[[271239]]

當(dāng)互聯(lián)網(wǎng)架構(gòu)面臨數(shù)據(jù)量，高并發(fā)、高可用場(chǎng)景幾何增長(zhǎng)的情況，Service Mesh 可以在其中發(fā)揮什么樣的作用？什么樣的場(chǎng)景適合使用 Service Mesh？如果有需要使用，又將如何來(lái)實(shí)現(xiàn) Service Mesh 呢？…針對(duì)上述問(wèn)題，InfoQ 記者在 ArchSummit 全球架構(gòu)師峰會(huì)（深圳站）2019 的現(xiàn)場(chǎng)采訪了同程藝龍研發(fā)中心架構(gòu)師雷飛尉。

什么是 Service Mesh 呢？目前業(yè)內(nèi)公認(rèn)的是 Linkerd CEO Willian Morgan 對(duì) Service Mesh 的定義，即 Service Mesh 是一個(gè)基礎(chǔ)設(shè)施層，用于處理服務(wù)間通信。云原生應(yīng)用有著復(fù)雜的服務(wù)拓?fù)?，Service Mesh 保證請(qǐng)求可以在這些拓?fù)渲锌煽康卮┧?。在?shí)際應(yīng)用當(dāng)中，Service Mesh 通常是由一系列輕量級(jí)的網(wǎng)絡(luò)代理組成的，它們與應(yīng)用程序部署在一起，但應(yīng)用程序不需要知道它們的存在。

Service Mesh 定義中有這么多關(guān)鍵詞，那么到底什么才是最關(guān)鍵的呢？在雷飛尉看來(lái)，Service Mesh 最關(guān)鍵的部分在于設(shè)計(jì)時(shí)所定義的服務(wù)模型。Service Mesh 模型設(shè)計(jì)不僅有服務(wù)的概念，還會(huì)有環(huán)境的概念，而這些概念的提出會(huì)使得 Service Mesh 系統(tǒng)不再是一個(gè)普通的提供服務(wù)發(fā)現(xiàn)、負(fù)載均衡等功能的服務(wù)治理框架， 我們可以依此實(shí)現(xiàn)強(qiáng)大的服務(wù)環(huán)境間路由功能, 讓 7 層的服務(wù)間調(diào)用也能像 3 層的 IP 報(bào)文一樣路由起來(lái)。

如果我們把之前經(jīng)典的服務(wù)發(fā)現(xiàn) +RPC 的服務(wù)治理框架看作是服務(wù)治理 1.0 的話，那么 Service Mesh 技術(shù)就可以稱為服務(wù)治理 2.0，它是業(yè)界基于之前的服務(wù)治理實(shí)踐總結(jié)出來(lái)的全新思路。

Service Mesh 實(shí)際上是在解決什么問(wèn)題呢？雷飛尉認(rèn)為 Service Mesh 主要解決的就是服務(wù)間調(diào)用解耦的問(wèn)題。

在沒(méi)有 Service Mesh 之前，服務(wù)間調(diào)用要么寫(xiě)死 IP 地址，要么寫(xiě)死域名，但是這些方案太死板了，寫(xiě)死域名雖然比寫(xiě)死 IP 地址稍微靈活一點(diǎn)點(diǎn)，但由于各種歷史包袱，很多 DNS 解析庫(kù)對(duì)域名的處理并不規(guī)范，典型的就是忽略域名的 TTL 導(dǎo)致不能快速變更域名的 IP 地址列表。

第一代服務(wù)發(fā)現(xiàn) +RPC 的服務(wù)治理框架雖然解決了最基本的 IP 地址調(diào)用的問(wèn)題，但是對(duì)于多環(huán)境間的請(qǐng)求路由要么完全沒(méi)有考慮，要么非常不靈活，這就造成很多業(yè)務(wù)為了實(shí)現(xiàn) A/B 測(cè)試或泳道發(fā)布，不得不多寫(xiě)很多專門(mén)的代碼。而 Service Mesh 在請(qǐng)求路由的層面進(jìn)一步解耦了服務(wù)間調(diào)用，使得以前需要每個(gè)業(yè)務(wù)專門(mén)寫(xiě)代碼處理的問(wèn)題，有了一套通用而且業(yè)務(wù)無(wú)關(guān)的解決方案。

目前業(yè)內(nèi)比較流行的 Service Mesh 開(kāi)源軟件有 Linkerd、Envoy、Istio、Conduit、nginMesh 和 Kong。

其中 Istio 是 Service Mesh 比較經(jīng)典的實(shí)現(xiàn)方式，它是由 Google、IBM 和 Lyft 聯(lián)合開(kāi)發(fā)，于 2017 年 5 月 24 日首次發(fā)布。Istio 在邏輯上可以分為數(shù)據(jù)層和控制層，數(shù)據(jù)層是由一組智能的代理（Envoy）構(gòu)成，負(fù)責(zé)協(xié)調(diào)和控制服務(wù)間的所有網(wǎng)絡(luò)的通信，而控制層負(fù)責(zé)管理和配置路由轉(zhuǎn)發(fā)流量，就是運(yùn)行時(shí)實(shí)施的策略。

