精彩觀點(diǎn)導(dǎo)讀：
? 我們?nèi)ヌ剿饕豁?xiàng)技術(shù)，并不會(huì)僅僅因?yàn)槠湎冗M(jìn)性，而是因?yàn)槲覀兡壳坝龅搅艘恍o(wú)法解決的問(wèn)題，而這項(xiàng)技術(shù)正好能解決這個(gè)問(wèn)題。

? 所有軟件最重要的使命不是滿足功能要求，而是演進(jìn)，從而持續(xù)成長(zhǎng)。

? 微服務(wù)本質(zhì)是對(duì)服務(wù)的拆分，微服務(wù)架構(gòu)符合工程領(lǐng)域常用的“分而治之”范式。

?

近日，在Aliware Open Source?成都站-Apache Dubbo 開(kāi)發(fā)者沙龍上，阿里巴巴中間件高級(jí)技術(shù)專家李云（至簡(jiǎn)）向開(kāi)發(fā)者們分享了阿里巴巴中間件團(tuán)隊(duì)在Service Mmesh領(lǐng)域的探索和最新實(shí)踐。本文是根據(jù)至簡(jiǎn)的現(xiàn)場(chǎng)分享所整理，為大家回顧分享中的精彩內(nèi)容。

嘉賓介紹：李云（至簡(jiǎn)），阿里巴巴中間件高級(jí)技術(shù)專家，是阿里巴巴集團(tuán)Service Mesh方向的重要參與者和推動(dòng)者。

“阿里巴巴中間件”公眾號(hào)后臺(tái)發(fā)送“成都沙龍PPT”，下載全場(chǎng)PPT。

“阿里巴巴中間件”公眾號(hào)后臺(tái)發(fā)送“成都沙龍視頻”，進(jìn)行回看。

我們?nèi)ヌ剿饕豁?xiàng)技術(shù)，并不會(huì)僅僅因?yàn)槠湎冗M(jìn)性，而是因?yàn)槲覀兡壳坝龅搅艘恍o(wú)法解決的問(wèn)題，而這項(xiàng)技術(shù)正好能解決這個(gè)問(wèn)題。現(xiàn)在，阿里巴巴整個(gè)集團(tuán)業(yè)務(wù)的體量很大，在技術(shù)上會(huì)遇到很多的挑戰(zhàn)。而正是因?yàn)檫@些挑戰(zhàn)，讓我們思考通過(guò)哪些新技術(shù)可以去解決這些痛點(diǎn)，這也是我們?cè)赟ervice Mesh領(lǐng)域進(jìn)行探索和實(shí)踐的出發(fā)點(diǎn)。首先，我們先來(lái)看看自己遇到了哪些挑戰(zhàn)。

一、微服務(wù)的5大挑戰(zhàn)

第一個(gè)挑戰(zhàn)是微服務(wù)框架自身演進(jìn)困難。

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

第二個(gè)挑戰(zhàn)是微服務(wù)框架SDK多語(yǔ)言并行開(kāi)發(fā)與維護(hù)成本高。

以前我們都是通過(guò)對(duì)技術(shù)棧的統(tǒng)一來(lái)提升成本優(yōu)勢(shì)和團(tuán)隊(duì)效率，大家可以用一種語(yǔ)言去開(kāi)發(fā)和維護(hù)，避免多語(yǔ)言時(shí)團(tuán)隊(duì)的不聚焦。但在軟件和開(kāi)源生態(tài)演進(jìn)的過(guò)程中，多語(yǔ)言已經(jīng)成為一種流行，因?yàn)椴煌Z(yǔ)言都有其自身的優(yōu)勢(shì)，今天大家能看到的一個(gè)現(xiàn)象是云原生的生態(tài)中有多種開(kāi)發(fā)語(yǔ)言，使用頻率最高的語(yǔ)言已經(jīng)不是Java了，而是Go，是因?yàn)镚o的footprint很小。再以 Dubbo為例，除了Java，我們還提供C++，Node.js的SDK，以便讓更多的開(kāi)發(fā)者可以加入Dubbo生態(tài)，但所有的這些，如果沒(méi)有社區(qū)力量的參與，是很難維持的。

第三個(gè)挑戰(zhàn)是異構(gòu)服務(wù)框架難以共存完成漸進(jìn)式演進(jìn)。

