作者簡介

本文作者佐思、燒魚、Shirley博，來自于攜程Cloud Container團隊，主要從事Service Mesh在攜程的落地，負責控制面的可用性及優(yōu)化建設(shè)，以及推進各類基礎(chǔ)設(shè)施服務(wù)的云原生化。該團隊負責K8s容器平臺的研發(fā)和優(yōu)化工作，專注于推動基礎(chǔ)設(shè)施云原生架構(gòu)升級，以及創(chuàng)新產(chǎn)品的研發(fā)和落地。

一、背景

為了支撐業(yè)務(wù)的高速發(fā)展，從17年開始，攜程內(nèi)部逐步推進應(yīng)用容器化改造與業(yè)務(wù)上云工作，同期攜程技術(shù)架構(gòu)經(jīng)歷了從集中式單體應(yīng)用到分布式微服務(wù)化的演進過程。

隨著Kubernetes的不斷發(fā)展和推廣，服務(wù)網(wǎng)格（Service Mesh）在近幾年也變得很流行。而 Servive Mesh 之所以越來越受歡迎，在提供更豐富的服務(wù)治理、安全性、可觀測性等核心能力外，其從架構(gòu)設(shè)計層面解決了以上幾個痛點，服務(wù)治理能力以 Sidecar 的模式下沉到數(shù)據(jù)面，解決了 SDK 升級及多語言的問題，對于像負載均衡、熔斷、限流等策略配置，由控制面統(tǒng)一管理和配置，并下發(fā)到數(shù)據(jù)面生效。在整體架構(gòu)上云技術(shù)方案選型上，權(quán)衡各類方案的功能完備性、架構(gòu)擴展性、改造維護成本及社區(qū)發(fā)展等，最終選擇基于Istio構(gòu)建Service Mesh平臺治理方案。

1.1 攜程Service Mesh發(fā)展

從2020年中，我們依托K8S底座能力，進行Service Mesh技術(shù)預(yù)研，深度定制Istio，并與攜程框架部門合作進行了小規(guī)模的落地試點。2021年底，接入非核心應(yīng)用600+，為Service Mesh在攜程的最終落地奠定基礎(chǔ)。到目前為止，生產(chǎn)環(huán)境已有2000個應(yīng)用（業(yè)務(wù)POD數(shù)近1W）接入，預(yù)期下半年推進核心應(yīng)用的接入。

1.2 攜程Service Mesh數(shù)據(jù)表現(xiàn)

在前期應(yīng)用接入過程中，針對Istio穩(wěn)定性（主要在性能）方面，梳理了以下幾個問題：

控制面并發(fā)性能：pilot對象處理的并發(fā)性能是否滿足平臺需求？

控制面配置下發(fā)時效性：配置下發(fā)的延遲及準確性是否能夠滿足業(yè)務(wù)需求？

本文主要分享在當前的體量下，回答上述問題，使控制面平穩(wěn)支撐大規(guī)模 Sidecar 的落地，通過下述優(yōu)化之后，測試域（Istio CR量級在1W+）如下圖所示：

• 從實際生產(chǎn)來看，ServiceEntry的處理效率提升了15倍左右
• 從測試域來看，整體initContext時延從原先P99 30s左右到目前P99 5-10秒左右
• 從測試域來看，整體優(yōu)化水平從原先P99 30s+到目前的P99 15s左右（該處為全量推送水平，其中15s的結(jié)果是平衡資源使用與推送效率調(diào)參的目標值，這里PILOT_DEBOUNCE_AFTER 設(shè)置為10s）
• 開啟增量推送后，實例推送在測試域的推送效果從10-30s縮減至2.5s左右

攜程目前Istio落地版本為1.10

二、Service Mesh優(yōu)化的思路與挑戰(zhàn)

2.1 現(xiàn)狀

針對Service Mesh在攜程落地的服務(wù)目標，可以用一句話進行總結(jié)：能夠通過橫向擴展，支撐萬級業(yè)務(wù)服務(wù)。為了完成上述目標，團隊面臨以下挑戰(zhàn)：

• 當前 Istio的對象處理性能等方面無法滿足平臺需求
• 配置下發(fā)的延遲及準確性無法滿足業(yè)務(wù)需求

經(jīng)過前中期，針對 Istio架構(gòu)進行深入研究以及上線前期測試的性能預(yù)研，核心問題聚焦在以下幾點：