上圖是 Istio 的架構(gòu)圖，從圖中我們可以看到 Istio 的核心組件主要包括 Proxy 代理、Mixer 混合器、Pilot 引導(dǎo)、Citadel 堡壘和 Galley。其中，Proxy 代理的代理組件主要是 Envoy，用來(lái)攔截所有想攔截的流量；Mixer 混合器混合了各種策略以及后端數(shù)據(jù)采集或遙測(cè)系統(tǒng)的適配器，實(shí)現(xiàn)了前端 Proxy 與后端系統(tǒng)的隔離與匯合；Pilot 引導(dǎo)提供了一系列 rules api，允許運(yùn)維人員指定一系列高級(jí)的流量管理規(guī)則；Citadel 堡壘管理著集群的密鑰和證書(shū)，是集群的安全部門(mén)；Galley 主要是用來(lái)驗(yàn)證用戶編寫(xiě)的 Istio api 配置。

作為經(jīng)典的 Service Mesh 實(shí)現(xiàn)方式，Istio 在架構(gòu)設(shè)計(jì)和服務(wù)模型設(shè)計(jì)方面都沒(méi)有問(wèn)題，但也不是完全完美。雷飛尉表示：“Istio 因?yàn)槌霈F(xiàn)時(shí)間較短，所以有很多場(chǎng)景沒(méi)有覆蓋到，例如跨地域的 Service Mesh，Istio 的實(shí)現(xiàn)方案暫時(shí)不是那么漂亮；而多環(huán)境路由方案由于可能要侵入業(yè)務(wù)， Istio 暫時(shí)也沒(méi)有提出統(tǒng)一的解決方案。”

Service Mesh 作為一種新興的技術(shù)，哪些企業(yè)適合使用呢？對(duì)于企業(yè)來(lái)說(shuō)有哪些價(jià)值？落地過(guò)程中又會(huì)存在哪些問(wèn)題呢？

雷飛尉認(rèn)為 Service Mesh 適合所有的 IT 公司使用，只要其業(yè)務(wù)規(guī)模已經(jīng)大到需要拆分為不止一個(gè)服務(wù)，那么就需要服務(wù)治理，就應(yīng)該使用 Service Mesh 技術(shù)。

Service Mesh 的價(jià)值主要體現(xiàn)在三個(gè)方面，一是增強(qiáng)了業(yè)務(wù)服務(wù)的快速故障恢復(fù)能力，例如當(dāng)某個(gè)業(yè)務(wù)實(shí)例出現(xiàn)故障可以自動(dòng)健康檢查剔除掉，又或者整機(jī)房出現(xiàn)故障，只需要一句 select 語(yǔ)句更新一下即可；二是增強(qiáng)了業(yè)務(wù)服務(wù)的快速迭代能力，業(yè)務(wù)可以通過(guò) Service Mesh 輕松實(shí)現(xiàn)小流量功能，這樣業(yè)務(wù)驗(yàn)證的速度就非常快；三是節(jié)省了大量硬件和人力成本，基于 Service Mesh 的泳道發(fā)布方案把硬件資源的耗費(fèi)降到了最低，同時(shí)也把人力配置和溝通的成本降到了最低。

當(dāng)然，任何事情都是機(jī)遇與挑戰(zhàn)并存，所以 Service Mesh 在企業(yè)落地時(shí)也會(huì)存在很多挑戰(zhàn)。“Service Mesh 在落地時(shí)最大的挑戰(zhàn)在于存量業(yè)務(wù)”，雷飛尉認(rèn)為：“存量業(yè)務(wù)由于歷史原因往往會(huì)使用一些比較老的服務(wù)間調(diào)用方案，如寫(xiě)死 IP 地址或者域名，在這種情況除了改造業(yè)務(wù)別無(wú)他法。”

如果企業(yè)存量業(yè)務(wù)使用了服務(wù)發(fā)現(xiàn) +RPC 這樣的第一代服務(wù)治理方案，那么可以使用 Service Mesh 的服務(wù)發(fā)現(xiàn) + Sidecar 去兼容以前的 RPC 協(xié)議。通過(guò)這種方式，我們可以以最小的修改代價(jià)將該存量業(yè)務(wù)升級(jí)到 Service Mesh，業(yè)務(wù)只需要進(jìn)行重新編譯，如果該業(yè)務(wù)暫時(shí)用不到 Service Mesh 的流量路由功能， 甚至都可以不用編譯，無(wú)縫接入。

同程藝龍的 Service Mesh 實(shí)踐可以追溯到 2016 年底，當(dāng)時(shí)同程藝龍技術(shù)團(tuán)隊(duì)研發(fā)了一個(gè)服務(wù)發(fā)現(xiàn)系統(tǒng)，之后基于此系統(tǒng)不斷外延，形成了一個(gè)完善的、自研的 Service Mesh 系統(tǒng)。雷飛尉表示：“Service Mesh 是所有業(yè)務(wù)系統(tǒng)的底層支持技術(shù)，如果 Service Mesh 垮了，那么全公司的業(yè)務(wù)都會(huì)受影響，輕則不能變更配置，重則損失全部用戶流量。所以，在技術(shù)選型時(shí)，我們沒(méi)有直接使用 Istio，而是選擇了自研 Service Mesh 系統(tǒng)，并且在應(yīng)用時(shí)提前準(zhǔn)備了處理各種故障場(chǎng)景的預(yù)案，設(shè)計(jì)層層保底方案。”

