騰訊云中間件團(tuán)隊(duì)在Service Mesh中的實(shí)踐與探索

導(dǎo)語(yǔ)：Service Mesh作為騰訊微服務(wù)平臺(tái)（TSF）支持的微服務(wù)架構(gòu)之一，產(chǎn)品化命名為Mesh微服務(wù)平臺(tái)（Tencent Service Mesh Framework，簡(jiǎn)稱(chēng)TSF Mesh），提供下一代微服務(wù)架構(gòu)-服務(wù)網(wǎng)格（Service Mesh）的解決方案，覆蓋公有云、私有云和本地化部署等多種場(chǎng)景。從2018年8月推出首個(gè)版本以來(lái)，已經(jīng)陸續(xù)在金融、新零售、工業(yè)互聯(lián)網(wǎng)，以及公司內(nèi)部等生產(chǎn)環(huán)境落地。在產(chǎn)品落地過(guò)程中，遇到了一系列技術(shù)挑戰(zhàn)，如非Kubernetes環(huán)境的支持、多租戶(hù)隔離、與Spring Cloud服務(wù)框架的互通、海量服務(wù)實(shí)例下的域名解析等等。針對(duì)這些問(wèn)題，通過(guò)自研以及社區(qū)合作，最終得以解決。本文主要從用戶(hù)場(chǎng)景出發(fā)，以生產(chǎn)實(shí)踐探索過(guò)程中遇到的挑戰(zhàn)為切入點(diǎn)，梳理和總結(jié)應(yīng)對(duì)的解決方案，以期望對(duì)Service Mesh的認(rèn)識(shí)、對(duì)TSF Mesh產(chǎn)品的了解有所幫助。

01  背景介紹

什么是Service Mesh?根據(jù)Buoyant CEO，Service Mesh理念的提出者和先行者，William Morgan定義，Service Mesh（服務(wù)網(wǎng)格）是一個(gè)專(zhuān)注于處理服務(wù)間通信的基礎(chǔ)設(shè)施層。用于解決服務(wù)間復(fù)雜拓?fù)渲械目煽空?qǐng)求傳遞，是云原生技術(shù)棧的關(guān)鍵組件之一。

2018年被很多人稱(chēng)為“Service Mesh之年”，這一年，業(yè)界幾乎所有大廠都在嘗試推出自己的Service Mesh產(chǎn)品。Service Mesh中的明星項(xiàng)目Istio在這一年也是蓄勢(shì)待發(fā)，作為Google、IBM、Lyft聯(lián)合開(kāi)發(fā)的開(kāi)源項(xiàng)目，陸續(xù)發(fā)布了0.5、0.6、0.7、0.8和1.0版本，到2018年7月31日1.0 GA時(shí)，對(duì)Istio來(lái)說(shuō)是一個(gè)重要的里程碑，官方宣稱(chēng)所有的核心功能都可以用于生產(chǎn)。

以GitHub上的star數(shù)量的角度來(lái)看一下Istio在近幾年的受歡迎程度，下圖顯示的是Istio的GitHub star數(shù)量隨時(shí)間變化曲線?？梢钥吹皆?018年，Istio的star數(shù)量大概增長(zhǎng)了一萬(wàn)，目前已經(jīng)超過(guò)2.2萬(wàn)顆星，其增長(zhǎng)趨勢(shì)也非常平穩(wěn)。

早在2017年，騰訊云中間件團(tuán)隊(duì)就選定Istio為技術(shù)路線，開(kāi)始Service Mesh的相關(guān)預(yù)研和研發(fā)工作。作為騰訊微服務(wù)平臺(tái)（TSF）的無(wú)侵入式微服務(wù)框架的核心實(shí)現(xiàn)，于18年初在騰訊廣告平臺(tái)投入，打磨穩(wěn)定后，陸續(xù)開(kāi)始對(duì)外輸出，目前在金融、工業(yè)互聯(lián)網(wǎng)等領(lǐng)域都有落地案例。

產(chǎn)品落地過(guò)程并非一帆風(fēng)順，會(huì)遇到一些問(wèn)題和挑戰(zhàn)。接下來(lái)，首先以開(kāi)源Istio為切入點(diǎn)，介紹一下TSF Mesh,之后對(duì)TSF Mesh產(chǎn)品化探索過(guò)程中的部分典型問(wèn)題以及解決方案進(jìn)行梳理和分享。

