精彩觀點導讀：
? 我們去探索一項技術，并不會僅僅因為其先進性，而是因為我們目前遇到了一些無法解決的問題，而這項技術正好能解決這個問題。

? 所有軟件最重要的使命不是滿足功能要求，而是演進，從而持續成長。

? 微服務本質是對服務的拆分，微服務架構符合工程領域常用的“分而治之”范式。

?

近日，在Aliware Open Source?成都站-Apache Dubbo 開發者沙龍上，阿里巴巴中間件高級技術專家李云（至簡）向開發者們分享了阿里巴巴中間件團隊在Service Mmesh領域的探索和最新實踐。本文是根據至簡的現場分享所整理，為大家回顧分享中的精彩內容。

嘉賓介紹：李云（至簡），阿里巴巴中間件高級技術專家，是阿里巴巴集團Service Mesh方向的重要參與者和推動者。

“阿里巴巴中間件”公眾號后臺發送“成都沙龍PPT”，下載全場PPT。

“阿里巴巴中間件”公眾號后臺發送“成都沙龍視頻”，進行回看。

我們去探索一項技術，并不會僅僅因為其先進性，而是因為我們目前遇到了一些無法解決的問題，而這項技術正好能解決這個問題。現在，阿里巴巴整個集團業務的體量很大，在技術上會遇到很多的挑戰。而正是因為這些挑戰，讓我們思考通過哪些新技術可以去解決這些痛點，這也是我們在Service Mesh領域進行探索和實踐的出發點。首先，我們先來看看自己遇到了哪些挑戰。

一、微服務的5大挑戰

第一個挑戰是微服務框架自身演進困難。

任何軟件都會有他的生命進化曲線，從最初的萌芽，進入形成期，往上發展，再進入平臺期，最后進入衰亡期。當然我們希望我們的軟件可以在進入平臺期后，能借助某次演進進入新的發展期。從這個維度看，所有軟件最重要的使命不是滿足功能要求，而是演進，從而持續成長。相反，當某個軟件無法演進的時候，就會意味著死亡。但軟件的演進并不是一個簡單的事情，以微服務框架為例，為了進一步提升雙11期間整個中間件平臺的穩定性，我們會修改若干個功能，并以SDK的方式去提供給業務方，但業務代碼和微服務框架SDK是強耦合的，這時候需要我們推動各個業務方和我們一同去做升級。雖然我們的初衷是實現平臺穩定性的提升，幫助業務更好的發展，但這時由于大家的出發點和訴求有所不同，業務方和我們一起去做升級是比較困難的。所以要發展微服務框架，首先遇到的挑戰就是演進困難。

第二個挑戰是微服務框架SDK多語言并行開發與維護成本高。

以前我們都是通過對技術棧的統一來提升成本優勢和團隊效率，大家可以用一種語言去開發和維護，避免多語言時團隊的不聚焦。但在軟件和開源生態演進的過程中，多語言已經成為一種流行，因為不同語言都有其自身的優勢，今天大家能看到的一個現象是云原生的生態中有多種開發語言，使用頻率最高的語言已經不是Java了，而是Go，是因為Go的footprint很小。再以 Dubbo為例，除了Java，我們還提供C++，Node.js的SDK，以便讓更多的開發者可以加入Dubbo生態，但所有的這些，如果沒有社區力量的參與，是很難維持的。

第三個挑戰是異構服務框架難以共存完成漸進式演進。

我們結合場景來看看這個挑戰。阿里巴巴收購了一些企業，被收購企業的技術棧可能和阿里巴巴不同，比如有些用的是Go語言，有些用的是PHP，這時候為了統一技術棧，我們需要對這類技術平臺推倒重來，但這個過程中，我們會面臨一系列問題，首當其沖的就是推倒重來會帶來巨大的技術風險，其次是可能會面臨技術人員大批量流失的風險，這在社會責任的層面也是很難接受。所以我們在尋求一種可能的方案，去解決這類問題。

第四個挑戰是單一的語言限制了人才的多樣性。

這里，我們不去爭論某個編程語言的好與壞，每個語言都有其適用場景，你不能說我手里有個榔頭，你面對的都是釘子。以前我們覺得統一技術棧可以集中開發力量，并且帶來較高的運維便利性。但伴隨著互聯網帶來的快節奏，以往的團隊能力設置已經很難滿足這類變化，對工程師個體提出了更高的要求，我們不僅僅需要是某一方面的專家，而且還需要具備多域的工作技能，DevOps和全棧工程師就是這類快節奏變化下最好的注腳。