Service Mesh 系統(tǒng)不僅可以處理傳統(tǒng)的服務(wù)發(fā)現(xiàn)、負(fù)載均衡等應(yīng)用，更為關(guān)鍵的是其擁有 7 層路由功能，基于此功能，同程藝龍開(kāi)發(fā)了可同時(shí)支持幾百個(gè)泳道發(fā)布的泳道發(fā)布系統(tǒng)，并將人力成本降到了最低。

以推薦功能為例，由于同程藝龍的酒店業(yè)務(wù)本質(zhì)上是一個(gè)垂直搜索引擎，搜索結(jié)果中的推薦位就很關(guān)鍵，向用戶推薦什么樣的酒店直接關(guān)系到用戶體驗(yàn)，所以必須要做大量的 A/B 測(cè)試來(lái)驗(yàn)證模型的效果。

雷飛尉把同程藝龍酒店業(yè)務(wù)推薦功能的 Service Mesh 應(yīng)用分成了三部分：

Service Mesh 剛剛上線，業(yè)務(wù)同學(xué)不認(rèn)可，怎么辦？這時(shí)就要考慮誰(shuí)是最需要 Service Mesh 的人，當(dāng)然是運(yùn)維同學(xué)，他們需要維護(hù) nginx、lvs、RPC 等各種負(fù)載均衡系統(tǒng)，而 Service Mesh 中剛好有服務(wù)發(fā)現(xiàn)功能。所以，我們首先解決了運(yùn)維同學(xué)統(tǒng)一維護(hù)負(fù)載均衡系統(tǒng)的 upstream 列表的需求，把所有服務(wù)導(dǎo)入到 Service Mesh 上，再由 Service Mesh 去對(duì)接 nginx/lvs/RPC 等各個(gè)系統(tǒng)。通過(guò)這樣的方式，運(yùn)維同學(xué)不再需要配置 nginx、lvs、RPC 等多個(gè)系統(tǒng)，只需在 Service Mesh 系統(tǒng)上統(tǒng)一維護(hù)每個(gè)服務(wù)的 IP 列表。

接下來(lái)，我們做的是業(yè)務(wù)系統(tǒng)直接對(duì)接 Service Mesh 的 Sidecar，這種方式可以省掉對(duì)接 nginx 的開(kāi)銷(xiāo)。這一部分會(huì)比較難一點(diǎn)，因?yàn)?Sidecar 要過(guò)流量，大家的疑慮就會(huì)大一些。針對(duì)此，我們的方案是穩(wěn)扎穩(wěn)打，按灰度發(fā)布的路子穩(wěn)步推進(jìn)。

業(yè)務(wù)對(duì)接 Java Agent，這是我們?cè)O(shè)想中的 Service Mesh 完全體，只有這樣才能實(shí)現(xiàn)最靈活的 Service Mesh 的動(dòng)態(tài)流量調(diào)度功能。我們的方案是配合發(fā)布系統(tǒng)來(lái)做這件事， 直接把 Java Agent 內(nèi)置于 JVM 中。這樣，隨著業(yè)務(wù)不斷迭代發(fā)布，就把 Java Agent 帶到了線上。Java Agent 上線以后，Service Mesh 的作用就能得到充分發(fā)揮，極大的方便了 A/B 測(cè)試，業(yè)務(wù)可以在整個(gè)調(diào)用鏈的任意一點(diǎn)創(chuàng)建多個(gè)灰度環(huán)境，并把多個(gè)環(huán)境串聯(lián)起來(lái)，同時(shí)進(jìn)行多個(gè) A/B 測(cè)試。通過(guò)這種方式，模型驗(yàn)證的效率得到了極大的提高。

Service Mesh 雖然現(xiàn)在熱度很高，但是其在企業(yè)當(dāng)中的實(shí)踐還處于起步階段，對(duì)于其實(shí)踐價(jià)值，很多企業(yè)也存疑。作為 Service Mesh 實(shí)踐的先行者，雷飛尉表示：“前面的風(fēng)景真的很好，我們還想繼續(xù)往前走！”

談到 Service Mesh 未來(lái)的發(fā)展方向，雷飛尉表示：“無(wú)論如何演進(jìn)，Service Mesh 的基本架構(gòu)都逃不脫控制平面和數(shù)據(jù)平面這兩部分?？刂破矫姹举|(zhì)上是個(gè)存儲(chǔ)系統(tǒng)，所以其演進(jìn)基本就是在一致性和可用性上做平衡；而數(shù)據(jù)平面主要是在高效率和低侵入性方面做平衡。例如，Sidecar 雖然是數(shù)據(jù)平面的典型方案，但并不是唯一方案，RPC 框架也可以做數(shù)據(jù)平面，且效率會(huì)更高，但相對(duì)的侵入性也更高。”