解讀 Service Mesh 的實現(xiàn)方式與同程藝龍的具體實踐
當互聯(lián)網(wǎng)架構(gòu)面臨數(shù)據(jù)量，高并發(fā)、高可用場景幾何增長的情況，Service Mesh 可以在其中發(fā)揮什么樣的作用？什么樣的場景適合使用 Service Mesh？如果有需要使用，又將如何來實現(xiàn) Service Mesh 呢？…針對上述問題，InfoQ 記者在 ArchSummit 全球架構(gòu)師峰會（深圳站）2019 的現(xiàn)場采訪了同程藝龍研發(fā)中心架構(gòu)師雷飛尉。 什么是 Service Mesh 呢？目前業(yè)內(nèi)公認的是 Linkerd CEO Willian Morgan 對 Service Mesh 的定義，即 Service Mesh 是一個基礎(chǔ)設(shè)施層，用于處理服務(wù)間通信。云原生應(yīng)用有著復(fù)雜的服務(wù)拓撲，Service Mesh 保證請求可以在這些拓撲中可靠地穿梭。在實際應(yīng)用當中，Service Mesh 通常是由一系列輕量級的網(wǎng)絡(luò)代理組成的，它們與應(yīng)用程序部署在一起，但應(yīng)用程序不需要知道它們的存在。 Service Mesh 定義中有這么多關(guān)鍵詞，那么到底什么才是最關(guān)鍵的呢？在雷飛尉看來，Service Mesh 最關(guān)鍵的部分在于設(shè)計時所定義的服務(wù)模型。Service Mesh 模型設(shè)計不僅有服務(wù)的概念，還會有環(huán)境的概念，而這些概念的提出會使得 Service Mesh 系統(tǒng)不再是一個普通的提供服務(wù)發(fā)現(xiàn)、負載均衡等功能的服務(wù)治理框架， 我們可以依此實現(xiàn)強大的服務(wù)環(huán)境間路由功能, 讓 7 層的服務(wù)間調(diào)用也能像 3 層的 IP 報文一樣路由起來。 如果我們把之前經(jīng)典的服務(wù)發(fā)現(xiàn) +RPC 的服務(wù)治理框架看作是服務(wù)治理 1.0 的話，那么 Service Mesh 技術(shù)就可以稱為服務(wù)治理 2.0，它是業(yè)界基于之前的服務(wù)治理實踐總結(jié)出來的全新思路。 Service Mesh 實際上是在解決什么問題呢？雷飛尉認為 Service Mesh 主要解決的就是服務(wù)間調(diào)用解耦的問題。 在沒有 Service Mesh 之前，服務(wù)間調(diào)用要么寫死 IP 地址，要么寫死域名，但是這些方案太死板了，寫死域名雖然比寫死 IP 地址稍微靈活一點點，但由于各種歷史包袱，很多 DNS 解析庫對域名的處理并不規(guī)范，典型的就是忽略域名的 TTL 導(dǎo)致不能快速變更域名的 IP 地址列表。 第一代服務(wù)發(fā)現(xiàn) +RPC 的服務(wù)治理框架雖然解決了最基本的 IP 地址調(diào)用的問題，但是對于多環(huán)境間的請求路由要么完全沒有考慮，要么非常不靈活，這就造成很多業(yè)務(wù)為了實現(xiàn) A/B 測試或泳道發(fā)布，不得不多寫很多專門的代碼。而 Service Mesh 在請求路由的層面進一步解耦了服務(wù)間調(diào)用，使得以前需要每個業(yè)務(wù)專門寫代碼處理的問題，有了一套通用而且業(yè)務(wù)無關(guān)的解決方案。 目前業(yè)內(nèi)比較流行的 Service Mesh 開源軟件有 Linkerd、Envoy、Istio、Conduit、nginMesh 和 Kong。 其中 Istio 是 Service Mesh 比較經(jīng)典的實現(xiàn)方式，它是由 Google、IBM 和 Lyft 聯(lián)合開發(fā)，于 2017 年 5 月 24 日首次發(fā)布。Istio 在邏輯上可以分為數(shù)據(jù)層和控制層，數(shù)據(jù)層是由一組智能的代理（Envoy）構(gòu)成，負責(zé)協(xié)調(diào)和控制服務(wù)間的所有網(wǎng)絡(luò)的通信，而控制層負責(zé)管理和配置路由轉(zhuǎn)發(fā)流量，就是運行時實施的策略。 上圖是 Istio 的架構(gòu)圖，從圖中我們可以看到 Istio 的核心組件主要包括 Proxy 代理、Mixer 混合器、Pilot 引導(dǎo)、Citadel 堡壘和 Galley。其中，Proxy 代理的代理組件主要是 Envoy，用來攔截所有想攔截的流量；Mixer 混合器混合了各種策略以及后端數(shù)據(jù)采集或遙測系統(tǒng)的適配器，實現(xiàn)了前端 Proxy 與后端系統(tǒng)的隔離與匯合；Pilot 引導(dǎo)提供了一系列 rules api，允許運維人員指定一系列高級的流量管理規(guī)則；Citadel 堡壘管理著集群的密鑰和證書，是集群的安全部門；Galley 主要是用來驗證用戶編寫的 Istio api 配置。 作為經(jīng)典的 Service Mesh 實現(xiàn)方式，Istio 在架構(gòu)設(shè)計和服務(wù)模型設(shè)計方面都沒有問題，但也不是完全完美。雷飛尉表示：“Istio 因為出現(xiàn)時間較短，所以有很多場景沒有覆蓋到，例如跨地域的 Service Mesh，Istio 的實現(xiàn)方案暫時不是那么漂亮；而多環(huán)境路由方案由于可能要侵入業(yè)務(wù)， Istio 暫時也沒有提出統(tǒng)一的解決方案。” Service Mesh 作為一種新興的技術(shù)，哪些企業(yè)適合使用呢？對于企業(yè)來說有哪些價值？落地過程中又會存在哪些問題呢？ 雷飛尉認為 Service Mesh 適合所有的 IT 公司使用，只要其業(yè)務(wù)規(guī)模已經(jīng)大到需要拆分為不止一個服務(wù)，那么就需要服務(wù)治理，就應(yīng)該使用 Service Mesh 技術(shù)。 Service Mesh 的價值主要體現(xiàn)在三個方面，一是增強了業(yè)務(wù)服務(wù)的快速故障恢復(fù)能力，例如當某個業(yè)務(wù)實例出現(xiàn)故障可以自動健康檢查剔除掉，又或者整機房出現(xiàn)故障，只需要一句 select 語句更新一下即可；二是增強了業(yè)務(wù)服務(wù)的快速迭代能力，業(yè)務(wù)可以通過 Service Mesh 輕松實現(xiàn)小流量功能，這樣業(yè)務(wù)驗證的速度就非常快；三是節(jié)省了大量硬件和人力成本，基于 Service Mesh 的泳道發(fā)布方案把硬件資源的耗費降到了最低，同時也把人力配置和溝通的成本降到了最低。 當然，任何事情都是機遇與挑戰(zhàn)并存，所以 Service Mesh 在企業(yè)落地時也會存在很多挑戰(zhàn)。“Service Mesh 在落地時最大的挑戰(zhàn)在于存量業(yè)務(wù)”，雷飛尉認為：“存量業(yè)務(wù)由于歷史原因往往會使用一些比較老的服務(wù)間調(diào)用方案，如寫死 IP 地址或者域名，在這種情況除了改造業(yè)務(wù)別無他法。” 如果企業(yè)存量業(yè)務(wù)使用了服務(wù)發(fā)現(xiàn) +RPC 這樣的第一代服務(wù)治理方案，那么可以使用 Service Mesh 的服務(wù)發(fā)現(xiàn) + Sidecar 去兼容以前的 RPC 協(xié)議。通過這種方式，我們可以以最小的修改代價將該存量業(yè)務(wù)升級到 Service Mesh，業(yè)務(wù)只需要進行重新編譯，如果該業(yè)務(wù)暫時用不到 Service Mesh 的流量路由功能， 甚至都可以不用編譯，無縫接入。 同程藝龍的 Service Mesh 實踐可以追溯到 2016 年底，當時同程藝龍技術(shù)團隊研發(fā)了一個服務(wù)發(fā)現(xiàn)系統(tǒng)，之后基于此系統(tǒng)不斷外延，形成了一個完善的、自研的 Service Mesh 系統(tǒng)。雷飛尉表示：“Service Mesh 是所有業(yè)務(wù)系統(tǒng)的底層支持技術(shù)，如果 Service Mesh 垮了，那么全公司的業(yè)務(wù)都會受影響，輕則不能變更配置，重則損失全部用戶流量。所以，在技術(shù)選型時，我們沒有直接使用 Istio，而是選擇了自研 Service Mesh 系統(tǒng)，并且在應(yīng)用時提前準備了處理各種故障場景的預(yù)案，設(shè)計層層保底方案。” Service Mesh 系統(tǒng)不僅可以處理傳統(tǒng)的服務(wù)發(fā)現(xiàn)、負載均衡等應(yīng)用，更為關(guān)鍵的是其擁有 7 層路由功能，基于此功能，同程藝龍開發(fā)了可同時支持幾百個泳道發(fā)布的泳道發(fā)布系統(tǒng)，并將人力成本降到了最低。 以推薦功能為例，由于同程藝龍的酒店業(yè)務(wù)本質(zhì)上是一個垂直搜索引擎，搜索結(jié)果中的推薦位就很關(guān)鍵，向用戶推薦什么樣的酒店直接關(guān)系到用戶體驗，所以必須要做大量的 A/B 測試來驗證模型的效果。 雷飛尉把同程藝龍酒店業(yè)務(wù)推薦功能的 Service Mesh 應(yīng)用分成了三部分： Service Mesh 剛剛上線，業(yè)務(wù)同學(xué)不認可，怎么辦？這時就要考慮誰是最需要 Service Mesh 的人，當然是運維同學(xué)，他們需要維護 nginx、lvs、RPC 等各種負載均衡系統(tǒng)，而 Service Mesh 中剛好有服務(wù)發(fā)現(xiàn)功能。所以，我們首先解決了運維同學(xué)統(tǒng)一維護負載均衡系統(tǒng)的 upstream 列表的需求，把所有服務(wù)導(dǎo)入到 Service Mesh 上，再由 Service Mesh 去對接 nginx/lvs/RPC 等各個系統(tǒng)。通過這樣的方式，運維同學(xué)不再需要配置 nginx、lvs、RPC 等多個系統(tǒng)，只需在 Service Mesh 系統(tǒng)上統(tǒng)一維護每個服務(wù)的 IP 列表。 接下來，我們做的是業(yè)務(wù)系統(tǒng)直接對接 Service Mesh 的 Sidecar，這種方式可以省掉對接 nginx 的開銷。這一部分會比較難一點，因為 Sidecar 要過流量，大家的疑慮就會大一些。針對此，我們的方案是穩(wěn)扎穩(wěn)打，按灰度發(fā)布的路子穩(wěn)步推進。 業(yè)務(wù)對接 Java Agent，這是我們設(shè)想中的 Service Mesh 完全體，只有這樣才能實現(xiàn)最靈活的 Service Mesh 的動態(tài)流量調(diào)度功能。我們的方案是配合發(fā)布系統(tǒng)來做這件事， 直接把 Java Agent 內(nèi)置于 JVM 中。這樣，隨著業(yè)務(wù)不斷迭代發(fā)布，就把 Java Agent 帶到了線上。Java Agent 上線以后，Service Mesh 的作用就能得到充分發(fā)揮，極大的方便了 A/B 測試，業(yè)務(wù)可以在整個調(diào)用鏈的任意一點創(chuàng)建多個灰度環(huán)境，并把多個環(huán)境串聯(lián)起來，同時進行多個 A/B 測試。通過這種方式，模型驗證的效率得到了極大的提高。 Service Mesh 雖然現(xiàn)在熱度很高，但是其在企業(yè)當中的實踐還處于起步階段，對于其實踐價值，很多企業(yè)也存疑。作為 Service Mesh 實踐的先行者，雷飛尉表示：“前面的風(fēng)景真的很好，我們還想繼續(xù)往前走！” 談到 Service Mesh 未來的發(fā)展方向，雷飛尉表示：“無論如何演進，Service Mesh 的基本架構(gòu)都逃不脫控制平面和數(shù)據(jù)平面這兩部分?？刂破矫姹举|(zhì)上是個存儲系統(tǒng)，所以其演進基本就是在一致性和可用性上做平衡；而數(shù)據(jù)平面主要是在高效率和低侵入性方面做平衡。例如，Sidecar 雖然是數(shù)據(jù)平面的典型方案，但并不是唯一方案，RPC 框架也可以做數(shù)據(jù)平面，且效率會更高，但相對的侵入性也更高。”
