分佈式應用的將來 — Distributionless

做者丨阿里雲高級技術專家 至簡（李雲）

在技術變革推進社會發展這一時代背景下，大量支撐規模化分佈式應用的技術創新、創造與創業應用而生，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 的關鍵競爭力來自運維平面的產品化和開發平面無縫整合的能力。這兩塊是直接觸達客戶和用戶體現技術以更快、更好交付客戶價值的關鍵。相信「體驗爲王」在將來分佈式應用領域一樣適用。