隨着雲計算的快速發展，軟件開發的方式也從傳統的單體應用過渡到了SOA及時下流行的微服務。軟件方式的轉變也催生了一些新的技術發展，Service Mesh 就是在此環境下誕生的新的熱點技術。
當互聯網架構面臨數據量，高併發、高可用場景幾何增長的情況，Service Mesh可以在其中發揮什麼樣的作用？什麼樣的場景適合使用Service Mesh？如果有需要使用，又將如何來實現Service Mesh呢？…針對上述問題，InfoQ記者在ArchSummit 全球架構師峯會（深圳站）2019的現場採訪了同程藝龍研發中心架構師雷飛尉。
什麼是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在請求路由的層面進一步解耦了服務間調用，使得以前需要每個業務專門寫代碼處理的問題，有了一套通用而且業務無關的解決方案。
Service 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 暫時也沒有提出統一的解決方案。”
Service 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的流量路由功能， 甚至都可以不用編譯，無縫接入。
同程藝龍的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測試。通過這種方式，模型驗證的效率得到了極大的提高。
寫在最後
Service Mesh雖然現在熱度很高，但是其在企業當中的實踐還處於起步階段，對於其實踐價值，很多企業也存疑。作爲Service Mesh實踐的先行者，雷飛尉表示：“前面的風景真的很好，我們還想繼續往前走！”
談到Service Mesh未來的發展方向，雷飛尉表示：“無論如何演進，Service Mesh的基本架構都逃不脫控制平面和數據平面這兩部分。控制平面本質上是個存儲系統，所以其演進基本就是在一致性和可用性上做平衡；而數據平面主要是在高效率和低侵入性方面做平衡。例如，Sidecar雖然是數據平面的典型方案，但並不是唯一方案，RPC框架也可以做數據平面，且效率會更高，但相對的侵入性也更高。”