我們結(jié)合場(chǎng)景來(lái)看看這個(gè)挑戰(zhàn)。阿里巴巴收購(gòu)了一些企業(yè)，被收購(gòu)企業(yè)的技術(shù)棧可能和阿里巴巴不同，比如有些用的是Go語(yǔ)言，有些用的是PHP，這時(shí)候?yàn)榱私y(tǒng)一技術(shù)棧，我們需要對(duì)這類技術(shù)平臺(tái)推倒重來(lái)，但這個(gè)過(guò)程中，我們會(huì)面臨一系列問(wèn)題，首當(dāng)其沖的就是推倒重來(lái)會(huì)帶來(lái)巨大的技術(shù)風(fēng)險(xiǎn)，其次是可能會(huì)面臨技術(shù)人員大批量流失的風(fēng)險(xiǎn)，這在社會(huì)責(zé)任的層面也是很難接受。所以我們?cè)趯で笠环N可能的方案，去解決這類問(wèn)題。

第四個(gè)挑戰(zhàn)是單一的語(yǔ)言限制了人才的多樣性。

這里，我們不去爭(zhēng)論某個(gè)編程語(yǔ)言的好與壞，每個(gè)語(yǔ)言都有其適用場(chǎng)景，你不能說(shuō)我手里有個(gè)榔頭，你面對(duì)的都是釘子。以前我們覺(jué)得統(tǒng)一技術(shù)棧可以集中開(kāi)發(fā)力量，并且?guī)?lái)較高的運(yùn)維便利性。但伴隨著互聯(lián)網(wǎng)帶來(lái)的快節(jié)奏，以往的團(tuán)隊(duì)能力設(shè)置已經(jīng)很難滿足這類變化，對(duì)工程師個(gè)體提出了更高的要求，我們不僅僅需要是某一方面的專家，而且還需要具備多域的工作技能，DevOps和全棧工程師就是這類快節(jié)奏變化下最好的注腳。

第五個(gè)挑戰(zhàn)是點(diǎn)狀的服務(wù)治理難以做到及時(shí)、有效和經(jīng)濟(jì)。

微服務(wù)和架構(gòu)的核心是拆分，通過(guò)拆分，讓每個(gè)模塊可以獨(dú)立運(yùn)行，跟上業(yè)務(wù)的發(fā)展速度，持續(xù)推動(dòng)業(yè)務(wù)的創(chuàng)新。但拆完后新的問(wèn)題出來(lái)了，缺少橫向的內(nèi)容拉通所有獨(dú)立的煙囪，從而在服務(wù)治理上帶來(lái)極大的挑戰(zhàn)。

二、分布式應(yīng)用的4大發(fā)展趨勢(shì)

1. 微服務(wù)會(huì)成為大規(guī)模分布式應(yīng)用的主流架構(gòu)。

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

2. 微服務(wù)架構(gòu)下應(yīng)用的開(kāi)發(fā)是多語(yǔ)言的。

沒(méi)有一個(gè)語(yǔ)言是一家獨(dú)大的，每種語(yǔ)言在特定場(chǎng)景下都有其自身的優(yōu)勢(shì)，我們希望這種優(yōu)勢(shì)能夠?qū)⒓夹g(shù)到產(chǎn)品的周期（time to market）縮短。技術(shù)的核心在于創(chuàng)造價(jià)值，無(wú)論是交付給客戶，還是服務(wù)于整個(gè)社會(huì)。因此，微服務(wù)是需要不同語(yǔ)言的開(kāi)發(fā)者發(fā)揮自身的優(yōu)勢(shì)，去進(jìn)一步完善我們的微服務(wù)架構(gòu)，釋放技術(shù)價(jià)值。

3. 數(shù)據(jù)安全將成為公有云分布式應(yīng)用的生命線。

云原生時(shí)代，業(yè)務(wù)即便沒(méi)上云，企業(yè)對(duì)自身數(shù)據(jù)的安全都是有訴求的，尤其是在金融行業(yè)，如果通過(guò)抓包就能獲取一些敏感信息，這將會(huì)給企業(yè)帶來(lái)巨大的風(fēng)險(xiǎn)。

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

分布式發(fā)展的終極形式是無(wú)分布式，在未來(lái)我們做開(kāi)發(fā)，所有的代碼在web上寫(xiě)好后，通過(guò)點(diǎn)擊一個(gè)按鈕，所有部署都會(huì)自動(dòng)實(shí)現(xiàn)，所有的code review的工作可以在一個(gè)統(tǒng)一的工作臺(tái)上全部實(shí)現(xiàn)。

?成都站開(kāi)發(fā)者沙龍現(xiàn)場(chǎng)

5. 以更快的速度，通過(guò)構(gòu)建軟件去探索新業(yè)務(wù)。

