容器時代的數字轉型方法論

青云

企業需要厘清應用開發與運維全面向云原生和微服務架構轉型的根本原因，以及轉型過程中涉及的各種關鍵問題、相關概念之間的關系。

談到容器與微服務，人們習慣圍繞著Docker、Kubernetes、Service Mesh、FaaS、DevOps、Serverless等這些技術和概念在微觀層面打轉，結果導致企業在落地過程中出現很大的組織問題，進展舉步維艱。

本文試圖從企業業務核心訴求出發，在數字化轉型的核心邏輯下，幫助企業厘清企業應用開發與運維全面向云原生和微服務架構轉型的根本原因，以及轉型過程中涉及的各種關鍵問題、相關概念之間的關系。

2013年誕生的Docker，讓塵封已久的容器技術再一次興起，圍繞編排調度框架的百舸爭流，更是將容器推上了風口浪尖。直到 Kubernetes脫穎而出，成為業界公認的容器編排標準，容器似乎代表了未來的一切，業界對容器技術的追捧更是達到了頂點。然而，如同Gartner經典的技術成熟曲線所描述的，陡然而起的頂峰也意味著即將迎來的一輪幻滅低谷。當技術和生態日益蓬勃與成熟，越來越多的從業人員開始從單純對技術和理念的追捧，轉向對容器落地實踐與真實價值的思考。無獨有偶，Gartner調研預測，到2020年將有50%的企業會將容器應用于生產環境中。這從側面反映出業界，特別是最終用戶群體，對通過容器技術達成真正業務價值的期許。對于完成了高調亮相的容器和Kubernetes，接下來面臨的是走向成熟前的最后一次大考：突破“幻滅低谷”，走入真正的生產實踐，創造商業價值。

以“微觀塑形”的新業務、新應用

任何技術走入生產實踐的終極目標都是塑造企業創新性競爭力，為業務目標服務。

互聯網的出現為企業經營帶來了巨大的改變：全新的業務形態，更為廣闊的營銷空間，愈發高效的運轉效率。面向未來，企業業務將呈現更為徹底的互聯網化與數字化：從面向營銷、面向人的消費互聯網，通過物聯智能延伸到面向生產與供應鏈（物與流程）的產業互聯網，同時將更加依賴通過數據挖掘而形成的數據智能進行決策。企業IT將面臨超大規模、無數觸點、極高并發、極快速迭代更新等新的挑戰，需要更高的彈性和敏捷性。

數字化轉型1.0階段，企業更加關注基礎設施的敏捷性改造，并通過系統基礎架構（計算、存儲、網絡）全面云化實現獲取敏捷和彈性的第一波升級。而在云計算基礎上，完成對更為貼近實際業務的上層應用的架構轉型，將大幅提升業務敏捷性，云原生理念應運而生。

云原生的最基本屬性是分布式的，但以何種粒度和維度實現模塊化的切分，業界一直在不斷探索。Gartner提出了一種應用（服務）粒度理論，將應用分成：Macroservice、Miniservice、和Microservice，從粗到細依次對應不同的應用切分粒度。越細的粒度，將帶來越大的自由度和敏捷性。微服務架構就是基于這一理念，將應用進行更細粒度的模塊化拆分，并通過服務網格、服務治理技術建立起微服務間的通信網絡，從而構建起由獨立微小服務組織而成的應用（服務）網絡集群。由于每個個體相對而言是輕量化的，可以單獨開發與部署，使得整個微服務應用具備了高度的動態化能力，可以不斷快速迭代演化，也因此具有更強的業務敏捷性和彈性。Gartner基于微服務理念進一步提出了MASA（Mash App and Service Architecture）應用架構，并預測這種理念將成為未來應用架構的主流趨勢。應用開發開始從“宏觀造像”逐步走入“微觀塑形”。

如同愛因斯坦的相對論為我們打開了量子世界之門，微服務理念開啟了應用的“微觀世界”。但理論的真正落地，仍然需要一整套龐大的系統工程，包括完整的微服務工具集，與之匹配全新的應用開發與管理流程以及符合微服務特性的基礎設施平臺。

新流程

DevOps不僅僅是技術或者實現技術的工具，更是應用開發的一種組織架構和工作流程。DevOps通過流程的重構希望實現從開發、測試到最終應用部署發布全流程的貫通與高度自動化，從而實現敏捷開發。而正是這種對高度的動態特性的關注，讓DevOps方法論與微服務理念找到了共識。

新平臺

“輕量化”和“標準化”是容器最顯著的特性，而這兩個特性也恰恰完美匹配微服務應用開發的需求。輕量化匹配對“微觀”資源的需求，而標準化的封裝則為組網和標準化通信提供了基礎。進入“微觀”世界最不可避免的是數量劇增帶來的管理復雜性，也因此容器的使用從來不從單體出發，而強調調度編排，這也正是Kubernetes有如壓艙石一般的價值所在。同時，業界也普遍認可容器是運行DevOps的最佳平臺。