02  TSF Mesh介紹

Mesh微服務(wù)平臺(tái)（Tencent Service Mesh Framework，簡(jiǎn)稱(chēng)TSF Mesh），基于Service Mesh的理念，為應(yīng)用提供服務(wù)自動(dòng)注冊(cè)與發(fā)現(xiàn)、服務(wù)路由、鑒權(quán)、限流、熔斷等服務(wù)治理能力，且應(yīng)用無(wú)需對(duì)源代碼進(jìn)行侵入式改造，即可與該服務(wù)框架進(jìn)行集成。

在開(kāi)發(fā)選型上，基于業(yè)界達(dá)到商用標(biāo)準(zhǔn)的開(kāi)源軟件Istio進(jìn)行構(gòu)建，主要原因如下：

·Istio功能相對(duì)完備，mesh該有的能力都有。

·社區(qū)活躍，資源豐富，CNCF成員，代表云原生標(biāo)準(zhǔn)化。

·Golang（Istio）&C++14（envoy）都是高性能語(yǔ)言，且運(yùn)行起來(lái)資源使用靈活，獨(dú)立性好，無(wú)JVM等外部依賴(lài)。

在了解TSF Mesh架構(gòu)之前，先回顧一下Istio的架構(gòu)圖，如下圖所示：

在上面的架構(gòu)圖中，Istio Mesh分為兩塊：數(shù)據(jù)面板和控制面板。envoy在Istio中扮演數(shù)據(jù)面板的角色，作為服務(wù)的代理，被部署為sidecar，服務(wù)無(wú)需感知envoy的存在；控制面板包含Pilot，Mixer，Citadel等組件。這些組件的主要功能如下：

·Envoy:作為底層的代理，通常選用其擴(kuò)展版本istio-proxy，用于調(diào)度服務(wù)網(wǎng)格中所有服務(wù)的出入站流量。包含了豐富的內(nèi)置功能，例如動(dòng)態(tài)服務(wù)發(fā)現(xiàn)，負(fù)載均衡，HTTP/2&gRPC代理，熔斷器，健康檢查，基于百分比流量拆分的灰度發(fā)布，故障注入，性能指標(biāo)等。

·Pilot:控制面的核心組件，為Envoy提供服務(wù)發(fā)現(xiàn)、智能路由（如AB測(cè)試、灰度發(fā)布）和彈性流量管理功能（如超時(shí)、重試、熔斷），負(fù)責(zé)將高層的抽象的路由規(guī)則轉(zhuǎn)化成低級(jí)的envoy的配置。

·Mixer:提供策略檢查和遙測(cè)功能。

·Citadel:安全組件，提供了自動(dòng)生成、分發(fā)、輪換與撤銷(xiāo)密鑰和證書(shū)功能。

TSF Mesh整體架構(gòu)上，其核心能力與開(kāi)源的Istio保持一致，同時(shí)對(duì)envoy、Pilot、Mixer、Pilot-agent組件做了增強(qiáng)，并且新增組件Apiserver和Mesh-dns。外圍能力聚焦在安全性、易用性、可維護(hù)性和可觀測(cè)性，如下圖所示：

運(yùn)營(yíng)支撐提供了運(yùn)營(yíng)端管理和租戶(hù)端管理，比如租戶(hù)端的角色管理，集群管理，命名空間管理，應(yīng)用管理，服務(wù)治理等；運(yùn)營(yíng)端提供資源管理等。監(jiān)控系統(tǒng)提供了日志功能，鏈路追蹤，調(diào)用鏈拓?fù)鋱D，指標(biāo)監(jiān)控等?；A(chǔ)組件為限流、注冊(cè)中心、配置中心、日志采集和實(shí)時(shí)監(jiān)控提供支撐。Paas為應(yīng)用部署提供支撐，比如aPaas等。

TSF Mesh保留Istio所有的原生特性，同時(shí)對(duì)Service Mesh疊加了部分商業(yè)特性，如下：

·平臺(tái)解耦：支持K8S/VM/裸金屬服務(wù)器環(huán)境

·新舊兼容：支持Spring Cloud應(yīng)用、Service Mesh應(yīng)用互通，統(tǒng)一治理

