開啓應用微觀時代 | 容器時代的數字化轉型方法論

談到數字化轉型，大多數文章的表達方式大概都是「在時代從互聯網進入產業互聯網的背景下，全部行業都應該擁抱雲計算、大數據和人工智能……」好像只要開出這三味藥名就能藥到病除。

談到容器與微服務，人們習慣圍繞着 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 （整體擁有成本）。

二者各具優點，如何選擇則應訴諸於使用場景：更爲靈活的虛擬機方案比較適合開發測試環境，而 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 框架，須要提供良好的集成接口，在資源的調度和運維管理實現統一。同時，專業且溫馨的用戶體驗也不可或缺，從使用操做角度最大程度的兼容現有的流程和習慣。

組織和協做機制是另外一種隱形的企業 Legacy，包括業務長期發展沉澱下來的工做流程和職能劃分，業務需求塑造下的組織形態，甚至企業文化奠基的協做機制，等等。但容器、DevOps 、微服務帶來的不止於技術，一樣也是方法論層面的重構，對這些既有流程和習慣帶來衝擊不可避免。

綜合來看，容器項目在立項初期，就須要合理安排推動路徑，合理選型，儘可能減小對現有體系帶來大面積衝擊，逐步融入，長效演進，避免爆發式急進式的改造。

也能夠參考雲計算在企業內部落地的過程，不少企業先將雲平臺應用於部分創新業務場景，經過局部業務熟悉掌握雲平臺的構建和運維能力以後再推動到所有生產環境。

>>>>工具的選擇

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

業務人員的需求每每是很是直接的：版本發佈頻率愈來愈密集該怎麼辦、如何作測試和生產的隔離、如何作灰度發佈、發佈到生產環境以前要有審批……等等，這都是企業天天要面對的具體的事。

容器技術是底層支撐平臺，和業務需求之間有一層鴻溝，Kubernetes 也不能徹底彌補，更須要一個貫穿應用開發、測試、部署、運行管理全流程的解決方案級平臺產品，彌合開發和運維之間的認知、習慣與流程鴻溝。

這爲圍繞 Kubernetes 而延展出的應用生態提供了巨大的空間：

向下，基於 CNI，CSI 等標準定義，大大小小的存儲、網絡基礎架構廠商不斷把服務接駁進 Kubernetes 生態；

向上，面向各種業務應用場景不斷涌現出各種項目，有開源的也有商業，好比微服務治理的istio、鏡像倉庫 Harbor 等等，甚至一些遠早於 k8s 的老牌軟件也在調整自身去適應容器技術，好比 Jenkins 孵化的 Jenkins x 項目。

橫向，傳統 IT 領域的巨頭如 IBM、VMware，Rad Hat 等，紛紛宣佈支持 Kubernetes， 而大部分雲服務商則已經將雲端 Kubernetes 服務列爲標配。

但生態快速生長的同時，碎片化的問題也涌現出來。各功能模塊雖然選擇豐富，但缺少整合。好的企業級的容器平臺不該該是把各類功能碎片化的拼接起來，提供一個大而雜的技術產品，而應該經過體系化的設計，將企業在業務「微觀塑形」過程當中涉及的思惟、方法、工具與能力有機地整合起來，提供貫通應用開發、測試、部署、運行管理全流程的平臺級解決方案，並儘可能下降容器技術的使用門檻，簡化操做，最大程度兼容企業既有的業務流程和管理習慣。

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

• 流程重塑能力：

貫通工具到方法論的完整流程；

•抹平多角色技能與方法 gap 的能力：

讓多種角色各得其所，同心合力；

• 兼容傳統的能力：

尊重既有資產，無縫融入現有 IT 管理流程；

• 強大的性能支持：

健壯的網絡存儲支撐，確保高效穩定運行；

•安全性：

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

只見樹木，不見森林，是目前不少企業進行容器建設時的真實寫照。對系統化思考的缺失，盲目追捧熱點，每每很快由於各類挑戰阻力致使整個項目的失敗。

企業真正須要的是對架構設計和實現方法進行系統性的頂層設計和統籌考慮，因地制宜地結合現狀和能力進行長期規劃和平臺選型。這是一個系統性工程，同時若是能在平臺工具方面得到最大助益，則將大幅下降系統推動的難度，加速轉型進程。

展望

有人將容器做爲基礎計算力使用，能夠認爲這是初級階段；有人從業務視角，把一個個業務經過容器交付和運行， 能夠認爲進入了進階階段；而更進一步，以容器平臺作依託，去打造諸如物聯網、大規模計算平臺，Serverless、FaaS 等，即構建平臺之上的平臺，以一種技術去創造新的技術……

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

單一的容器個體是藐小的，但圍繞它展開的對動態架構的探索、對微觀方法論的思考、對技術價值的反思、和對將來應用的設計，則爲咱們打開了具備無限可能的將來世界大門。

容器技術的本質，是面向應用和業務價值再思考與再塑造， 而方法則是經過「微觀」解構並重塑「宏觀」。只有足夠深刻而豐富的「微觀」，才能涌現真正宏大而健壯的「宏觀」。人類進入原子時代後掌握了核能，而容器之於咱們呢？

換一種視角，從新思考容器。

「大道至簡 舉重若輕」，誠邀您參加將於 4 月 19 日在北京北辰洲際酒店舉辦的 KubeSphere 容器平臺產品發佈會，輕量級調度全棧雲功能，助力企業快速步入雲原生之旅，點擊閱讀原文或掃碼便可報名，帶你在數字化轉型中一步領先！