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