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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　新流程

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

　　新平臺(tái)

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

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

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

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

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

　　容器和云 & 虛擬化

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

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

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

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

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

　　容器和 Serverless & FaaS

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

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

　　容器和邊緣計(jì)算 & IoT

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

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

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

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

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

　　人才技能

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

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

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

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

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

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

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

　　企業(yè) Legacy

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

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

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

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

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

　　工具的選擇

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　展望

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

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

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

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

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

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