【前言】談到數(shù)字化轉(zhuǎn)型，大多數(shù)文章的表達方式大概都是“在時代從互聯(lián)網(wǎng)進入產(chǎn)業(yè)互聯(lián)網(wǎng)的背景下，所有行業(yè)都應(yīng)該擁抱云計算、大數(shù)據(jù)和人工智能……”好像只要開出這三味藥名就能藥到病除。

　　談到容器與微服務(wù)，人們習(xí)慣圍繞著 Docker、Kubernetes、Service Mesh、FaaS、DevOps、Serverless……這些技術(shù)和概念在微觀層面打轉(zhuǎn)，結(jié)果在落地過程中出現(xiàn)很大的組織裂痕，舉步維艱。

　　本文試圖從企業(yè)業(yè)務(wù)核心訴求出發(fā)，在數(shù)字化轉(zhuǎn)型核心邏輯下，幫助企業(yè)厘清企業(yè)應(yīng)用開發(fā)與運維全面向云原生和微服務(wù)架構(gòu)轉(zhuǎn)型的根本原因，以及轉(zhuǎn)型過程中涉及的各種關(guān)鍵問題、相關(guān)概念之間的關(guān)系。

　　2013 年誕生的 Docker，讓塵封已久的容器技術(shù)再一次興起。圍繞編排調(diào)度框架的百舸爭流，更是將容器推上了風(fēng)口浪尖。直到 Kubernetes 脫穎而出，成為業(yè)界公認的容器編排標(biāo)準(zhǔn)，容器似乎代表了未來的一切，業(yè)界對容器技術(shù)的追捧更是達到了頂點。

