在技術變革推動社會發展這一時代背景下，大量支撐規模化分佈式應用的技術創新、創造與創業應用而生，Could Native、Service Mesh、Serverless 等技術詞彙在全球範圍內引發了大量的解讀與討論，本文整理自阿里巴巴高級技術專家李雲在 QCon 北京 2019 的分享，帶你一起看清其背後的本質與驅動力，更好地把握技術趨勢並建立自己的思考邏輯。
圍繞解決大規模分佈式應用技術挑戰的話題總能引起廣泛的關注，CNCF 所提出的雲原生概念將這一話題推向了前所未有的新高度。就目前的行業發展現狀來看，雲原生是分佈式應用走向未來的關鍵路徑。此外，出現了 CDF 從 CI/CD 的角度幫助解決未來分佈式應用周邊的的挑戰等現象。我們不僅要問，“分佈式應用的未來究竟是什麼？”面對這一問題，具象化地給出所有人都能理解一致的描繪在現階段是不現實的，但給出一個相對模糊但又抓住重點的概念或許並不困難，作者用 Distributionless（無分佈式）去表達。
在全球範圍內帶來變革的技術，其背後不只是技術因素，還有商業利益的共同演繹。理解背後的驅動力能讓我們更準確地抓住新技術的優勢和思考未來發展的可能終局，這對於 CTO、CIO 等各類技術決策者來說至關重要。
解決複雜問題的終極範式
技術最終是服務於商業和社會的，但在“條條大路通羅馬”的情形下，如何判定一個技術比另一個技術更優呢？或者說，在技術向前演進的過程中，有沒有固定的範式可被我們掌握，從而將之運用於理解新技術的優勢呢？這個終極範式在作者看來就是“抽象後分而治之”。
探索複雜規模問題的解決方法從來都是動態、漸進的，會經歷不斷認識問題和尋找更優解的持續迭代過程，期間伴隨着部分“舊概念”被打破和“新概念”被重塑的雙重行爲。
比如，在實踐微服務軟件架構之初，一開始大家所關注的焦點是“如何拆”、“拆多大”以及技術與組織架構的配稱（康威定律），核心思路是通過將單體應用通過分拆去變成更小的軟件發佈單元，以解決單體應用的軟件迭代速度慢的問題（背後導致了商業價值創造慢的後果）。然而，當微服務改造工作完成且微服務的個數達到一定的規模時，各服務之間的連接、排錯、安全保障、監控等問題就逐漸地浮出了水面，那時行業深刻地體會並認識到微服務軟件架構其實是將複雜度從單體應用內轉移到了微服務之間。隨着分佈式應用規模的進一步增大，所涉開發和運維人員增長到一定數據時，效率問題再一次變得像單體應用時代那樣不可小視。不過，這一次所面臨的問題域和規模比那時大了很多。要解決微服務軟件架構所帶來的新問題，需要探索更加體系化、規範化和全局一致的解決方案，那就不可避免地會採用新的概念切分手法去構建新的解決方案，期間不可並避免地會打破舊概念並創造出新概念。
新舊概念相比之下，存在如下差異：
-
舊概念更側重於局部最優，不同舊概念之間的銜接存在生硬的現象。對複雜問題的探索從來都漸進式的，因而對問題的理解是一個從局部走向全局的過程，出現這樣的現狀是非常正常的現象。對於軟件系統來說，其軟件設計質量可從概念是否優雅、流暢去體現。子系統之間的概念銜接生硬往往意味着軟件設計缺乏全局觀，以致銜接處埋藏了不少醜陋的代碼，因維護成本高而影響了整個系統的演進效率和解決問題的有效性。
-
新概念更加抽象，塑造的目標是爲了實現全局最優（體系化），並滿足更多利益相關者的不同訴求。由於設計時的問題域更大、格局更高，所以子概念之間的銜接相當流暢，體現出了軟件設計的整體感和一致性。
“抽象後分而治之”爲技術人提供了一種單純從技術視角去分析一種技術是否優於另一種技術的方法，能一定程度避免被“老酒換新瓶”那樣的新概念所蠱惑。以這一範式去看待圍繞雲原生所出現的 Kubernetes、Istio、Knative 等技術，相信能因這些新技術的概念切分獨特、更具體系化和有更高的技術視野而對其先進性加以認可。
雲原生的驅動力及其本質
新技術得不到推廣應用並最終消亡的例子舉不勝舉。雲原生概念從提出到今天在全球範圍的如火如荼只經歷了短短的四年，背後的驅動力是什麼很值我們思考。此外，雲原生技術的概念目前仍相當模糊，理解其所解決的本質問題才能使技術團隊在發展的道路上正視趨勢，以及讓技術決策者更好地規劃技術發展方向。
從商業的角度，AWS 是無可爭議的雲計算市場的領導者，但其技術影響力遠不如 Google。雖說 Google 在技術實力上是全球的領導者，但在雲計算市場的發展上曾帶給人的傲慢感而最終沒能在市場表現上與 AWS 相庭抗禮。在面對市場佔有率落後的情形下，Google 發起了 CNCF 基金會，通過提出雲原生技術致力於打造廠商中立（vendor-neutral）的開源軟件事實標準，希望有機會以另一種路徑在市場中獲得突圍。“廠商中立”又意味着什麼？
輸出技術產品的廠商與其客戶之間一直存在一種利益博弈——技術鎖定和防鎖定。當廠商所輸出的技術無法在短期內立竿見影地給客戶創造業務價值時，這種博弈的痕跡就會更加明顯，否則客戶在短期內也樂於被鎖定。從廠商的角度，通過技術鎖定客戶就會有更高的要價空間和持續的利潤來源。反之，如果客戶做到了技術的防鎖定，則有更強的議價能力和選擇自由，否則會擔心成爲“砧板上的魚肉”。長遠來看，如何保持這種博弈力量的平衡是打造一個繁榮技術或商業生態的關鍵。這樣的案例在業已成熟的通信行業很早就出現了且仍在發生。
通信行業有一個標準化組織叫 3GPP，這個組織中有來自中國移動、中國聯通、中國電信這樣的各國電信運營商，也有來自華爲、ZTE 這樣的全球通信設備製造商。3GPP 通過制定規範並要求所有設備製造商全面遵循，使得運營商有從哪家採購通信設備的自由。回到雲計算市場，在通訊行業的規範變成了大家共同構建和採納的開源軟件，準確說是事實標準的開源軟件。
實事標準的關鍵不是開源，還得加上所有云廠商都採納，這一點對於提供雲基礎技術的雲廠商來說特別關鍵。具體的一個例子是，Kubernetes 是雲原生中的基礎設施並得到了所有云廠商的採納而提供相應的雲產品。當一個客戶採購了 AWS 的 Kubernetes 產品時，可以隨時方便地遷移到阿里雲上而不用擔心技術鎖定問題。不可否認，雲廠商提供雲產品與用戶自建是完全不同級別的可用性保障維度，這一點是很多客戶樂於花錢購買雲產品的關鍵。
技術防鎖定的利益博弈只要與客戶做交流就一定會看到，而這一力量也被 CNCF 發現並運用於推廣雲原生技術，且成爲了雲原生技術發展的核心驅動力，使得雲原生技術在相當短的時間內得到了來自雲廠商和雲客戶的大力支持。必須指出，AWS 作爲雲計算的行業領導者很少講技術鎖定這事，那是因爲沒有必要宣傳這一點而讓到手的客戶從自己手中流失，那並非因爲 AWS 沒有看到客戶對技術鎖定的擔心，從其積極跟進雲原生技術也不難佐證這一點。
Google 能否通過雲原生的推廣而在未來的雲計算市場獲得更大的份額雖說未知，但那不是我們關心的重點。重點在於，雲原生作爲行業認可的技術趨勢，我們如何迎合和規劃未來的技術發展，以及羣策羣力去打造一個健康、蓬勃發展的雲計算產業生態。
理解雲原生核心驅動力的價值在於，雲廠商在爲客戶提供雲原生技術方案時，需要充分地考慮到不要給客戶帶去技術鎖定，但可以考慮通過產品做粘性。鎖定是指“用了我你就無法方便地離開我”，而粘性是指“用了我可以給你帶去不一樣的價值，而你也可以隨時方便地離開我”。
只理解雲原生的核心驅動力還不夠，還得掌握它所解決的本質問題是什麼。作者歸納爲雲原生所解決的本質問題是應用（或“服務”，本文這兩詞可以互換使用）的彈性、易用性和移植性這層層遞進的“三性”。
應用的彈性是指即便在最嚴苛的業務場景下，技術仍具備給客戶創造業務價值的能力。換句話說，客戶使用了某個技術解決方案後，他可以持續有效地運用該產品去創造業務價值。從技術的角度，彈性包含了微服務軟件架構、充分解耦、高可用、異地多活、限流、熔斷、降級、不可變基礎設施等內容，以及支持應用的快速擴縮容能力。
第二個解決的本質問題是易用性。如果只解決了應用的彈性而沒有解決易用性，那麼爲了運用技術去支撐業務價值創造所需投入的人力和時間會是企業所面臨的下一個沉重負擔，最終在技術的運用和價值創造上無法體現敏捷性和經濟性。易用性對於雲產品的用戶和客戶來說，代表了良好的開發和運維效率。
良好的開發效率意味着使用者（客戶側的開發者）只需關心最少的概念和寫最少的代碼，這就需要雲產品在打造之時很好地圍繞使用者的心智和能力水平去設計，通過讓技術之間做儘可能的無縫連接、對技術細節做良好的抽象甚至徹底屏蔽去降低使用門檻。良好的運維效率則指，只用很少的幾個人就可以運維龐大的集羣，整個分佈式應用的發佈、故障發現和排錯都很高效。
上圖中，作者在易用性這塊羅列了 DevOps、GitOps、Cloud IDE 和 CI/CD 等內容。其中的 GitOps 被認爲是下一代的 DevOps，讓運維工作變得與寫代碼的方式一樣，將 Git 倉庫作爲運維工作的“the single source of truth”，這對於多雲、混合雲和多集羣部署是非常有價值的。Git 所具備的版本管理能力讓運維工作變得更加可溯與可控。總的說來，易用性解決的是軟件開發效率、工程質量和人力成本問題。
第三個解決的本質問題是應用的移植性。多雲（注：指同時使用多個公有云）和混合雲（注：指同時使用公有云和專有云）被 Gartner 認爲是未來企業 IT 的重要戰略。延着該戰略，終態得做到一個分佈式應用的代碼零改動就能方便地部署到不同的雲上（當然，配置可以不同）。邏輯上，要實現應用的可移植性，則應用中不應包含任何與雲平臺相關的代碼，那些代碼需要完全下沉到雲平臺中，實現與應用與雲平臺的完全解耦。要做到那些代碼在所有的雲平臺上都可用，則需要相關的基礎技術是被所有云廠商採納的，這是一項技術是否是“事實標準”的關鍵。
對於客戶來說，實現應用移植性的價值在於，除了解決防止被雲廠商鎖定的問題，還讓自由搭配各雲廠商上的技術和成本優勢成爲了可能。對於那些關係到國計民生的國家級或國際化發展的應用來說，也讓滿足多雲部署的政策合規要求變得簡單。
整個雲原生技術所關注的都是通過降本增效，以更好、更快、更經濟的方式去幫助客戶創造價值，這一點也是分佈式應用的終極技術挑戰。
上圖的左側，作者列出了 CNCF 對於雲原生的官方中文定義，其中使用橙色和紅色高亮的內容，與作者在這裏所表達的核心驅動力和所解決的本質問題是同意但不同樣的表達。
雲原生的技術趨勢
簡單說來，雲原生的技術趨勢是圍繞應用的可移植性問題，以一致性爲目的，通過分層去解決。上圖的左側列出了五個層次，右側則示例了對應的部分開源軟件。最上層的 Cloud Portability 與前面講的應用的移植性是同一回事。
圖中存在 Service Portability 和 Network Portability 兩個不同的層。前者解決的是 OSI 網絡層次模型中 4 到 7 層的可移植性問題，比如 Service Mesh 的開源軟件 Istio 所解決的就是這個層次的問題；後者解決的是 2 至 3 層的網格連通性問題，開源的 Network Service Mesh 就是專注於這一層。從 Network Portability 的角度，未來的網絡連通性不再是用 IP 和網絡掩碼去描述，而將採用類似 RPC 中的服務註冊與發現那樣，基於被部署的應用的 YAML 文件中所描述的網絡要求去構建。
與雲原生同行
在雲原生的技術大潮下，作者從應用開發者和雲平臺開發者的角度給出一些建議。
從應用開發者的角度，首先應儘量以 Kubernetes 爲底座去部署應用。Kubernetes 使得應用的部署與運維較上一代的方式輕鬆且不易出錯，相信圍繞着 Kubernetes 所構建的雲原生生態會有更多的技術紅利可以享受到。其次，儘量採用 CNCF Landscape 中的開源軟件去構建自己的分佈式應用體系。CNCF Landscape 中的項目大多有很好的社區活躍度，也圍繞着雲原生這個大圖在發展，其豐富度和成熟度能避免少走很多彎路和杜絕沒有必要的重複建設。最後，讓所開發的應用努力做到無狀態、輕量化和鬆耦合。在雲原生的時代背景下，光開發一個功能正常的應用是不夠的，還得很好地思考應用的可移植性等內容，這是跟上技術發展步伐和更新自身知識體系的必經途徑。
對於雲平臺開發者來說，第一個建議是應全面基於 CNCF Landscape 中的項目去打造雲平臺。雲原生的出現對於雲廠商過去自建的基礎設施是一次很大的顛覆與打擊，不少雲原生技術的設計因爲格局更高而更優，面對這一情形下應果斷地放棄自建的，當開源的滿足不要自己的需要時考慮參與開源去共建。當然，如果發現自建的產品可以豐富 CNCF Landscape，則可以考慮貢獻給 CNCF，通過做大做強去變成事實標準而增強技術影響力。
第二個建議是圍繞“三性”去找發力點。雲原生概念的提出，讓不少雲平臺開發者覺得困惑，因爲太抽象而使得每個人的理解不同而無法聚焦討論，進一步導致不好找發力點。今天的雲原生仍圍繞着核心驅動力和“三性”在動態發展，隨着發展的深入將變得愈加具象。在這種情形下，雲平臺開發者應當圍繞這幾個要素去審視自己的技術路徑是否是雲原生的，避免出現發展偏離。
第三個建議是“借力開源，反哺開源”。借力開源是爲了避免重新發明輪子所帶來的勞命傷財。如果開源社區已有一個和自建的相似的產品，作者建議要好好地思考自建的與開源的兩者之間的關係是什麼。是完全放棄自建的，還是將自建的貢獻給開源社區，這可以基於兩者的差異化去做決定（當然還得看 CNCF 是否接收）。如果發現開源的功能和性能比自己所需存在差距，應當考慮對開源的進行增強，並將增強的功能反哺回開源社區。通過這樣的形式參與到開源社區的建設去讓“雲原生”變得更加具象。真有技術實力，應當自信於放棄自己的，通過投身開源去打造技術影響力。
最後一點建議是努力不要讓自己的技術對客戶產生鎖定。對於平臺性技術，客戶對於技術鎖定是非常敏感的，一旦採用鎖定的思路去做產品就會讓用戶放棄選擇。當然，如果是非平臺性技術，鎖定問題就並不存在而無需擔心。
Kubernetes、Service Mesh 和 Serverless
這張圖能幫助我們理解 Kubernetes 和 Serverless 的位置關係。Kubernetes 今天仍在發展，包含了 CaaS 和 PaaS 兩大塊的內容，且有做厚的趨勢。平臺技術做厚的好處在於，會對下面的基礎技術的演進有更強的掌控力，也會因爲做厚而使得上面的應用變輕，讓應用更加聚焦於業務邏輯本身而無需過於關心解決分佈式應用連接、安全、控制和遙測等共性問題。上圖還展示了 service 這個概念從 IaaS 貫穿至 PaaS 層，讓層與層之間因爲 service 這個概念而能流暢地銜接，從軟件設計的角度體現優雅與一致性。這張圖中並沒有看到 Service Mesh 的影子，下圖以另一種視角進行了展示。
圖中示例了數據平面和控制平面。Service Mesh 的 Sidecar 形成了連接 PaaS 和 SaaS 兩層服務的數據總線，能方便地完成位於這兩層服務的互聯互通（即服務註冊與發現），結合控制平面，實現所有服務的控制（流量灰度、限流、熔斷、降級等）、觀測（日誌、指標和調用鏈路跟蹤），以及服務與服務之間的安全保障。控制平面則貫穿了所有層，是整個分佈式生態系統的控制中樞。圖中並沒有示例出另外兩個同樣重要的開發平面和運維平面。
Kubernetes、Service Mesh 和 Serverless 三者共同演繹不同層次的封裝和向上屏蔽下面的細節。Kubernetes 引入了不同的設計模式，實現對各種雲資源全新、有效和優雅的抽象和管理模式，讓集羣的管理和應用發佈變成了件相當輕鬆且不易出錯的事。
被廣泛採用的微服務軟件架構將分佈式應用的各種複雜度遷移到了服務之間，如何通過全局一致、體系化、規範化和無侵入的手段進行治理就變成了微服務軟件架構下至關重要的內容。Service Mesh 通過將各服務所共用和與環境相關的內容剝離到部署於每個服務邊上的 Sidecar 進程而輕鬆地做到了。這一剝離動作使得服務與平臺能充分解耦而方便各自演進與發展，也使得服務變輕而有助於改善服務啓停的及時性。
雲原生是天然支持多語言的——各技術團隊可以使用自己最善長、最高效的編程語言去創造業務價值和做業務探索。Service Mesh 因爲將那些服務治理相關的邏輯剝離到了 Sidecar 中且作爲獨立進程，所以 Sidecar 所實現的功能天然地支持多語言，爲上面的服務採用多語言開發創造了更爲有利的條件。
通過 Service Mesh 對整個網絡的服務流量進行技術收口，讓異地多活這樣涉及流量調度的系統工程實現起來更加優雅、簡潔與有效，也能更加方便地實現服務版本升級時的灰度、回滾而改善安全生產質量。由於技術收口，給服務流量的治理和演進、排錯、日誌採集的經濟性等疑難問題創造了新的發展空間。
Serverless 對客戶的最大價值有兩點。其一，將資本支出（CAPEX）變成了運營成本（OPEX），且能很好地解決業務“估不准問題”。Serverless 採用更精確地根據業務量所消耗的資源去支付費用，無需在事先估計業務量而先採購好計算資源。傳統的通過預估業務峯值採購計算資源的方式下，如果業務量估高了就會造成採購多餘的資源而帶來浪費，如果業務量估少了又會使得業務價值無法最大化而讓營收變窄。Serverless 從技術層面做到了可以在毫秒級實現計算資源擴容而很好地應對業務流量的波動。
其二，省去了高昂的運維成本。Serverless 由於是免服務器運維的，所以不需要配置相應的人員去運維服務器。Serverless 的整個解決方案通過封裝向開發者屏蔽了大量的技術細節，讓開發者可以專注於業務邏輯而帶去更高的開發效率和縮短業務上線時間。可以預見，Serverless 是彈性、易用性和移植性的重要落地形式。
有部分人對 Service Mesh 和 Serverless 存在這樣的困惑：有了 Serverless 之後還需要 Service Mesh 嗎？作者看來，兩都並非矛盾體。Service Mesh 是解決微服務軟件架構下服務與服務之間複雜度問題的，只要採納了微服務軟件架構就應當使用 Service Mesh。Serverless 解決的是免服務器運維的問題，一個運用於微服務軟件架構的 Serverless 解決方案，應當包含 Service Mesh 的內容，只不過對於終端的開發者很可能感知不到而已。
Distributionless 的內涵及發展趨勢
雲原生是分佈式應用當下重要的發展路徑，其終態應當是 Distributionless。背後的含義有兩點。首先，所有與分佈式相關的問題由雲平臺解決。換句話說，基於雲平臺做二次開發的開發者無需掌握底層複雜的技術與概念就能高效地開發、部署和發佈應用。雲平臺會提供各種工具作爲腳手架，幫助開發者去發現問題、診斷、排錯和做資源編排等工作。其二，分佈式應用的開發會跟傳統應用的開發一樣方便，甚至更加便捷。信息流動的效率與充分度是很多創新的重要因素，互聯網天然具有這些優勢，這種優勢一定會讓分佈式應用的開發效率持續得到巨大改善。
Distrubutionless 的發展趨勢是：
-
平臺變厚、變重、變標準，應用變薄、變輕。分佈式應用的複雜度無論用什麼技術方案都是存在的，關鍵在於如何解和在哪兒解。邏輯上，將複雜度下沉到平臺纔是正道，這就帶來了平臺變厚和重、應用變薄和輕的結果。沿着雲原生的路徑，只有平臺標準化才能最終實現應用的可移植性。
-
數據平面網格化。分佈式應用從單體走向微服務軟件架構，所隱含的思路是數據平面應當網格化。服務網格作爲雲原生的關鍵技術，未來一定存在不同應用對於網格的定製需求，不同應用定製所帶來的開銷應當由應用所在的機器承擔，而不能轉嫁給其他應用，唯有網格化才能實現資源使用在應用級別的資源隔離（不同的應用加載實現不同定製邏輯的插件）。類似 RSocket 這樣採用集中 Broker 的技術根本無法滿足這一要求。數據平面的最大挑戰在於如何隔離好業務對數據平面的定製化要求，以及如何做到路徑無損。後者是指，在增加 Sidecar 的情形下，通過技術創新實現 RT 和資源佔用趨於零。
-
控制平面集中化。數據平面與控制平面是孿生兄弟，一個“形散”的數據平面需要有一個“神不散”的控制平面去幫助實現全局治理。控制平面的技術挑戰在於如何在最短的時間內，將整個集羣的相關控制信息推送到數據平面。
-
運維平面產品化。產品化水平的高低代表了未來分佈式應用運維便利性和應急響應的及時性。產品化過程中對概念的抽象和人機交互的設計，代表了雲平臺廠商對分佈式應用開發這一專業領域的洞見和最佳實踐，也表達了雲廠商對使用技術的人性化的認知深度。產品化工作一定不是以圖形化的人機交互方式去表達技術細節，而是爲用戶塑造一套讓人容易理解和掌握的心智模式。
-
開發平面無縫整合。開發平面由分佈式應用的開發者日常工作所應遵守的流程組成，包含代不限於需求與任務分解、概要設計、編碼、單元測試、集成測試、代碼管理、軟件打包和發佈等內容。開發平面如何做到以開發者爲中心，使他能流暢而高效地開展自己的工作是關鍵挑戰。此外，開發平面的設計需要對高效軟件開發的方法論有很好的梳理與表達，且能踐行行業的一些共識實踐。比如，能方便地實現需求的可溯和軟件缺陷的跟蹤。
對於雲平臺廠商來說，Distributionless 的關鍵競爭力來自運維平面的產品化和開發平面無縫整合的能力。這兩塊是直接觸達客戶和用戶體現技術以更快、更好交付客戶價值的關鍵。相信“體驗爲王”在未來分佈式應用領域同樣適用。
更多關於國內外一流技術團隊的實踐案例請持續關注 QCon 全球軟件開發大會，上海站內容正在籌備中，涵蓋大數據、架構、移動、微服務、工程效率、運維、前端等經典方向及 Cloud Native、中臺、圖數據庫、下一代計算等新興方向。點擊 QCon官網或識別二維碼來 QCon 上海 2019 瞭解行業專家分享有實戰價值的高頻交易系統落地實例，從技術層面解析高頻交易系統的設計、架構和實現。大會 8 折報名中，立減 1760 元，有任何問題歡迎聯繫票務小姐姐 Ring：17310043226（微信同號）
