戳藍字“CSDN云計算”關注我們哦！

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

談到容器與微服務，人們習慣圍繞著 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 自身的效率提升起步，逐步將重心轉移至對應用和業務的賦能，最終匯聚單點能量打造平臺能力，并推動新一輪的技術轉型升級。單一的容器個體是藐小的，但圍繞它展開的對動態架構的探索、對微觀方法論的思考、對技術價值的反思、和對未來應用的設計，則為我們打開了具有無限可能的未來世界大門。

容器技術的本質，是面向應用和業務價值再思考與再塑造， 而方法則是通過“微觀”解構并重塑“宏觀”。只有足夠深入而豐富的“微觀”，才能涌現真正宏大而健壯的“宏觀”。人類進入原子時代后掌握了核能，而容器之于我們呢？換一種視角，重新思考容器。

福利

掃描添加小編微信，備注“姓名+公司職位”，加入【云計算學習交流群】，和志同道合的朋友們共同打卡學習！

推薦閱讀：

• 在線公開課 | 從理論走向實踐，多角度詳解Cloud Native

• 蘋果春季發布會：庫克絕不玩別人玩剩下的！

• 中國區塊鏈職業發展現狀: 30歲前不做開發; 平均薪資僅38.4萬; 跳槽薪資漲三成 (附完整報告下載資源)

• 庫克談“唱衰蘋果”：一派胡言！

• 上海交大CV博導微信群辱罵學生，已停止教學
  

• 李沐團隊新作Gluon，復現CV經典模型到BERT，簡單好用 | 強烈推薦

• 日本樂天要求員工學編程，AI 進中小學課堂，全民編程時代來了！

真香，朕在看了！

總結

以上是生活随笔為你收集整理的容器：开启应用微观时代的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。