總結下來，企業真正需要的是利用更敏捷靈活的應用交付能力持續鎖定創新競爭力，而通過落地微服務完成應用架構升級，則是取得這一目標的關鍵。完善的容器平臺，提供基礎設施資源、完整的工具集、流程鏈及企業級工作平臺，為微服務及DevOps的全面落地提供一站式支持，應該成為所有企業容器建設的共同目標。

廣義架構黏合劑

以上是從縱向的視角探討容器對單體應用的重構，而以橫向的視角，從宏觀拓展的角度，亦可觀察到容器在多種新興應用場景中起到的黏合作用。

容器和云&虛擬化

一方面，容器和虛擬化是互補關系，這一點越來越為大家所認可。在容器最火熱的時候，將容器視為虛擬化替代品的論調也不乏受眾。但逐漸，大家在實踐中認知到容器與虛擬化各自的專長，也逐步區分開各自的應用場景。兩者都是基于分布式的架構理念，但是如之上提及的粒度理論，容器更敏捷更輕量，需要全方位的架構重組，適合短平快的新業務;而虛擬化粒度更粗，靈活不及容器，但單體更強壯，更適合需要長期穩定運行的重載應用。另一方面，容器是可以部署在虛擬化之上運行的。特別是在虛擬化大規模普及的背景下，這樣的部署方式更貼近用戶的使用習慣和真實環境，使用和運維都十分方便靈活，同時虛擬化在隔離性上的優勢也將補強容器的安全性。但代價是一定程度的性能損耗，特別是網絡性能。與之相應的是選擇將容器直接部署在物理機上，架構上減少一層，會大幅降低運維復雜度和性能損耗，同時資源利用率也將顯著提升，最終獲得更優的TCO（總體擁有成本）。

容器和 Serverless & FaaS

通過Serverless服務，用戶可以直接執行代碼來處理負載，從而完全避免了應用運行環境或部署所帶來的各類消耗，提供極高的需求響應速度，面對突發性或事件驅動型的負載，Serverless更具優勢。在目前這個階段，可以說容器為Serverless概念的落地奠定了技術基礎，不少服務商基于容器技術構建Serverless 服務。但未來很有可能，Serverless只是作為從容器到FaaS的過渡階段的一個代名詞，或者以Serverless統稱類容器的輕量計算平臺。

容器和邊緣計算 & IoT

邊緣計算并不是把云簡單復制到邊緣，而是一種體系化的計算框架設計。位居中心的云計算平臺和邊緣會有分工，處理不同場景下的負載。并且這種分工是動態和敏捷的，從而適應整個架構的狀態和實際場景的需求。比如在一個攝像頭智能識別圖像的IoT場景中，實現圖像識別的人工智能算法應該運行在邊緣，以便更快速響應來自攝像頭的實時需求，但算法不應該是固定不變的，應該在不斷學習中迭代升級。完成學習的巨大算力可以由中央的云負擔，而邊緣節點不斷快速迭代的需求則可以通過運行容器環境作為承載，同時還可兼顧邊緣節點對輕量化的要求。容器之于邊緣之于IoT，是一種更好黏合中心到邊緣的架構工具，同時也賦予整個物聯網更多的彈性與敏捷。

整體而言，容器作為一種輕量化的計算載體，為更多的場景賦予高度的彈性與敏捷性，也將更多場景有機的黏合在一起。從宏觀的視角看，這也是一種廣義架構層面的彈性與敏捷，同樣在橫向上重構了場景連接的方式。

實踐中的系統性挑戰

真正走入生產實踐時，環境現狀是復雜多樣的，雜糅了多重視角，既需要關注單體應用的開發流程的設計，也需要在宏觀全局層面上考量不同平臺間的有序銜接，同時兼顧來自管理、組織、人才等層面的挑戰。

人才技能

作為最前沿的技術領域，業界對這種新事物充滿了好奇。大家最初接觸Docker，都在感慨其便利性。但當Kubernetes出現后，很多人都在抱怨其復雜、難用。

一方面，Kubernetes實際上定義了一套新的標準，里面充斥著大量新概念和方法論，需要時間理解掌握。同時Kubernetes作為一個開源項目，關注核心的發展，而將關于易用性和教育培訓的問題交給了廣大社區自行解決。至今，原生Kubernetes大量的操作還需要通過命令行指令完成，這與企業IT從業者對UI化操作的預期還有相當的距離。而種類繁多且但參差不齊的周邊套件對初學者而言同樣無所適從。而且，Kuberentes對部署后期的運維也提出了不少新課題，比如容器網絡環境、持久化的數據存儲方案、運維監控等等。

另一方面，Kubernetes技術橫跨企業的系統和研發，打破了固有工作邊界。典型企業場景中，應用開發和系統運維是兩個團隊，大家擁有不同的工作重心、知識結構和和習慣認知。運行好一個集群平臺需要有強壯的網絡和存儲支持，而Kubernetes在這兩個方面還處于不斷發展階段，成熟的方案和先例不多，應用開發人員覺得不可掌控;同時運行容器集群是為了運行應用，不是作為一個OS來使用，系統人員又覺得沒有頭緒，兩方都需要理解對方的視角，也需要有全新的理念、方法論、組織架構、工作流程和新的工具，實現兩種角色的認知統一和協調推進。