·多租戶(hù)隔離、管理支持

·調(diào)用鏈、日志、監(jiān)控落盤(pán)

·高可用性

03  TSF Mesh產(chǎn)品化挑戰(zhàn)

1.支持異構(gòu)的計(jì)算平臺(tái)

盡管Istio強(qiáng)調(diào)自身可擴(kuò)展性的重要性在于適配各種不同的平臺(tái)，也可以對(duì)接其他服務(wù)發(fā)現(xiàn)機(jī)制，但在實(shí)際場(chǎng)景中，通過(guò)深入分析Istio幾個(gè)版本的代碼和設(shè)計(jì)，可以發(fā)現(xiàn)其重要的能力都是基于Kubernetes進(jìn)行構(gòu)建的。以下面兩點(diǎn)為例：

·服務(wù)配置管理

Istio的所有路由規(guī)則和控制策略都是通過(guò)Kubernetes CRD實(shí)現(xiàn)，可以說(shuō)Istio的APIServer就是Kubernetes的APIServer，數(shù)據(jù)也自然地被存在了對(duì)應(yīng)Kubernetes的Etcd中。如下圖所示：

·服務(wù)發(fā)現(xiàn)及健康檢查

Istio的服務(wù)發(fā)現(xiàn)機(jī)制基于Kubernetes的Services/Endpoints，從Kube-apiserver中獲取Service和Endpoint，然后將其轉(zhuǎn)換成Istio服務(wù)模型的Service和ServiceInstance。同時(shí)Istio不提供域名解析能力，域名訪問(wèn)機(jī)制也依賴(lài)于kube-dns,coreDNS等構(gòu)建。節(jié)點(diǎn)健康檢查能力基于LivenessProbe/ReadinessProbe機(jī)制實(shí)現(xiàn)。

在實(shí)際場(chǎng)景中，TSF的用戶(hù)并非都是Kubernetes用戶(hù)，例如公司內(nèi)部的一個(gè)業(yè)務(wù)因歷史遺留問(wèn)題，不能完全容器化改造，同時(shí)存在VM和容器環(huán)境，場(chǎng)景如下：

從上面的業(yè)務(wù)場(chǎng)景可以看出，業(yè)務(wù)要求能夠?qū)⑵洳渴鹪谧匝蠵aas以及Kubernetes的容器、虛擬機(jī)以及裸金屬的服務(wù)都可以通過(guò)Service Mesh進(jìn)行相互訪問(wèn)。

為了實(shí)現(xiàn)多平臺(tái)的部署，必須與Kubernetes進(jìn)行解耦。在脫離Kubernetes后，Istio面臨以下四個(gè)問(wèn)題：

·服務(wù)的動(dòng)態(tài)配置管理不可用

·服務(wù)節(jié)點(diǎn)健康檢查不可用

·服務(wù)自動(dòng)注冊(cè)與反注冊(cè)能力不可用

·流量劫持不可用

針對(duì)這4個(gè)問(wèn)題，TSF Mesh團(tuán)隊(duì)對(duì)Istio的能力進(jìn)行了擴(kuò)展和增強(qiáng)，增強(qiáng)后的架構(gòu)如下：

增強(qiáng)Pilot的consul適配器，與consul注冊(cè)中心對(duì)接；增加Apiserver實(shí)現(xiàn)元數(shù)據(jù)轉(zhuǎn)換；增強(qiáng)Pilot-agent，實(shí)現(xiàn)VM的自動(dòng)注入，服務(wù)注冊(cè)，envoy管理。經(jīng)過(guò)改造后，Service Mesh成功與Kubernetes平臺(tái)解耦，組網(wǎng)變得更加簡(jiǎn)潔，通過(guò)GRPC和REST API可以對(duì)數(shù)據(jù)面進(jìn)行全方位的控制，可從容適配任何的底層部署環(huán)境，對(duì)于私有云客戶(hù)可以提供更好的體驗(yàn)。

2.支持多租戶(hù)

租戶(hù)的概念不止局限于集群的用戶(hù)，它可以包含為一組計(jì)算，網(wǎng)絡(luò)，存儲(chǔ)等資源組成的工作負(fù)載集合。而在多租戶(hù)場(chǎng)景中，需要對(duì)不同的租戶(hù)提供盡可能的安全隔離，以最大程度的避免惡意租戶(hù)對(duì)其他租戶(hù)的攻擊，同時(shí)需要保證租戶(hù)之間公平地分配共享集群資源。

