在過去的兩年中，Service Mesh 迅速在業界走紅，從概念期進入到了應用期。爲了幫助大家解決Service Mesh在落地過程中可能遇到的問題，我們採訪了多家互聯網企業的應用實踐，例如美團點評、同程藝龍以及瓜子二手車等，本文我們採訪了騰訊高級專項測試工程師黃俊，請他和大家分享騰訊的Service Mesh 實踐。今年10月，他將在QCon全球軟件開發大會（上海站）2019分享題爲《騰訊雲上基於 Service Mesh 的後臺環境管理實踐》的演講。
爲什麼需要 Service Mesh？
想要回答“爲什麼需要Service Mesh”這個問題，首先得弄明白Service Mesh是什麼。關於Service Mesh的定義，業界似乎已經達成了共識：Service Mesh是雲原生服務通信的基礎設施。在黃俊看來，Service Mesh最關鍵的部分是將服務通信管理能力從業務應用中剝離下沉至基礎設施的思想與實現。
其次，Service Mesh主要是解決什麼問題？“透明無侵入是 Service Mesh 的最大特性。”黃俊表示，“Service Mesh可以提供服務間一致可見性和網絡流量控制，無需修改業務程序代碼，即可獲得管控服務通信流量與層級觀測的能力。”
Service Mesh 主要解決的是傳統意義上的“服務治理”，覆蓋服務間流量、容錯、安全控制和全面遙測。傳統的主流解決方法是使用SDK類庫的方式顯式地對業務應用程序進行改造，但是這種方式在提供能力的同時，也帶來了相應的維護和使用成本，從而間接影響業務開發迭代的效率，例如，開發團隊需要感知並掌握治理框架、需要持續改造應用程序、對開發語言、對主被調服務接入SDK版本有依賴等等。而Service Mesh的出現，從網絡層面自下而上地提出了更好的解決方案與實現，基於服務通信基礎設施的定位和無侵入的特性，Service Mesh可對業務開發透明地提供“服務治理”能力。
在企業技術部門中，黃俊認爲開發與基礎運維團隊應該要格外關注Service Mesh，並且關注的側重點還有所不同：
- 因爲無侵入的特性，開發團隊是感知不到 Service Mesh 的存在，因此在開發業務過程中，開發團隊幾乎不需要作任何適配，只需在服務部署上線後，直接下發指令與配置，對通信進行管控和查看觀測數據。簡而言之更偏向於“用”，Service Mesh提供的能力作爲工具爲開發團隊服務。
- 對於基礎運維團隊而言，Service Mesh 已經成爲PaaS基礎設施的一部分，在“用”的基礎上，還要做好“維護”工作，保證 Service Mesh 控制面與數據面的穩定性與可靠性會是重點工作。除此之外，部分大型企業還要爲業務團隊打造定製化Service Mesh工具，包括集成企業自身發佈系統、Devops流程、環境治理平臺、微服務治理平臺等等。
騰訊 Service Mesh 實踐
早期，騰訊自研業務在內部做服務化拆分與部署時就已經在嘗試應用 Service Mesh相關技術來解決服務通信間的路由、容錯、限流與監控。當時，騰訊內部多個業務線都有同類工具類落地，不過，都還停留在業務框架層面。近年，隨着容器化技術的廣泛應用，騰訊自研業務中也逐漸落地了K8s，Service Mesh纔在騰訊的部分業務中有了真正意義上的落地，例如遊戲、社交、工具平臺等業務。
爲了更清楚的闡述騰訊Service Mesh實踐，我們將重點介紹一下其是如何利用Service Mesh進行後臺環境管理。
技術選型：Istio+K8s
騰訊後臺環境具有多租戶、多分支、多環境的業務特點，需要高精度自定義通信流量管控，可實現動態配置不同租戶（用戶）請求依賴任意指定環境中的指定分支版本，同時支持在流量層面隔離租戶依賴環境。
在技術選型方面，騰訊採用了 Istio+K8s 來實現後臺環境的管理。Service Mesh也有很多實現方式，爲什麼會選定Istio + K8s呢？黃俊解釋主要是出於兩方面考慮：
- K8s已經成爲容器編排平臺的事實標準，是CNCF與業界公認的雲原生生態中樞。從廣義上講，Service Mesh不依賴K8s，Service Mesh 也不關心服務所運行的計算平臺，但是與K8s結合能更完整地發揮Service Mesh的優勢，K8s的服務（負載）生產到Mesh的服務發現與通信接管可以是個自動化的過程。另外，業務容器化也是雲原生的必選項。
- 選擇Istio的主要原因是社區大勢，Istio與K8s原生集成，源自同一個團隊。Istio是對K8s服務通信管控能力的建設與完善，更像是K8s的下一個迭代。Google Cloud的CTO還曾經預估過，未來兩年內會有90%的K8s用戶使用Istio。在Istio已經定義了Service Mesh的事實標準，XDS v2已經成爲了Service Mesh通信的標準數據模型和協議的情況下，選擇Istio不僅可以服務更多客戶，而且可以完善基於K8s的容器服務平臺。
後臺環境管理的實踐過程
據黃俊介紹，騰訊基於Service Mesh的後臺環境管理實踐可以分成3個階段：
第一階段：解決研發過程中開發調試與測試的衝突，開發測試環境與測試環境分離。這一階段只要一次性把幾套固定的環境搭建出來即可，但是一套環境中經常會出現相互衝突，例如測試同學之間的環境衝突。
第二階段：一鍵自動化建立全新的測試環境，保證每個人在需要時，都有自己的開發測試環境。這一階段，主要做了兩部分工作：一是把環境進行容器化以便更好地做服務編排，K8s能夠讓每個後臺服務的搭建變得容易簡單；二是對後臺請求做精細化的路由管理，我們對Istio Envoy中的源碼做了很多改造工作來支持更多的私有RPC協議。
第三階段：結合DevOps、CI/CD以及自動化測試，在這一階段，後臺環境的持續部署能力將提升整體研發效能。
利用Istio+ K8s實現的後臺環境管理，不僅降低了多種後臺異構帶來的環境成本，而且提升了研發測試過程的效率，根據黃俊的介紹整個實踐過程的難點主要集中在以下三點：
支持私有RPC協議：Istio不支持私有RPC協議的流量管理，而測試開發環境管理的核心就是需要Istio支持私有RPC協議流量的管理，同時，我們希望複用Istio原生的能力，而不是重複造輪子。
解決方案：利用Istio支持的HTTP/gRPC作爲私有協議數據的傳輸隧道，同時將需要作爲流量管理的信息暴露到HTTP/gRPC header（例如：染色信息）。
支持私有名字服務：私有協議改造後，下發的HTTP/gRPC路由規則不生效，host匹配失敗，即私有名字服務解析到的POD IP無法匹配ServiceName、ServiceIP以及域名。
解決方案：在Istio-proxy的服務發現邏輯中記錄Service和POD IP的映射關係，具體流量解析時，再通過POD IP反查該POD所屬的ServiceName，將反查值作爲host字段。
支持流量轉發給本地POD IP：Istio-proxy流量攔截後，透傳給相同POD下的業務服務時，目標地址爲127.0.0.1，而業務監聽的socket基本爲POD IP，鏈路不通。
解決方案：將下發的終點socket_address由127.0.0.1改爲當前POD的ip地址，不過代價是捨棄Istio對POD調用自己流量的管控能力。
Service Mesh未來發展
目前，國內的Service Mesh應用和開發基本都源自Istio，無論是直接優化應用還是重構部分模塊，主要投入者還是公有云雲計算服務商，作爲容器平臺能力的補充。 另外，傳統的微服務框架開始集成Service Mesh的一部分能力作爲服務接入的拓展方式，主要面向私有云與傳統行業轉型。
在落地方面，整個市場還處於早期階段，但比較樂觀的是，隨着K8s的推廣和普及，相比於之前的遲疑，大家對於Service Mesh的認可度提高了，各個行業已經逐步有客戶在主動嘗試並生產應用Service Mesh。
黃俊表示：“作爲技術，Service Mesh還處於發展期，即使是最火的Istio項目也才推出了1.2版本，尚未達到K8s那樣的成熟度。”他認爲Service Mesh目前存在的問題主要集中在以下兩點：
- 性能損耗與拓展性：sidecar主動劫持流量經過兩次額外的TCP/IP堆棧穿越，與內核上下文切換，開源的版本平均每次調用將產生5-8ms延遲，這對敏感型業務來說，是比較難接受的。另外就是對服務通信私有協議的支持需要拓展。
- 維護成本：以Istio爲例，整個微服務化的Service Mesh控制面與業務成正比數量的sidecar，部署、升級、伸縮都需要投入相當大的精力與成本。
至於未來發展，黃俊認爲Service Mesh的發展還是會圍繞雲原生服務通信基礎設施的方向，作爲基礎PaaS平臺的核心組成支撐上層的業務應用平臺。另外，各大雲服務商也需要在Service Mesh 產品服務化上持續發力，解決和優化核心技術問題，打造成熟的解決方案和最佳實踐，幫助客戶遷移和應用Service Mesh與容器相關技術。
嘉賓介紹：
黃俊，騰訊高級專項測試工程師，現負責騰訊文檔、手 Q 增值服務等質量團隊。2014 年加入騰訊，經歷了移動 APP/AI 測試的發展歷程，目前主要聚焦在如何結合 DevOps 理念來助力團隊研發效能提升。
在QCon上海2019的演講中，他將重點闡述在騰訊雲上如何利用雲原生的解決方案 Istio+K8s 來對自研業務後臺進行環境管理，過程中涉及到了如何來適配 RPC 私有協議、名字服務等技術細節。以及這套環境治理方案實際對業務在研發過程效率的提升效果，點此瞭解。