毫無疑問，面對新技能的挑戰，企業都會想方設法幫助員工學習提升，但如何確保結果能夠得償所愿呢？現實的情況大多是，很多從業人員抱持著極大的熱忱而來，但面對陡峭的學習曲線又望而卻步，很快就喪失了堅持的動力，從而很快從好奇轉向了抗拒。也許，降低入門門檻，在沒有很專業的知識時就能先使用起來，在之后的使用中再不斷深入學習提升，創造一種學習實踐的正向循環，是更值得考慮的學習路徑。

企業 Legacy

容器帶來的創新是顛覆性的，而企業既有的應用架構、基礎設施、組織架構、業務流程、協同和管理方法等，這些行之有年的穩定體系，不會輕易改變，也不可能輕易改變。

從技術層面，作為整體IT的一部分，容器平臺應該恰如其分的融入整體，而絕不應該是一個獨立的技術體系。

而一個全新平臺想要融入現有企業IT框架，需要提供良好的集成接口，在資源的調度和運維管理上實現統一。同時，專業且舒適的用戶體驗也不可或缺，從使用操作角度最大程度的兼容現有流程和習慣。

綜合來看，容器項目在立項初期，就需要合理安排推進路徑，合理選型，盡量減少對現有體系帶來大面積沖擊，逐步融入，長效演進，避免爆發式急進式的改造。也可以參考云計算在企業內部落地的過程，很多企業先將云平臺應用于部分創新業務場景，通過局部業務熟悉掌握云平臺的構建和運維能力之后再推進到全部生產環境。

工具的選擇

工具是落地的抓手，一方面要足夠豐富以滿足最直接的需求，而另一方面也需要足夠統一以發揮系統性的價值。

業務人員的需求往往是非常直接的：版本發布頻率越來越密集該怎么辦、如何做測試和生產的隔離、如何做灰度發布、發布到生產環境之前要有審批等，這都是企業每天要面對的具體的事。

容器技術是底層支撐平臺，和業務需求之間有一層鴻溝，Kubernetes也不能完全彌補，更需要一個貫穿應用開發、測試、部署、運行管理全流程的解決方案級平臺產品，彌合開發和運維之間的認知、習慣與流程鴻溝。這為圍繞Kubernetes而延展出的應用生態提供了巨大的空間：向下，基于CNI，CSI等標準定義，大大小小的存儲、網絡基礎架構廠商不斷把服務接駁進Kubernetes生態;向上，面向各類業務應用場景不斷涌現出各類項目，有開源的也有商業，比如微服務治理的istio、鏡像倉庫Harbor等，甚至一些遠早于k8s的老牌軟件也在調整自身去適應容器技術，比如Jenkins孵化的Jenkins x項目。橫向，傳統IT領域的巨頭如IBM、VMware，Rad Hat等，紛紛宣布支持Kubernetes，而大部分云服務商則已經將云端Kubernetes服務列為標配。

但生態快速生長的同時，碎片化的問題也涌現出來。各功能模塊雖然選擇豐富，但缺乏整合。

好的企業級容器平臺不應該只是把各種功能碎片化的拼接起來，提供一個大而雜的技術產品，而應該通過體系化的設計，將企業在業務“微觀塑形”過程中涉及的思維、方法、工具與能力有機地整合起來，提供貫通應用開發、測試、部署、運行管理全流程的平臺級解決方案，并盡量降低容器技術的使用門檻，簡化操作，最大程度兼容企業既有的業務流程和管理習慣。

綜上所述，除了滿足功能和業務的設計目標，諸多延展而來的問題也需要統籌考慮，完整而系統化的容器平臺，應該包括：

·簡單易用，快速上手：幫助用戶快速入門，激發學習實踐的正向循環;

·流程重塑能力：貫通從工具到方法論的完整流程;

·抹平多角色技能與方法gap的能力：讓多種角色各得其所，同心協力;

·兼容傳統的能力：尊重既有資產，無縫融入現有 IT 管理流程;

·強大的性能支持：健壯的網絡存儲支撐，確保高效穩定運行;

·安全性：企業級安全體系，包括多租戶環境下的安全隔離機制。

展望

容器進階之路，清晰地描繪出企業數字化轉型的歷程，從關注IT自身的效率提升起步，逐步將重心轉移至對應用和業務的賦能，最終匯聚單點能量打造平臺能力，并推動新一輪的技術轉型升級。

單一的容器個體是渺小的，但圍繞它展開的對動態架構的探索、對微觀方法論的思考、對技術價值的反思和對未來應用的設計，則為我們打開了具有無限可能的未來世界大門。容器技術的本質，是面向應用和業務價值再思考與再塑造，而方法則是通過“微觀”解構并重塑“宏觀”。技術飛速發展，容器時代的數字轉型方法論到底該如何掌握？或許每一個企業都有著不同的理解。