• istio對象處理性能較低：在處理ServiceEntry時的并發(fā)性缺失及WorkloadEntry Selector模式的計算高耗時等
• istio配置推送性能較低：配置推送時對象的全量處理拉長下發(fā)時延，并會隨著Istio對象增長而近線性增長

2.2 優(yōu)化實踐

接下來主要分享攜程所經(jīng)歷過的性能問題，和對應(yīng)的優(yōu)化的方向：

對象處理性能

當前istio使用內(nèi)部queue處理各類Object事件，其為線性處理流程，效率比較低下，為此社區(qū)提供namespace filter方式進行處理，以減緩性能問題，但針對Istio相關(guān)對象，未實現(xiàn)基于namespace的隔離，因此效率提升不太符合預(yù)期。

推送性能

xDS 是 istio 控制面和數(shù)據(jù)面 envoy 之間的通信協(xié)議，其中x 表示多種協(xié)議的集合，可以簡單的把 xDS 理解為，網(wǎng)格內(nèi)的服務(wù)發(fā)現(xiàn)數(shù)據(jù)和治理規(guī)則的集合。 xDS 數(shù)據(jù)量的大小和網(wǎng)格規(guī)模是正相關(guān)的。

當前 istio 下發(fā) xDS 使用的是全量下發(fā) 策略，也就是網(wǎng)格里的所有 sidecar，內(nèi)存里都會有整個網(wǎng)格內(nèi)所有的服務(wù)發(fā)現(xiàn)數(shù)據(jù)。 在大量服務(wù)實例的情況下，全量下發(fā)會影響 Pilot 和 Sidecar 的性能和穩(wěn)定性，雖然Istio 在不斷的演進過程中引入了一些 scoping 的機制，就是 Sidecar 這個 CRD，這個配置可以顯式的定義服務(wù)之間的依賴關(guān)系，但該scoping方案還是無法達到業(yè)務(wù)側(cè)的推送延遲預(yù)期。

首先，簡要介紹一下Istio推送的過程：

注：這里使用海東同學的推送源碼分析圖

根據(jù)上圖結(jié)合源碼可知：

• StreamAggregatedResources  會和當前的 Proxy 創(chuàng)建一個連接，并創(chuàng)建一個接受請求的  reqChannel  。同時開啟一個新的協(xié)程  receiveThread  處理客戶端主動發(fā)起的請求，期間調(diào)用 s.globalPushContext().InitContext(s.Env, nil, nil) 進行數(shù)據(jù)初始化，其中InitContext需要處理Istio 所有CR的全量數(shù)據(jù)（如VirtualServices、DestinationRules、EnvoyFilters和SidecarScopes等），該操作耗時較長，因測試環(huán)境上述對象量級在2w左右，導致執(zhí)行耗時P99 在28s左右。
• 從  con.pushConnection  中獲取到  pushEv  事件后，調(diào)用  s.pushConnection()  進行處理，判斷是否為全量推送：

if pushRequest.Full {
        // Update Proxy with current information.
        s.updateProxy(con.proxy, pushRequest.Push)
}

其中 updateProxy 更新proxy當前信息，主要邏輯如下所示：

func (s *DiscoveryServer) updateProxy(proxy *model.Proxy, push *model.PushContext) {
    s.setProxyState(proxy, push)
    if util.IsLocalityEmpty(proxy.Locality) {
        ...
        if len(proxy.ServiceInstances) > 0 {
            proxy.Locality = util.ConvertLocality(proxy.ServiceInstances[0].Endpoint.Locality.Label)
        }
    }
}


func (s *DiscoveryServer) setProxyState(proxy *model.Proxy, push *model.PushContext) {
    proxy.SetWorkloadLabels(s.Env)
    proxy.SetServiceInstances(push.ServiceDiscovery)
    ...
    proxy.SetSidecarScope(push)
    proxy.SetGatewaysForProxy(push)
}

在 setProxyState 方法中的環(huán)節(jié)獲取SidecarScope等相關(guān)信息。針對上述介紹可以明確下面幾個優(yōu)化方向：

雖然Istio針對K8S對象實現(xiàn)了基于namespace級別的隔離，但未對Istio CR對象實現(xiàn)namespace級別隔離

在 InitContext 方法中， Push()  這么慢，主要是在  req.Full  做全量推送的時候，需要初始化  PushContext  ，初始化  PushContext  的過程中需要調(diào)用  initServiceRegistry 、 initEnvoyFilters 和 initSidecarScopes 等，耗時巨大

2.2.1 Pilot性能優(yōu)化

資源基于Namespace隔離

