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