在公有云或私有云場(chǎng)景下，用戶(hù)對(duì)隱私和隔離看得非常重要。往往不同用戶(hù)/租戶(hù)之間，服務(wù)配置、節(jié)點(diǎn)信息、控制信息等資源數(shù)據(jù)是隔離的，互相不可見(jiàn)。但是Istio本身并不支持這種級(jí)別的隔，需要框架集成者去擴(kuò)展。

Istio依托于kubernetes能力，可實(shí)現(xiàn)“soft-multitenancy”，即單一Kubernetes控制平面和多個(gè)Istio控制平面以及多個(gè)服務(wù)網(wǎng)格相結(jié)合；每個(gè)租戶(hù)都有自己的一個(gè)控制平面和一個(gè)服務(wù)網(wǎng)格。

其它租戶(hù)模式，比如單獨(dú)的Istio控制平面控制多集群網(wǎng)格的場(chǎng)景，Istio并不支持。在這種場(chǎng)景下，每個(gè)租戶(hù)一個(gè)網(wǎng)格，集群管理員控制和監(jiān)控整個(gè)Istio控制面以及所有網(wǎng)格，租戶(hù)管理員只能控制特定的網(wǎng)格。這種場(chǎng)景與云環(huán)境下的多租戶(hù)概念比較穩(wěn)合，對(duì)此TSF Mesh通過(guò)數(shù)據(jù)建模，實(shí)現(xiàn)了這種租戶(hù)模式，即單控制面多集群網(wǎng)格。基本架構(gòu)如下圖所示：

在上圖中，實(shí)現(xiàn)了租戶(hù)管理、租戶(hù)數(shù)據(jù)的隔離存儲(chǔ)、Pilot控制面緩存增加租戶(hù)索引。在這種場(chǎng)景下，各租戶(hù)只能看到自身的集群資源，包括計(jì)算資源、邏輯資源、應(yīng)用資源等，其它租戶(hù)創(chuàng)建的集群資源不可見(jiàn)，sidecar只能從控制端同步到本租戶(hù)的配置和服務(wù)xDS信息。

3.服務(wù)尋址

在侵入式框架下，目標(biāo)服務(wù)的標(biāo)識(shí)通常是服務(wù)名，服務(wù)注冊(cè)與發(fā)現(xiàn)是強(qiáng)關(guān)聯(lián)的，通過(guò)服務(wù)發(fā)現(xiàn)機(jī)制實(shí)現(xiàn)服務(wù)名到服務(wù)實(shí)例的尋址。在Service Mesh機(jī)制下，對(duì)應(yīng)用是無(wú)侵入的，服務(wù)發(fā)現(xiàn)機(jī)制只能下沉到Service Mesh，這意味著客戶(hù)端通過(guò)目標(biāo)服務(wù)標(biāo)識(shí)名稱(chēng)的訪問(wèn)方式，需要域名解析能力的支持。

Istio下的應(yīng)用使用完全限定域名FQDN（fully qualified domain name）進(jìn)行相互調(diào)用，基于FQDN的尋址依賴(lài)DNS服務(wù)器，Istio官方對(duì)DNS服務(wù)器的說(shuō)明如下：

Istio does not provide a DNS.Applications can try to resolve the FQDN using the DNS service present in the underlying platform(kube-dns,mesos-dns,etc.).

從上面的描述看出，Istio并不提供DNS的能力，依托于平臺(tái)的能力，如kubernetes平臺(tái)下的kube-dns。以Istio的官方提供的demo：bookinfo為例，Reviews與Ratings之間的完整的服務(wù)調(diào)用會(huì)經(jīng)過(guò)以下過(guò)程：

從圖上可以看出，Reviews和Ratings的互通，kube-dns主要實(shí)現(xiàn)2個(gè)功能：

·服務(wù)的DNS請(qǐng)求被kube-dns接管

·kube-dns將服務(wù)名解析成可被iptables接管的虛擬IP（clusterIP）

