分布式應用的未來 — 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 的關鍵競争力來自運維平面的産品化和開發平面無縫整合的能力。這兩塊是直接觸達客戶和使用者展現技術以更快、更好傳遞客戶價值的關鍵。相信“體驗為王”在未來分布式應用領域同樣适用。