雖然Istio針對K8S對象實現(xiàn)了基于namespace級別的隔離，但未對Istio CR對象實現(xiàn)namespace級別隔離，基于此，內(nèi)部團隊針對Istio 1.10.3版本針對Istio CR對象實現(xiàn)namespace隔離，使其影響范圍控制在指定namespace 下，其他用戶操作Istio CR而彼此互不干擾，且能夠極大縮減Istio Event事件的處理，加速Pilot啟動速度，提升事件處理效率，促進配置下發(fā)效率，在CR Client結(jié)構(gòu)體中，新增 namespaceFilter 等相關(guān)字段，定義如下：

// Client is a client for Istio CRDs, implementing config store cache
// This is used for CRUD operators on Istio configuration, as well as handling of events on config changes
type Client struct {
    ...


    namespaceInformer v1.NamespaceInformer
    namespaceFilter   filter.DiscoveryNamespacesFilter
    ...
}

截至目前為止，攜程Mesh平臺主要分為SLB、SOA兩大namespace，基于namespace隔離之后，效率提升預(yù)估在50%左右。

ServiceEntryStore 改造

ServiceEntryStore 的數(shù)據(jù)處理性能問題，主要有以下幾點：

• 它里面有一個步驟，會全量更新實例的索引，這意味著 service 有一個發(fā)生變化了，它會更新全部 service 的索引，這是一個量級寫放大
• WorkloadEntry與ServiceEntry的關(guān)聯(lián)查詢的耗時，隨著彼此的數(shù)量逐步放大
  
• configController的Queue隊列為線性處理，效率低下
  

因此，攜程通過針對ServiceEntryStore進行Controller-Runtime改造，將ServiceEntry對象由線性處理改為并發(fā)處理，同時將WorkloadEntry結(jié)構(gòu)體廢棄，選擇直接使用ServiceEntry，業(yè)務(wù)方Operator管理ServiceEntry對應(yīng)Endpoint方式，優(yōu)化處理性能，從實際生產(chǎn)效率來看，ServiceEntry的處理效率提升了4倍左右。

EnvoyFilter增量化改造

通過上述簡介可知， Push() 這么慢，主要是在  req.Full 做全量推送的時候，需要初始化  PushContext ，初始化  PushContext 的過程，都是全量且嵌套循環(huán)處理，因此當多個對象量級巨大，則計算耗時成倍增長，針對EnvoyFilter的全量處理，不涉及其他對象，可以通過定義EnvoyFilterController結(jié)構(gòu)體以Controller方式運行，從而實現(xiàn)全量改增量，結(jié)構(gòu)體定義如下：

type Controller struct {
    xdsUpdater model.XDSUpdater
    client     kube.Client
    queue      controllers.Queue


    // processed ingresses
    envoyFilter map[types.NamespacedName]*wrapEnvoyFilterWrapper


    envoyFilterInformer cache.SharedInformer
    envoyFilterLister   v1alpha3.EnvoyFilterLister


    mutex sync.Mutex


    envoyFiltersByNamespace map[string][]*wrapEnvoyFilterWrapper
}

Sidecar延遲及按需計算

在 InitContext 方法中，除了EnvoyFilter耗時較多外，initSidecarScopes同樣耗時巨大，通過代碼可知, Sidecar 有兩種，一種是帶  WorkloadSelector 的，一種是不帶的。不帶  Selector 的話就是對這個命名空間所有服務(wù)生效。如果沒有手動創(chuàng)建默認的  Sidecar ，Pilot 會通過  DefaultSidecarScopeForNamespace 為當前命名空間創(chuàng)建一個默認的  Sidecar ，會將網(wǎng)格中所有的服務(wù)都遍歷一遍，寫入  SidecarScope 中。 initSidecarScopes 循環(huán)計算如下：

sidecar數(shù)量x(egressConfigs數(shù)量x(selectVirtualServices耗時+selectServices耗時)+out.EgressListeners數(shù)量x(listener.services數(shù)量+listener.virtualServices數(shù)量...))

因SidecarScope涉及其他CR對象結(jié)果，因此無法簡單的由全量改增量，但可以通過延遲計算和按需計算方式，進行效率提升，延遲計算主要通過將 initSidecarScopes 計算邏輯后移至push階段，按需計算即沒必要計算所有Sidecar，只需要根據(jù)鏈接的proxy進行計算即可，通過上述的優(yōu)化，可以做以下針對性調(diào)整：