正如前面提到的，用戶(hù)的生產(chǎn)環(huán)境不一定包含kubernetes或者kube-dns，我們需要另外尋找一種機(jī)制來(lái)實(shí)現(xiàn)上面的兩個(gè)功能。

在DNS選型上，有集中式和分布式兩種方案，集中式DNS：代表有kube-dns,CoreDNS等，通過(guò)內(nèi)置或者插件的方式，實(shí)現(xiàn)與服務(wù)注冊(cè)中心進(jìn)行數(shù)據(jù)同步。

集中式DNS存在以下問(wèn)題：組網(wǎng)中額外增加一套DNS集群，并且一旦DNS Server集群不可用，所有數(shù)據(jù)面節(jié)點(diǎn)在DNS緩存失效后都無(wú)法工作，因此需要為DNS Server考慮高可用甚至容災(zāi)等一系列后續(xù)需求，會(huì)導(dǎo)致后期運(yùn)維成本增加。

分布式DNS將服務(wù)DNS的能力下沉到數(shù)據(jù)平面。分布式DNS運(yùn)行在數(shù)據(jù)面節(jié)點(diǎn)上，DNS無(wú)單點(diǎn)故障，無(wú)需考慮集群容災(zāi)等問(wèn)題，只需要有機(jī)制可以重新拉起即可。由于與業(yè)務(wù)進(jìn)程運(yùn)行在同一節(jié)點(diǎn)，因此其資源占用率必須控制得足夠低，才不會(huì)對(duì)業(yè)務(wù)進(jìn)程產(chǎn)生影響。

綜合考慮，最終TSF Mesh選用了分布式DNS的方案，以獨(dú)立進(jìn)程作為DNS Server，如下圖所示

圖中Mesh-dns通過(guò)Pilot同步服務(wù)信息，當(dāng)應(yīng)用通過(guò)服務(wù)名調(diào)用時(shí)，會(huì)進(jìn)入Mesh-dns進(jìn)行域名的本地解析，然后流量被iptables接管，之后到達(dá)envoy，最后由envoy動(dòng)態(tài)路由到upstream；對(duì)于其它非mesh服務(wù)的域名解析，Mesh-dns會(huì)透明傳輸，走默認(rèn)的DNS。通過(guò)配置緩存本地化以及異常退出后自動(dòng)拉起并加載配置，保證在異常情況下的高可用。

值得一提的是Istio暴力流量接管問(wèn)題，這個(gè)也是大家詬病比較多的。由于Istio的數(shù)據(jù)面針對(duì)kubernetes容器內(nèi)流量進(jìn)行全接管，但是對(duì)于虛擬機(jī)或裸金屬場(chǎng)景可能不適用，畢竟虛擬機(jī)或裸金屬上可能不僅僅只有mesh的服務(wù)。因此，需要考慮細(xì)粒度的接管方案，使得mesh與非mesh應(yīng)用在同一個(gè)虛擬機(jī)/容器中可以共存。TSF Mesh對(duì)這塊能力也做了增強(qiáng)，只需要少量的iptables規(guī)則，即可完成mesh與非mesh流量的篩選。

4.與異構(gòu)服務(wù)框架互通

微服務(wù)框架可以分為侵入式和非侵入式兩種，目前比較主流的微服務(wù)框架Spring Cloud，基于Spring Boot開(kāi)發(fā)，提供一套完整的微服務(wù)解決方案，包括服務(wù)注冊(cè)與發(fā)現(xiàn)，配置中心，全鏈路監(jiān)控，API網(wǎng)關(guān)，熔斷器，遠(yuǎn)程調(diào)用等開(kāi)源組件，并且可以根據(jù)需求對(duì)部分組件進(jìn)行擴(kuò)展和替換。與Service Mesh之處不同在于，Spring Cloud是一種侵入式的微服務(wù)框架，需要SDK支撐，并且技術(shù)棧受限于Java。

出于功能重疊、語(yǔ)言壁壘、耦合性，開(kāi)發(fā)運(yùn)維成本，技術(shù)門(mén)檻，云原生生態(tài)等多方面的因素，有相當(dāng)一部分用戶(hù)開(kāi)始嘗試Service Mesh，或者往Service Mesh遷移和轉(zhuǎn)型，但仍然存在一些遺留的Spring Cloud的服務(wù)，希望能與Service Mesh中的服務(wù)互通。用戶(hù)期望支持的架構(gòu)如下圖所示：

