Dubbo Mesh | 阿里巴巴中間件團隊在 Service Mesh 的實踐和探索（附PPT）

精彩觀點導讀：
» 咱們去探索一項技術，並不會僅僅由於其先進性，而是由於咱們目前遇到了一些沒法解決的問題，而這項技術正好能解決這個問題。

» 全部軟件最重要的使命不是知足功能要求，而是演進，從而持續成長。

» 微服務本質是對服務的拆分，微服務架構符合工程領域經常使用的「分而治之」範式。

 

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

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

「阿里巴巴中間件」公衆號後臺發送「成都沙龍PPT」，下載全場PPT。

「阿里巴巴中間件」公衆號後臺發送「成都沙龍視頻」，進行回看。

咱們去探索一項技術，並不會僅僅由於其先進性，而是由於咱們目前遇到了一些沒法解決的問題，而這項技術正好能解決這個問題。如今，阿里巴巴整個集團業務的體量很大，在技術上會遇到不少的挑戰。而正是由於這些挑戰，讓咱們思考經過哪些新技術能夠去解決這些痛點，這也是咱們在Service Mesh領域進行探索和實踐的出發點。首先，咱們先來看看本身遇到了哪些挑戰。

1、微服務的5大挑戰

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

任何軟件都會有他的生命進化曲線，從最初的萌芽，進入造成期，往上發展，再進入平臺期，最後進入衰亡期。固然咱們但願咱們的軟件能夠在進入平臺期後，能借助某次演進進入新的發展期。從這個維度看，全部軟件最重要的使命不是知足功能要求，而是演進，從而持續成長。相反，當某個軟件沒法演進的時候，就會意味着死亡。但軟件的演進並非一個簡單的事情，以微服務框架爲例，爲了進一步提高雙11期間整個中間件平臺的穩定性，咱們會修改若干個功能，並以SDK的方式去提供給業務方，但業務代碼和微服務框架SDK是強耦合的，這時候須要咱們推進各個業務方和咱們一同去作升級。雖然咱們的初衷是實現平臺穩定性的提高，幫助業務更好的發展，但這時因爲你們的出發點和訴求有所不一樣，業務方和咱們一塊兒去作升級是比較困難的。因此要發展微服務框架，首先遇到的挑戰就是演進困難。

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

之前咱們都是經過對技術棧的統一來提高成本優點和團隊效率，你們能夠用一種語言去開發和維護，避免多語言時團隊的不聚焦。但在軟件和開源生態演進的過程當中，多語言已經成爲一種流行，由於不一樣語言都有其自身的優點，今天你們能看到的一個現象是雲原生的生態中有多種開發語言，使用頻率最高的語言已經不是Java了，而是Go，是由於Go的footprint很小。再以 Dubbo爲例，除了Java，咱們還提供C++，Node.js的SDK，以便讓更多的開發者能夠加入Dubbo生態，但全部的這些，若是沒有社區力量的參與，是很難維持的。

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

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

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

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

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

微服務和架構的核心是拆分，經過拆分，讓每一個模塊能夠獨立運行，跟上業務的發展速度，持續推進業務的創新。但拆完後新的問題出來了，缺乏橫向的內容拉通全部獨立的煙囪，從而在服務治理上帶來極大的挑戰。

2、分佈式應用的4大發展趨勢

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

任何複雜的工程問題都會歸結爲devide and conquer（分而治之），意思就是就是把一個複雜的問題分紅兩個或更多的相同或類似的子問題，再把子問題分紅更小的子問題……直到最後子問題能夠簡單的直接求解，原問題的解即子問題的解的合併。微服務本質是對服務的拆分，與工程領域慣用的「分而治之」的思路是一致的。

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

沒有一個語言是一家獨大的，每種語言在特定場景下都有其自身的優點，咱們但願這種優點可以將技術到產品的週期（time to market）縮短。技術的核心在於創造價值，不管是交付給客戶，仍是服務於整個社會。所以，微服務是須要不一樣語言的開發者發揮自身的優點，去進一步完善咱們的微服務架構，釋放技術價值。

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

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

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

分佈式發展的終極形式是無分佈式，在將來咱們作開發，全部的代碼在web上寫好後，經過點擊一個按鈕，全部部署都會自動實現，全部的code review的工做能夠在一個統一的工做臺上所有實現。

▵成都站開發者沙龍現場

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

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

3、什麼是 Service Mesh

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

層次化

分爲數據面和控制面兩個概念，數據面是指全部數據流動的那個層面，控制面是用來控制這個數據面的，對服務去作處理。對數據面和控制面進行分層，帶來的好處是，針對一個複雜的系統進行切分，能夠得到更清晰的認識，這和devide and conque是同一個理念。

規範化

是指經過標準協議完成數據平面和控制平面的鏈接，同時，sidecar成爲全部traffic互聯、互通的約束標準。

體系化

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

無侵入

是指咱們但願經過無侵入，當新增一個業務的時候，不須要考慮一個SDK去初始化，而是能夠經過sidecar的進程方式來解耦。

4、Service Mesh 的形態

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

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

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

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

5、Service Mesh 下的應用架構

不管是單體應用，仍是分佈式應用，均可以創建在Service Mesh上，mesh上的sidecar支撐了全部的上層應用，業務開發者無須關心底層構成，能夠用Java，也能夠用Go等語言完成本身的業務開發。

6、Service Mesh 的價值

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

Ø 被收購子公司與母公司的業務能夠融合發展

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

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

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

7、Dubbo Mesh 的發展思路

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

8、Dubbo Mesh 的進展

Dubbo Proxy

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

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

Dubbo Control

• 豐富Istio/Pilot-discovery

已完成與VIPServer、Diamond的對接

正規劃與ZooKeeper、Nacos的對接

• 仍在規劃Istio/Mixer部分

9、成都沙龍 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了嗎？

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