第五個挑戰是點狀的服務治理難以做到及時、有效和經濟。

微服務和架構的核心是拆分，通過拆分，讓每個模塊可以獨立運行，跟上業務的發展速度，持續推動業務的創新。但拆完后新的問題出來了，缺少橫向的內容拉通所有獨立的煙囪，從而在服務治理上帶來極大的挑戰。

二、分布式應用的4大發展趨勢

1. 微服務會成為大規模分布式應用的主流架構。

任何復雜的工程問題都會歸結為devide and conquer（分而治之），意思就是就是把一個復雜的問題分成兩個或更多的相同或相似的子問題，再把子問題分成更小的子問題……直到最后子問題可以簡單的直接求解，原問題的解即子問題的解的合并。微服務本質是對服務的拆分，與工程領域慣用的“分而治之”的思路是一致的。

2. 微服務架構下應用的開發是多語言的。

沒有一個語言是一家獨大的，每種語言在特定場景下都有其自身的優勢，我們希望這種優勢能夠將技術到產品的周期（time to market）縮短。技術的核心在于創造價值，無論是交付給客戶，還是服務于整個社會。因此，微服務是需要不同語言的開發者發揮自身的優勢，去進一步完善我們的微服務架構，釋放技術價值。

3. 數據安全將成為公有云分布式應用的生命線。

云原生時代，業務即便沒上云，企業對自身數據的安全都是有訴求的，尤其是在金融行業，如果通過抓包就能獲取一些敏感信息，這將會給企業帶來巨大的風險。

4. Cloud native成為distributionless（無分布式）的主要探索路徑。

分布式發展的終極形式是無分布式，在未來我們做開發，所有的代碼在web上寫好后，通過點擊一個按鈕，所有部署都會自動實現，所有的code review的工作可以在一個統一的工作臺上全部實現。

?成都站開發者沙龍現場

5. 以更快的速度，通過構建軟件去探索新業務。

工程師服務的是客戶，通過技術輸出來實現技術價值，以互聯網的架構幫助賦能傳統企業，幫助企業獲得差異化競爭力。

三、什么是 Service Mesh

Service Mesh是層次化、規范化、體系化、無侵入的分布式服務治理技術平臺。

層次化

分為數據面和控制面兩個概念，數據面是指所有數據流動的那個層面，控制面是用來控制這個數據面的，對服務去做處理。對數據面和控制面進行分層，帶來的好處是，針對一個復雜的系統進行切分，可以獲得更清晰的認識，這和devide and conque是同一個理念。

規范化

是指通過標準協議完成數據平面和控制平面的連接，同時，sidecar成為所有traffic互聯、互通的約束標準。

體系化

包含兩個維度，一是指observability全局考慮。目前在整個分布式治理過程中的最大挑戰是：logging、metrics、tracing這三個observability領域的核心內容缺少體系性的關注。另一個是集中管理的維度，包括服務管理、限流、熔斷、安全、灰度在內的服務模塊都可以在獲得體系化的呈現，每個服務都可以被看到，而非團隊a只看限流，團隊b只看logging，需要一種技術能力拉通所有的服務模塊，這個體系化這個角度看，Service Mesh是一個理想的技術方案。

無侵入

是指我們希望通過無侵入，當新增一個業務的時候，不需要考慮一個SDK去初始化，而是可以通過sidecar的進程方式來解耦。

四、Service Mesh 的形態

我們從三個維度對比的來看 ServiceMesh 的形態。

圖中左邊是傳統的微服務形態，調用者和被調用者是通過一個SDK的方式來實現共享服務的，以Dubbo為例，我們會在SDK里提供服務路由、服務發現等功能，雖然我們的開發者在做應用開發的時候并不會太關注SDK的構成，但這些功能是面臨不斷被變更的可能，有著比較重的邏輯。在右邊Service Mesh的形態中，我們首先會對厚重的SDK進行分解，將復雜的邏輯下沉到sidecar，借助sidecar來實現服務的調用。

雖然在Service Mesh的形態，調用路徑要長于傳統的形態，路徑越長消耗越大，對性能影響越大。但在當前的分布式應用的治理過程中，易用性已經成為一個比性能更重要的話題。當我們給客戶部署一套微服務，即便性能很強，但沒有處理好易用性問題的話，這將會給技術的推廣帶來巨大的阻礙，不僅是會影響外部的客戶，也會影響內部的用戶，如何實現喝著咖啡從容應對雙11，必須先解決易用性的問題。在解決易用性問題后，沿著技術的發展路徑再去解決性能問題。