工程師服務(wù)的是客戶，通過(guò)技術(shù)輸出來(lái)實(shí)現(xiàn)技術(shù)價(jià)值，以互聯(lián)網(wǎng)的架構(gòu)幫助賦能傳統(tǒng)企業(yè)，幫助企業(yè)獲得差異化競(jìng)爭(zhēng)力。

三、什么是 Service Mesh

Service Mesh是層次化、規(guī)范化、體系化、無(wú)侵入的分布式服務(wù)治理技術(shù)平臺(tái)。

層次化

分為數(shù)據(jù)面和控制面兩個(gè)概念，數(shù)據(jù)面是指所有數(shù)據(jù)流動(dòng)的那個(gè)層面，控制面是用來(lái)控制這個(gè)數(shù)據(jù)面的，對(duì)服務(wù)去做處理。對(duì)數(shù)據(jù)面和控制面進(jìn)行分層，帶來(lái)的好處是，針對(duì)一個(gè)復(fù)雜的系統(tǒng)進(jìn)行切分，可以獲得更清晰的認(rèn)識(shí)，這和devide and conque是同一個(gè)理念。

規(guī)范化

是指通過(guò)標(biāo)準(zhǔn)協(xié)議完成數(shù)據(jù)平面和控制平面的連接，同時(shí)，sidecar成為所有traffic互聯(lián)、互通的約束標(biāo)準(zhǔn)。

體系化

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

無(wú)侵入

是指我們希望通過(guò)無(wú)侵入，當(dāng)新增一個(gè)業(yè)務(wù)的時(shí)候，不需要考慮一個(gè)SDK去初始化，而是可以通過(guò)sidecar的進(jìn)程方式來(lái)解耦。

四、Service Mesh 的形態(tài)

我們從三個(gè)維度對(duì)比的來(lái)看 ServiceMesh 的形態(tài)。

圖中左邊是傳統(tǒng)的微服務(wù)形態(tài)，調(diào)用者和被調(diào)用者是通過(guò)一個(gè)SDK的方式來(lái)實(shí)現(xiàn)共享服務(wù)的，以Dubbo為例，我們會(huì)在SDK里提供服務(wù)路由、服務(wù)發(fā)現(xiàn)等功能，雖然我們的開(kāi)發(fā)者在做應(yīng)用開(kāi)發(fā)的時(shí)候并不會(huì)太關(guān)注SDK的構(gòu)成，但這些功能是面臨不斷被變更的可能，有著比較重的邏輯。在右邊Service Mesh的形態(tài)中，我們首先會(huì)對(duì)厚重的SDK進(jìn)行分解，將復(fù)雜的邏輯下沉到sidecar，借助sidecar來(lái)實(shí)現(xiàn)服務(wù)的調(diào)用。

雖然在Service Mesh的形態(tài)，調(diào)用路徑要長(zhǎng)于傳統(tǒng)的形態(tài)，路徑越長(zhǎng)消耗越大，對(duì)性能影響越大。但在當(dāng)前的分布式應(yīng)用的治理過(guò)程中，易用性已經(jīng)成為一個(gè)比性能更重要的話題。當(dāng)我們給客戶部署一套微服務(wù)，即便性能很強(qiáng)，但沒(méi)有處理好易用性問(wèn)題的話，這將會(huì)給技術(shù)的推廣帶來(lái)巨大的阻礙，不僅是會(huì)影響外部的客戶，也會(huì)影響內(nèi)部的用戶，如何實(shí)現(xiàn)喝著咖啡從容應(yīng)對(duì)雙11，必須先解決易用性的問(wèn)題。在解決易用性問(wèn)題后，沿著技術(shù)的發(fā)展路徑再去解決性能問(wèn)題。

Service Mesh的形態(tài)中的control plan不會(huì)導(dǎo)致重復(fù)建設(shè)，但在shared service是有可能存在重復(fù)建設(shè)的。

五、Service Mesh 下的應(yīng)用架構(gòu)

無(wú)論是單體應(yīng)用，還是分布式應(yīng)用，都可以建立在Service Mesh上，mesh上的sidecar支撐了所有的上層應(yīng)用，業(yè)務(wù)開(kāi)發(fā)者無(wú)須關(guān)心底層構(gòu)成，可以用Java，也可以用Go等語(yǔ)言完成自己的業(yè)務(wù)開(kāi)發(fā)。

六、Service Mesh 的價(jià)值

• 為單體應(yīng)用向微服務(wù)架構(gòu)演進(jìn)提供了漸進(jìn)的途徑
• 為異構(gòu)（微）服務(wù)框架/平臺(tái)提供了融合發(fā)展的可能

? 被收購(gòu)子公司與母公司的業(yè)務(wù)可以融合發(fā)展

