作者丨阿里云高級技術專家 至簡（李云）

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

總結

以上是生活随笔為你收集整理的分布式应用的未来 — Distributionless的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。