• 如果集群內(nèi)服務(wù)較多，為每一個應(yīng)用創(chuàng)建一個sidecar，防止所有服務(wù)信息推送給envoy，導致envoy OOM。
• 在上述優(yōu)化之后，InitContext的處理耗時可以從P99 30s下降到P99 5s左右，此時，配置推送效率得到5倍左右的提升，那么 setProxyState 處的耗時，將會被放大，CPU的使用率將會成倍增長，可以通過下述配置進行優(yōu)化。
  

2.2.2 Pilot配置優(yōu)化

啟用 XDS 增量推送

通過給 istiod 配置 PILOT_ENABLE_EDS_DEBOUNCE環(huán)境變量，我們啟用 istiod 的增量推送而無需等待full push。

減少推送量

將 istiod 的 PILOT_FILTER_GATEWAY_CLUSTER_CONFIG 環(huán)境變量配置為 “true”，這樣 Istio 將僅推送 Gateway 所需的服務(wù)信息，這個配置將極大的減少每次推送的量。開啟這個特性之后，集群內(nèi)的 istiod 每次向 Gateway 推送的服務(wù)信息降低90%。

關(guān)閉Headless

將 istiod 的 PILOT_ENABLE_HEADLESS_SERVICE_POD_LISTENERS環(huán)境變量配置為 “false”，因為headless svc對應(yīng)的endpoints發(fā)生了變化，會觸發(fā)full push的行為。

提高吞吐

默認情況下，單個 istiod 的推送并發(fā)數(shù)只有 100，在較大的集群內(nèi)，可能會導致配置生效的延遲。istiod 環(huán)境變量 PILOT_PUSH_THROTTLE 可以配置這個并發(fā)數(shù)。建議根據(jù)集群規(guī)模進行配置。

避免頻發(fā)推送

PILOT_DEBOUNCE_AFTER 與 PILOT_DEBOUNCE_MAX 是配置 istiod 去抖動的兩個參數(shù)。

默認配置是 100ms 與 10s ，這也就意味著，當集群中有任何事件發(fā)生時，Istio 會等待 100ms，如果開啟EDS，則增量推送不會等待。

若 100ms 內(nèi)無任何事件進入，Istio 會立即觸發(fā)推送。否則 Istio 將會等待另一個 100ms，重復(fù)這一操作，直到總共等待的時間達到 10s 時，會強制觸發(fā)推送。實踐中可以適當調(diào)整這兩個值以匹配集群規(guī)模和實際應(yīng)用。攜程內(nèi)部調(diào)高 PILOT_DEBOUNCE_AFTER 到 10s，以避免頻繁推送對性能產(chǎn)生影響，也能夠避免極端情況下推送不及時導致的 503 問題。

三、Service Mesh未來展望

控制面的重心在于解決規(guī)?；瘑栴}，后續(xù)控制面將會在下述領(lǐng)域深入探索：

• 控制?去除對k8s的資源的依賴，推送耗時下降到秒級別，滿?更?規(guī)模的接?
• 使?NDS實現(xiàn)DNS解析功能，避免search域多次查詢，提升Mesh的可?性
  

團隊將與社區(qū)深度合作，針對控制面，密切關(guān)注增量推送等特性，后續(xù)將優(yōu)先實現(xiàn)控制面穩(wěn)定性增強，如下述功能：

• 連接限流：通過限流功能，降低大量Sidecar同時連接同一個 Pilot 實例的風險，減少服務(wù)風暴發(fā)生的機率。
• 熔斷：基于生產(chǎn)場景的壓測數(shù)據(jù)，測算出單實例 Pilot 可服務(wù)的 Sidecar 上限，超過上限值后，新連接會被Pilot 拒絕。
  

Service Mesh作為云原生領(lǐng)域下一代微服務(wù)技術(shù)，經(jīng)過 2 年多摸索與演進，攜程完成了多語言、多場景的業(yè)務(wù)落地， 實際論證了Service Mesh在流量管控、系統(tǒng)擴展性的優(yōu)勢，具有下沉服務(wù)治理能力到基礎(chǔ)設(shè)施層，高度解耦中間件與業(yè)務(wù)系統(tǒng)的可行性。

后續(xù)，攜程將在總結(jié)前期非核心應(yīng)用Service Mesh化改造的基礎(chǔ)上，逐步推進核心應(yīng)用的落地，同步打磨完善平臺能力，全面提升穩(wěn)定性，為行業(yè)落地Service Mesh提供最佳實踐和相關(guān)借鑒。