Service Mesh的形態中的control plan不會導致重復建設，但在shared service是有可能存在重復建設的。

五、Service Mesh 下的應用架構

無論是單體應用，還是分布式應用，都可以建立在Service Mesh上，mesh上的sidecar支撐了所有的上層應用，業務開發者無須關心底層構成，可以用Java，也可以用Go等語言完成自己的業務開發。

六、Service Mesh 的價值

• 為單體應用向微服務架構演進提供了漸進的途徑
• 為異構（微）服務框架/平臺提供了融合發展的可能

? 被收購子公司與母公司的業務可以融合發展

• 加速（微）服務框架/平臺自身的演進
• 讓業務開發同學聚焦于業務邏輯本身
• 業務開發時無需關心安全、灰度、限流、熔斷等通用的技術內容
• 培育了多語言業務開發的土壤

? 助力人才發展中編程語言的多樣性

• 對（異構）微服務架構應用實現更為有效的全局一體化監管控

七、Dubbo Mesh 的發展思路

• 迎合Kubernetes已成orchestrator王者的大勢
• 開源版本與阿里巴巴集團內版本統一
• 與領域主流開源項目形成合力發展，源于開源、反哺開源

八、Dubbo Mesh 的進展

Dubbo Proxy

• Envoy支持Dubbo協議，分兩個迭代完成

迭代一：實現對Dubbo協議的解析和統計信息收集（代碼已提交給社區review）
迭代二：支持服務路由（規劃中）

Dubbo Control

• 豐富Istio/Pilot-discovery

已完成與VIPServer、Diamond的對接

正規劃與ZooKeeper、Nacos的對接

• 仍在規劃Istio/Mixer部分

九、成都沙龍 Q&A

Q1: 阿里巴巴是怎么從微服務過渡到sidecar模式，再過渡到Service Mesh？

整個過渡是漸進式的，我們會將控制平面的一些組件先下沉到與sidecar部署在一起，這一下沉能很好復用開源軟件已有的能力而減少開發工作量。當這一步驟完成后，被下沉的控制面組件會重新拉回到上面的控制面，那時就會面臨一定的服務端改造，一旦改造完成就有了一個全新、完整的Service Mesh。

Q2: Service Mesh中的服務注冊發現，負載均衡，網關，熔斷降級，超時，限流，消息總線，分布式配置，這些都是怎么實現的？

Dubbo Mesh在控制面會基于Istio去做，而Istio已經具備了Kubernetes下的服務注冊與發現能力，我們要做的是擴充Istio的能力，讓服務注冊與發現能與ZooKeeper、Nacos進行對接去完成。基于開源的Envoy所實現的sidecar已實現了超時處理的功能，相應的內容可以讀代碼去了解。其他內容我們仍在規劃中。

Q3: Dubbo Mesh目前性能怎么樣? 增加一層sidecar導致Dubbo的RT有多少？

在使用iptables的情形下，一跳增加1.5毫秒，如果不采用iptables直接proxy方式的情形下應當性能更好（這一點與Lyft也郵件確認過了），我們接下來會做更多的性能測試，目前的焦點更多在于功能層面。

Q4: Dubbo Mesh是把雙刃劍，經過的鏈路更復雜，運維和開發者問題排查有沒有更有效的工具？
**
理論上，增加一跳并沒有改變服務調用的拓撲結構，但確實會增加復雜度，這個應當通過設計實現去解決。好在因為是一體化的方案，所以解決這類問題時需要更具全局視野。**

?成都站開發者提問

Q5: Service Mesh中控制面板也用C++嗎？我看主流很多實現都是Go， 我相信大佬做過技術調研，有哪些優勢？

控制面是復用Istio的，是Go語言的。我們力爭不重復造輪子，而是以開放的心態去共建。

Q6: Client做解碼和反序列化是吧，有計劃支持HTTP2協議嗎？

Envoy默認就支持了，不需我們開發。這也是借力開源的收益。

Q7: Dubbo Mesh已經支持domain socket了嗎？

目前不支持，這個還處于意向階段。

?

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的Dubbo Mesh | 阿里巴巴中间件团队在 Service Mesh 的实践和探索（附PPT）的全部內容，希望文章能夠幫你解決所遇到的問題。

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