• 加速（微）服務(wù)框架/平臺(tái)自身的演進(jìn)
• 讓業(yè)務(wù)開(kāi)發(fā)同學(xué)聚焦于業(yè)務(wù)邏輯本身
• 業(yè)務(wù)開(kāi)發(fā)時(shí)無(wú)需關(guān)心安全、灰度、限流、熔斷等通用的技術(shù)內(nèi)容
• 培育了多語(yǔ)言業(yè)務(wù)開(kāi)發(fā)的土壤

? 助力人才發(fā)展中編程語(yǔ)言的多樣性

• 對(duì)（異構(gòu)）微服務(wù)架構(gòu)應(yīng)用實(shí)現(xiàn)更為有效的全局一體化監(jiān)管控

七、Dubbo Mesh 的發(fā)展思路

• 迎合Kubernetes已成orchestrator王者的大勢(shì)
• 開(kāi)源版本與阿里巴巴集團(tuán)內(nèi)版本統(tǒng)一
• 與領(lǐng)域主流開(kāi)源項(xiàng)目形成合力發(fā)展，源于開(kāi)源、反哺開(kāi)源

八、Dubbo Mesh 的進(jìn)展

Dubbo Proxy

• Envoy支持Dubbo協(xié)議，分兩個(gè)迭代完成

迭代一：實(shí)現(xiàn)對(duì)Dubbo協(xié)議的解析和統(tǒng)計(jì)信息收集（代碼已提交給社區(qū)review）
迭代二：支持服務(wù)路由（規(guī)劃中）

Dubbo Control

• 豐富Istio/Pilot-discovery

已完成與VIPServer、Diamond的對(duì)接

正規(guī)劃與ZooKeeper、Nacos的對(duì)接

• 仍在規(guī)劃Istio/Mixer部分

九、成都沙龍 Q&A

Q1: 阿里巴巴是怎么從微服務(wù)過(guò)渡到sidecar模式，再過(guò)渡到Service Mesh？

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

Q2: Service Mesh中的服務(wù)注冊(cè)發(fā)現(xiàn)，負(fù)載均衡，網(wǎng)關(guān)，熔斷降級(jí)，超時(shí)，限流，消息總線，分布式配置，這些都是怎么實(shí)現(xiàn)的？

Dubbo Mesh在控制面會(huì)基于Istio去做，而Istio已經(jīng)具備了Kubernetes下的服務(wù)注冊(cè)與發(fā)現(xiàn)能力，我們要做的是擴(kuò)充Istio的能力，讓服務(wù)注冊(cè)與發(fā)現(xiàn)能與ZooKeeper、Nacos進(jìn)行對(duì)接去完成。基于開(kāi)源的Envoy所實(shí)現(xiàn)的sidecar已實(shí)現(xiàn)了超時(shí)處理的功能，相應(yīng)的內(nèi)容可以讀代碼去了解。其他內(nèi)容我們?nèi)栽谝?guī)劃中。

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

在使用iptables的情形下，一跳增加1.5毫秒，如果不采用iptables直接proxy方式的情形下應(yīng)當(dāng)性能更好（這一點(diǎn)與Lyft也郵件確認(rèn)過(guò)了），我們接下來(lái)會(huì)做更多的性能測(cè)試，目前的焦點(diǎn)更多在于功能層面。

Q4: Dubbo Mesh是把雙刃劍，經(jīng)過(guò)的鏈路更復(fù)雜，運(yùn)維和開(kāi)發(fā)者問(wèn)題排查有沒(méi)有更有效的工具？
**
理論上，增加一跳并沒(méi)有改變服務(wù)調(diào)用的拓?fù)浣Y(jié)構(gòu)，但確實(shí)會(huì)增加復(fù)雜度，這個(gè)應(yīng)當(dāng)通過(guò)設(shè)計(jì)實(shí)現(xiàn)去解決。好在因?yàn)槭且惑w化的方案，所以解決這類問(wèn)題時(shí)需要更具全局視野。**

?成都站開(kāi)發(fā)者提問(wèn)

Q5: Service Mesh中控制面板也用C++嗎？我看主流很多實(shí)現(xiàn)都是Go， 我相信大佬做過(guò)技術(shù)調(diào)研，有哪些優(yōu)勢(shì)？

控制面是復(fù)用Istio的，是Go語(yǔ)言的。我們力爭(zhēng)不重復(fù)造輪子，而是以開(kāi)放的心態(tài)去共建。

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

Envoy默認(rèn)就支持了，不需我們開(kāi)發(fā)。這也是借力開(kāi)源的收益。

Q7: Dubbo Mesh已經(jīng)支持domain socket了嗎？

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

?

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。