騰訊雲 Service Mesh 實踐：利用Istio+K8s進行後臺環境管理

1爲何須要 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 流程、環境治理平臺、微服務治理平臺等等。

2騰訊 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 調用本身流量的管控能力。

3Service Mesh 將來發展

目前，國內的 Service Mesh 應用和開發基本都源自 Istio，不管是直接優化應用仍是重構部分模塊，主要投入者仍是公有云雲計算服務商，做爲容器平臺能力的補充。另外，傳統的微服務框架開始集成 Service Mesh 的一部分能力做爲服務接入的拓展方式，主要面向私有云與傳統行業轉型。

在落地方面，整個市場還處於早期階段，但比較樂觀的是，隨着 K8s 的推廣和普及，相比於以前的遲疑，你們對於 Service Mesh 的承認度提升了，各個行業已經逐步有客戶在主動嘗試並生產應用 Service Mesh。

黃俊表示：「做爲技術，Service Mesh 還處於發展期，即便是最火的 Istio 項目也才推出了 1.2 版本，還沒有達到 K8s 那樣的成熟度。」他認爲 Service Mesh 目前存在的問題主要集中在如下兩點：

1. 性能損耗與拓展性：sidecar 主動劫持流量通過兩次額外的 TCP/IP 堆棧穿越，與內核上下文切換，開源的版本平均每次調用將產生 5-8ms 延遲，這對敏感型業務來講，是比較難接受的。另外就是對服務通訊私有協議的支持須要拓展。

2. 維護成本：以 Istio 爲例，整個微服務化的 Service Mesh 控制面與業務成正比數量的 sidecar，部署、升級、伸縮都須要投入至關大的精力與成本。至於將來發展，黃俊認爲 Service Mesh 的發展仍是會圍繞雲原生服務通訊基礎設施的方向，做爲基礎 PaaS 平臺的核心組成支撐上層的業務應用平臺。另外，各大雲服務商也須要在 Service Mesh 產品服務化上持續發力，解決和優化核心技術問題，打形成熟的解決方案和最佳實踐，幫助客戶遷移和應用 Service Mesh 與容器相關技術。