　　然而，如同 Gartner 經(jīng)典的技術(shù)成熟曲線所描述的，陡然而起的頂峰也意味著即將迎來的一輪“幻滅低谷”。當(dāng)技術(shù)和生態(tài)日益蓬勃與成熟，越來越多的從業(yè)人員開始從單純對技術(shù)和理念的追捧，轉(zhuǎn)向?qū)θ萜髀涞貙嵺`與真實價值的思考。無獨有偶，另一份 Gartner 調(diào)研預(yù)測到 2020 年將有 50% 的企業(yè)會將容器應(yīng)用于生產(chǎn)環(huán)境中。

　　這側(cè)面反映出業(yè)界，特別是最終用戶群體，對通過容器技術(shù)達成真正業(yè)務(wù)價值的期許。對于完成了高光亮相的容器和Kubernetes， 接下來面臨的是走向成熟前的最后一次大考：突破“幻滅低谷”，走入真正的生產(chǎn)實踐，創(chuàng)造商業(yè)價值。

　　以“微觀塑形”的新業(yè)務(wù)新應(yīng)用

　　任何技術(shù)走入生產(chǎn)實踐的終極目標(biāo)都是塑造企業(yè)創(chuàng)新性競爭力，為業(yè)務(wù)目標(biāo)服務(wù)。

　　互聯(lián)網(wǎng)的出現(xiàn)為企業(yè)經(jīng)營帶來巨大改變：全新的業(yè)務(wù)形態(tài)，更為廣闊的營銷空間，愈發(fā)高效的運轉(zhuǎn)效率。面向未來，企業(yè)業(yè)務(wù)將呈現(xiàn)更為徹底的互聯(lián)網(wǎng)化與數(shù)字化：從面向營銷、面向人的消費互聯(lián)網(wǎng)，通過物聯(lián)智能延伸到面向生產(chǎn)與供應(yīng)鏈(物與流程)的產(chǎn)業(yè)互聯(lián)網(wǎng)，同時將更加依賴通過數(shù)據(jù)挖掘而形成的數(shù)據(jù)智能進行決策。

　　企業(yè) IT 將面臨超大規(guī)模、無數(shù)觸點、極高并發(fā)、極快速迭代更新等新的挑戰(zhàn)，需要更高的彈性和敏捷性。

　　數(shù)字化轉(zhuǎn)型 1.0 階段，企業(yè)更加關(guān)注基礎(chǔ)設(shè)施的敏捷性改造，通過系統(tǒng)基礎(chǔ)架構(gòu)(計算、存儲、網(wǎng)絡(luò))全面云化實現(xiàn)獲取敏捷和彈性的第一波升級。而在云計算基礎(chǔ)上，完成對更為貼近實際業(yè)務(wù)的上層應(yīng)用的架構(gòu)轉(zhuǎn)型，將更直接的大幅提升業(yè)務(wù)敏捷性，云原生理念應(yīng)運而生。

　　云原生的最基本屬性是分布式的，但以何種粒度和維度實現(xiàn)模塊化的切分，業(yè)界一直在不斷探索。Gartner 提出了一種應(yīng)用(服務(wù))粒度理論，將應(yīng)用分成：Macroservice、Miniservice、和 Microservice，從粗到細依次對應(yīng)不同的應(yīng)用切分粒度。越細的粒度，將帶來越大的自由度和敏捷性。

　　微服務(wù)架構(gòu)就是基于這一理念，將應(yīng)用進行更細粒度的模塊化拆分，并通過服務(wù)網(wǎng)格/服務(wù)治理技術(shù)建立起微服務(wù)間的通信網(wǎng)絡(luò)，從而構(gòu)建起由獨立微小服務(wù)組織而成的應(yīng)用(服務(wù))網(wǎng)絡(luò)集群。

　　由于每個個體相對而言是輕量化的，可以單獨開發(fā)與部署，使得整個微服務(wù)應(yīng)用具備了高度的動態(tài)化能力，可以不斷的快速迭代演化，也因此具有更強的業(yè)務(wù)敏捷性和彈性。

　　Gartner 基于微服務(wù)理念進一步提出了 MASA (Mash App and Service Architecture)應(yīng)用架構(gòu)，并預(yù)測這種理念將成為未來應(yīng)用架構(gòu)的主流趨勢。 應(yīng)用開發(fā)開始從“宏觀造像”逐步走入“微觀塑形”。

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

　　新流程

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

　　新平臺

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

　　總結(jié)下來，企業(yè)真正需要的是利用更敏捷靈活的應(yīng)用交付能力持續(xù)鎖定創(chuàng)新競爭力，而通過落地微服務(wù)完成應(yīng)用架構(gòu)升級，則是取得這一目標(biāo)的關(guān)鍵。

　　完善的容器平臺，提供基礎(chǔ)設(shè)施資源、完整的工具集、流程鏈及企業(yè)級工作平臺，為微服務(wù)及 DevOps 的全面落地提供一站式支持，應(yīng)該成為所有企業(yè)容器建設(shè)的共同目標(biāo)。

　　廣義架構(gòu)的粘合劑

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

　　容器和云 & 虛擬化

　　一方面，容器和虛擬化是互補關(guān)系，這一點越來越為大家所認可。在容器最火熱的時候，將容器視為虛擬化替代品的論調(diào)也不乏受眾。

　　但逐漸，大家在實踐中認知到容器與虛擬化各自的專長，也逐步區(qū)分開各自的應(yīng)用場景。兩者都是基于分布式的架構(gòu)理念，但是如之上提及的粒度理論，容器更敏捷更輕量，需要全方位的架構(gòu)重組，適合短平快的新業(yè)務(wù); 而虛擬化粒度更粗，靈活不及容器，但單體更強壯，更適合需要長期穩(wěn)定運行的重載應(yīng)用。因此在相當(dāng)長的時間內(nèi)，虛擬化和容器將以互補的關(guān)系在企業(yè)的生產(chǎn)環(huán)境中長期共存。

　　另一方面，容器是可以部署在虛擬化之上運行的。特別是在虛擬化大規(guī)模普及的背景下，這樣的部署方式更貼近用戶的使用習(xí)慣和真實環(huán)境，使用和運維都十分方便靈活，同時虛擬化在隔離性上的優(yōu)勢也將補強容器的安全性。但代價是在一定程度的性能損耗，特別是網(wǎng)絡(luò)性能。

　　與之相應(yīng)的，是選擇將容器直接部署在物理機上，架構(gòu)上減少一層，會大幅降低運維復(fù)雜度和性能損耗，同時資源利用率也將顯著提升，最終獲得更優(yōu)的 TCO (總體擁有成本)。

　　兩者各具優(yōu)勢，如何選擇則應(yīng)訴諸于使用場景：更為靈活的虛擬機方案比較適合開發(fā)測試環(huán)境，而 TCO 和性能更好的物理機方案則更適合長期運行的生產(chǎn)環(huán)境。在真實環(huán)境中，這兩者不是簡單的二選一，大多數(shù)時候是同時存在互相補充的，在一套完整的云體系中統(tǒng)籌管理運行。

　　容器和 Serverless & FaaS

　　通過 Serverless 服務(wù)，用戶可以直接執(zhí)行代碼來處理負載，從而完全避免了應(yīng)用運行環(huán)境或部署所帶來的各類消耗，提供極高的需求響應(yīng)速度，面對突發(fā)性或事件驅(qū)動型的負載，Serverless 更具優(yōu)勢。在目前這個階段，可以說容器為 Serverless 概念的落地奠定了技術(shù)基礎(chǔ)，不少服務(wù)商基于容器技術(shù)構(gòu)建 Serverless 服務(wù)。

　　但未來很有可能，Serverless 只是作為從容器到 FaaS 的過渡階段的一個代名詞，或者以 Serverless 統(tǒng)稱類容器的輕量計算平臺。輕量化和高度敏捷快速是這類平臺的共同特征，能滿足關(guān)于彈性伸縮、按需按量計費等敏態(tài)的需求。

　　容器和邊緣計算 & IoT

　　邊緣計算并不是把云簡單復(fù)制到邊緣，而是一種體系化的計算框架設(shè)計。位居中心的云計算平臺和邊緣會有分工，處理不同場景下的負載。并且這種分工是動態(tài)和敏捷的，以適應(yīng)整個架構(gòu)的狀態(tài)和實際場景的需求。

　　比如在一個攝像頭智能識別圖像的 IoT 場景中，實現(xiàn)圖像識別的人工智能算法應(yīng)該運行在邊緣，以便更快速響應(yīng)來自攝像頭的實時需求，但算法不應(yīng)該是固定不變的，應(yīng)該在不斷的學(xué)習(xí)中迭代升級。完成學(xué)習(xí)的巨大算力可以由中央的云負擔(dān)，而邊緣節(jié)點不斷快速迭代的需求則可以通過運行容器環(huán)境作為承載，同時還可兼顧邊緣節(jié)點對輕量化的要求。容器之于邊緣之于 IoT，是一種更好粘合中心到邊緣的架構(gòu)工具，同時也賦予整個物聯(lián)網(wǎng)更多的彈性與敏捷。

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

　　實踐中的系統(tǒng)性挑戰(zhàn)

　　真正走入生產(chǎn)實踐時，環(huán)境現(xiàn)狀是復(fù)雜多樣的，雜糅了多重視角，既需要關(guān)注單體應(yīng)用的開發(fā)流程的設(shè)計，也需要在宏觀全局層面上考量不同平臺間的有序銜接，同時兼顧來自管理、組織、人才等層面的挑戰(zhàn)。

　　人才技能

　　作為最前沿的技術(shù)領(lǐng)域，業(yè)界對這種新事物充滿了好奇。大家最初接觸 Docker，都在感慨其便利性。但當(dāng) Kubernetes 出現(xiàn)后，很多人都在抱怨其復(fù)雜、難用。

　　一方面， Kubernetes 實際上定義了一套新的標(biāo)準(zhǔn)，里面充斥著大量新概念和方法論，需要時間理解掌握。同時 Kubernetes 作為一個開源項目， 關(guān)注核心的發(fā)展，而將關(guān)于易用性和教育培訓(xùn)的問題交給了廣大社區(qū)自行解決。

　　至今，原生 Kubernetes 大量的操作還需要通過命令行指令完成，這與企業(yè) IT 從業(yè)者對 UI 化操作的預(yù)期還有相當(dāng)?shù)木嚯x。而種類繁多且但參差不齊的周邊套件對初學(xué)者而言同樣無所適從。而且，Kuberentes 對部署后期的運維也提出了不少新課題，比如容器網(wǎng)絡(luò)環(huán)境、持久化的數(shù)據(jù)存儲方案、運維監(jiān)控等等。

　　另一方面， Kubernetes 技術(shù)橫跨企業(yè)的系統(tǒng)和研發(fā)，打破了固有工作邊界。典型企業(yè)場景中，應(yīng)用開發(fā)和系統(tǒng)運維是兩個團隊，大家擁有不同的工作重心、知識結(jié)構(gòu)和和習(xí)慣認知。

　　運行好一個集群平臺需要有強壯的網(wǎng)絡(luò)和存儲支持，而 Kubernetes 在這兩個方面還處于不斷發(fā)展階段，成熟的方案和先例不多，應(yīng)用開發(fā)人員覺得不可掌控;同時運行容器集群是為了運行應(yīng)用，不是作為一個 OS 來使用，系統(tǒng)人員又覺得沒有頭緒，兩方都需要理解對方的視角，也需要有全新的理念、方法論、組織架構(gòu)、工作流程和新的工具，實現(xiàn)兩種角色的認知統(tǒng)一和協(xié)調(diào)推進。

　　毫無疑問，面對新技能的挑戰(zhàn)，企業(yè)都會想方設(shè)法幫助員工學(xué)習(xí)提升，但如何確保結(jié)果能夠得償所愿呢?

　　現(xiàn)實的情況大多是，很多從業(yè)人員抱持著極大的熱忱而來，但面對陡峭的學(xué)習(xí)曲線又望而卻步，很快就喪失了堅持的動力，從而很快從好奇轉(zhuǎn)向了抗拒。也許，降低入門門檻，在沒有很專業(yè)的知識時就能先使用起來，在之后的使用中在不斷深入學(xué)習(xí)提升，創(chuàng)造一種學(xué)習(xí)實踐的正向循環(huán)，是更值得考慮的學(xué)習(xí)路徑。

　　企業(yè) Legacy

　　容器帶來的創(chuàng)新是顛覆性的，而企業(yè)既有的應(yīng)用架構(gòu)、基礎(chǔ)設(shè)施、組織架構(gòu)、業(yè)務(wù)流程、協(xié)同和管理方法等等，這些行之有年的穩(wěn)定體系，不會輕易改變，也不可能輕易改變。

　　從技術(shù)層面，作為整體 IT 的一部分，容器平臺應(yīng)該恰如其分的融入整體， 而絕不應(yīng)該是一個獨立的技術(shù)體系。而一個全新平臺想要融入現(xiàn)有企業(yè) IT 框架，需要提供良好的集成接口，在資源的調(diào)度和運維管理實現(xiàn)統(tǒng)一。同時，專業(yè)且舒適的用戶體驗也不可或缺，從使用操作角度最大程度的兼容現(xiàn)有的流程和習(xí)慣。

　　組織和協(xié)作機制是另一種隱形的企業(yè) Legacy，包括業(yè)務(wù)長期發(fā)展沉淀下來的工作流程和職能劃分，業(yè)務(wù)需求塑造下的組織形態(tài)，甚至企業(yè)文化奠定的協(xié)作機制，等等。但容器、DevOps 、微服務(wù)帶來的不止于技術(shù)，同樣也是方法論層面的重構(gòu)，對這些既有流程和習(xí)慣帶來沖擊不可避免。

　　綜合來看，容器項目在立項初期，就需要合理安排推進路徑，合理選型，盡量減少對現(xiàn)有體系帶來大面積沖擊，逐步融入，長效演進，避免爆發(fā)式急進式的改造。

　　也可以參考云計算在企業(yè)內(nèi)部落地的過程，很多企業(yè)先將云平臺應(yīng)用于部分創(chuàng)新業(yè)務(wù)場景，通過局部業(yè)務(wù)熟悉掌握云平臺的構(gòu)建和運維能力之后再推進到全部生產(chǎn)環(huán)境。

　　工具的選擇

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

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

　　容器技術(shù)是底層支撐平臺，和業(yè)務(wù)需求之間有一層鴻溝，Kubernetes 也不能完全彌補，更需要一個貫穿應(yīng)用開發(fā)、測試、部署、運行管理全流程的解決方案級平臺產(chǎn)品，彌合開發(fā)和運維之間的認知、習(xí)慣與流程鴻溝。

　　這為圍繞 Kubernetes 而延展出的應(yīng)用生態(tài)提供了巨大的空間：

　　向下，基于 CNI，CSI 等標(biāo)準(zhǔn)定義，大大小小的存儲、網(wǎng)絡(luò)基礎(chǔ)架構(gòu)廠商不斷把服務(wù)接駁進 Kubernetes 生態(tài);

　　向上，面向各類業(yè)務(wù)應(yīng)用場景不斷涌現(xiàn)出各類項目，有開源的也有商業(yè)，比如微服務(wù)治理的istio、鏡像倉庫 Harbor 等等，甚至一些遠早于 k8s 的老牌軟件也在調(diào)整自身去適應(yīng)容器技術(shù)，比如 Jenkins 孵化的 Jenkins x 項目。

　　橫向，傳統(tǒng) IT 領(lǐng)域的巨頭如 IBM、VMware，Rad Hat 等，紛紛宣布支持 Kubernetes， 而大部分云服務(wù)商則已經(jīng)將云端 Kubernetes 服務(wù)列為標(biāo)配。

　　但生態(tài)快速生長的同時，碎片化的問題也涌現(xiàn)出來。各功能模塊雖然選擇豐富，但缺乏整合。好的企業(yè)級的容器平臺不應(yīng)該是把各種功能碎片化的拼接起來，提供一個大而雜的技術(shù)產(chǎn)品，而應(yīng)該通過體系化的設(shè)計，將企業(yè)在業(yè)務(wù)“微觀塑形”過程中涉及的思維、方法、工具與能力有機地整合起來，提供貫通應(yīng)用開發(fā)、測試、部署、運行管理全流程的平臺級解決方案，并盡量降低容器技術(shù)的使用門檻，簡化操作，最大程度兼容企業(yè)既有的業(yè)務(wù)流程和管理習(xí)慣。

　　綜上，除了滿足功能和業(yè)務(wù)的設(shè)計目標(biāo)，諸多延展而來的問題也需要統(tǒng)籌考慮，完整而系統(tǒng)化的容器平臺，應(yīng)該包括：

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

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

　　• 兼容傳統(tǒng)的能力：尊重既有資產(chǎn)，無縫融入現(xiàn)有 IT 管理流程;

　　• 強大的性能支持：健壯的網(wǎng)絡(luò)存儲支撐，確保高效穩(wěn)定運行;

　　•安全性：企業(yè)級安全體系，包括多租戶環(huán)境下的安全隔離機制。

　　企業(yè)級安全體系，包括多租戶環(huán)境下的安全隔離機制。

　　只見樹木，不見森林，是目前很多企業(yè)進行容器建設(shè)時的真實寫照。對系統(tǒng)化思考的缺失，盲目追捧熱點，往往很快因為各種挑戰(zhàn)阻力導(dǎo)致整個項目的失敗。

　　企業(yè)真正需要的是對架構(gòu)設(shè)計和實現(xiàn)方法進行系統(tǒng)性的頂層設(shè)計和統(tǒng)籌考慮，因地制宜地結(jié)合現(xiàn)狀和能力進行長期規(guī)劃和平臺選型。這是一個系統(tǒng)性工程，同時如果能在平臺工具方面獲得最大助益，則將大幅降低系統(tǒng)推進的難度，加速轉(zhuǎn)型進程。

　　展望

　　有人將容器作為基礎(chǔ)計算力使用，可以認為這是初級階段;有人從業(yè)務(wù)視角，把一個個業(yè)務(wù)通過容器交付和運行， 可以認為進入了進階階段;而更進一步，以容器平臺做依托，去打造諸如物聯(lián)網(wǎng)、大規(guī)模計算平臺，Serverless、FaaS 等，即構(gòu)建平臺之上的平臺，以一種技術(shù)去創(chuàng)造新的技術(shù)……

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

　　單一的容器個體是藐小的，但圍繞它展開的對動態(tài)架構(gòu)的探索、對微觀方法論的思考、對技術(shù)價值的反思、和對未來應(yīng)用的設(shè)計，則為我們打開了具有無限可能的未來世界大門。

　　容器技術(shù)的本質(zhì)，是面向應(yīng)用和業(yè)務(wù)價值再思考與再塑造， 而方法則是通過“微觀”解構(gòu)并重塑“宏觀”。只有足夠深入而豐富的“微觀”，才能涌現(xiàn)真正宏大而健壯的“宏觀”。人類進入原子時代后掌握了核能，而容器之于我們呢?

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

　　“大道至簡 舉重若輕”誠邀您參加將于4月19日在北京北辰洲際酒店舉辦的KubeSphere 容器平臺發(fā)布會，輕量級調(diào)度全棧云功能，助力企業(yè)快速步入云原生之旅，掃碼報名(https://www.bagevent.com/event/2420412?bag_track=pr)，帶你在數(shù)字化轉(zhuǎn)型中一步領(lǐng)先!