在上面這個(gè)架構(gòu)中，最大的挑戰(zhàn)在于涉及了兩個(gè)不同的微服務(wù)框架之間的互通。這兩個(gè)微服務(wù)框架從架構(gòu)模式、概念模型、功能邏輯，技術(shù)棧上，都存在較大的差異。唯一相共的點(diǎn)，就是他們都是微服務(wù)框架，可以將應(yīng)用的能力通過(guò)服務(wù)的形式提供出來(lái)，給外部用戶(hù)調(diào)用，外部用戶(hù)實(shí)際上并不感知服務(wù)的具體形態(tài)。

基于這個(gè)共同點(diǎn)，為了使得不同框架下的服務(wù)能夠正常工作，TSF團(tuán)隊(duì)做了大量的開(kāi)發(fā)工作，將兩個(gè)微服務(wù)框架，從部署模式、服務(wù)及功能模型上進(jìn)行了拉通，主要包括如下幾點(diǎn)：

5.可觀測(cè)性

在上一小節(jié)，提到了Service Mesh與Spring Cloud的能力互通，TSF Mesh為了提供更好的用戶(hù)體驗(yàn)，在日志、監(jiān)控和調(diào)用鏈方面的能力也與Spring Cloud拉通，在envoy標(biāo)準(zhǔn)Tracers能力（envoy.zipkin）的基礎(chǔ)上，增加了envoy.local類(lèi)型，使其支持監(jiān)控和調(diào)用鏈日志落到本地掛載盤(pán)，由TSF的APM系統(tǒng)采集并分析，實(shí)現(xiàn)mesh應(yīng)用與spring應(yīng)用的調(diào)用鏈串接。

如下圖展示了兩種不同微服務(wù)架構(gòu)下，一致的服務(wù)依賴(lài)拓?fù)淠芰?。user、shop、promotion為Service Mesh應(yīng)用，provider-demo為Spring Cloud應(yīng)用，服務(wù)間的箭頭表示了調(diào)用關(guān)系。

04  總結(jié)與展望

TSF Mesh作為騰訊微服務(wù)平臺(tái)TSF的Service Mesh解決方案，在持續(xù)交付中，幫助企業(yè)客戶(hù)解決傳統(tǒng)集中式架構(gòu)轉(zhuǎn)型的困難，打造大規(guī)模高可用的分布式系統(tǒng)架構(gòu)，實(shí)現(xiàn)業(yè)務(wù)、產(chǎn)品的快速落地。本文主要從用戶(hù)實(shí)際場(chǎng)景出發(fā)，挑選了TSF Mesh產(chǎn)品化過(guò)程中遇到的部分典型問(wèn)題和應(yīng)對(duì)的解決方案，進(jìn)行梳理和介紹，希望對(duì)TSF Mesh產(chǎn)品的了解以及技術(shù)演進(jìn)思路有所幫助。還有一些問(wèn)題和解決辦法，涉及較深的技術(shù)細(xì)節(jié)，或顯枯燥，并未一一羅列，比如性能優(yōu)化相關(guān)，mixer相關(guān)，自定義協(xié)議相關(guān)，部署相關(guān)等等。

TSF Mesh團(tuán)隊(duì)擁抱開(kāi)源協(xié)同，努力跟進(jìn)Service Mesh的技術(shù)發(fā)展趨勢(shì)，積極參與社區(qū)貢獻(xiàn)。就技術(shù)發(fā)展趨勢(shì)，有些點(diǎn)仍值得后續(xù)探討，比如控制面單體化，UDPA（通用數(shù)據(jù)平面API）的標(biāo)準(zhǔn)化演進(jìn)，wasm在envoy中扮演的角色，mixer下沉，協(xié)議擴(kuò)展，性能優(yōu)化等等。

回顧過(guò)去，從"Service Mesh"和"Istio"這兩個(gè)詞匯第一次進(jìn)入公眾視野到如今，有將近四年的時(shí)間，見(jiàn)證了數(shù)據(jù)面板的爭(zhēng)奇斗艷，也親歷了xDS的“快速”演變，架構(gòu)與性能之間的妥協(xié)也從未停歇?？傊?，一句話：流年笑擲，未來(lái)可期。