人物 | 魏竹斌：58同城深度學習推理平臺基於Istio的雲原生閘道器實踐

每一種系統架構的設計都有其特定的歷史背景，我習慣從需求驅動和技術支撐兩方面去分析。

在WPAI上線之前，為支撐業務的快速發展，實現AI應用的快速落地，集團各業務部門只能選擇各自為戰，獨立開發推理相關功能，但因為缺乏平臺化管理、監控等能力，難免會出現研發、運維效率低下的問題；再加上演算法與工程沒有明確邊界，導致演算法同學深陷工程泥潭，無法將有限的精力聚焦在模型最佳化上，模型迭代效率也不盡如人意，所以集團對AI平臺化能力有著迫切的需求。

從技術支撐角度看，由於K8S叢集內外網路是不聯通的，所以我們需要在叢集邊緣架設閘道器來打通整套推理流程，而當時集團自研的Java系RPC框架-SCF在經過多次版本迭代和集團多條業務線在生產環境的檢驗後，已經具備成熟的服務治理能力（如超時、限流、監控、告警等）、強大的橫向擴充套件能力及高可用保障，並且對業務方來說基本沒有學習和使用成本，所以為了滿足業務方快速接入的需求，我們選用SCF作為閘道器實現搭建了我們1.0版推理架構。

圖3 SCF整體架構

3.2推理架構1.0設計實現

推理架構1.0中的SCF閘道器屬於傳統API閘道器實現，下面我將使用當下比較流行的資料面和控制面概念對其進行描述。

控制面側主要包括三大模組：

      1、向下連線K8S叢集，透過K8S List/Watch機制實現了服務註冊發現功能，基於Endpoints構建了面向模型的、細粒度的gRPC連線池。

      2、向上連線AI管理平臺，透過WConfig（58自研配置中心）實現模型執行時引數的實時同步功能，例如超時時間、限流閾值等。

      3、基於WOS（58自研物件儲存服務）打造了協議轉換jar外掛中心。這裡需要著重解釋下：因為SCF閘道器無法透傳gRPC請求，這要求我們在閘道器內部將每一個SCF請求轉換為gRPC請求後，再轉發給後端模型服務，返回資料同理。為實現這一功能，平臺提供了標準協議轉換介面，演算法人員需要在模型上線前基於平臺提供的介面實現模型特有的請求和返回資料資料轉換邏輯，打成jar包後再透過平臺管理介面上傳到外掛中心。

資料面側則圍繞服務治理相關功能打造了請求處理的Pipeline：包括鑑權、秒級限流、協議轉換jar包熱載入（收到模型第一次推理請求時透過自定義類載入器載入jar包）、Request/Response協議轉換、加權負載均衡、流量轉發、日誌與異常處理等功能。

圖4 推理架構1.0實現

3.3 推理架構1.0不足

推理架構1.0的上線，很好地解決了集團線上推理平臺化能力缺失的問題，解耦了演算法同學和工程同學的工作職責，提高了演算法迭代和工程研發的工作效率。但隨著接入方不斷增多，業務方模型迭代需求的增加，1.0架構逐漸暴露出一些不足：

       業務接入角度：協議解析Jar包的編寫和上傳，使得接入流程稍顯複雜，增加了演算法人員模型除錯成本，而且接入方式單一，不支援HTTP方式接入。

       服務效能角度：一方面SCF與gRPC協議互轉會增加推理耗時；另一方面，SCF網路通訊層是基於Netty實現的，Netty會給每一個SocketChannel分配一定的緩衝區（ByteBuffer）用於資料的讀取，緩衝區大小直接影響服務的效能（分配過大會增加GC的回收壓力，分配過小又會觸發擴容，進而執行記憶體複製操作）。在Netty實現中，提供了一種“可預測性”的緩衝區分配機制來解決這個問題（核心實現參見io.netty.channel.AdaptiveRecvByteBufAllocator class），然而這套機制對size較大請求不太友好，例如圖片美化類推理場景，當輸入圖片的size超過1M的時候，緩衝區會擴容到16M，所以SCF客戶端連線數直接決定服務端JVM老年代的記憶體佔用情況，隨著接入規模增加會因為GC問題導致推理效能抖動。

       開發運維角度：閘道器實現與第三方庫緊密耦合，整合新功能或第三方庫升級都需要對閘道器進行整體升級，成本較高（此處不得不提Log4j）。

為了解決1.0推理架構這種傳統閘道器實現所暴露的問題，我們決定升級推理架構，擁抱雲原生閘道器Istio。Istio的定義關聯甚廣，快速瞭解Istio最好的方式就是從它的誕生時間線入手：

       2012-2013年移動網際網路開始興起，企業對服務迭代效率提出了更高的要求，應用程式架構開始從單體逐漸轉向微服務，服務規模開始初步增長。

       2013年Docker開源，提供了更輕量級的虛擬化方案，解決了應用封裝、隔離和移植性問題。

       2014年Google宣佈開源Kubernetes，為容器編排和生命週期管理提供了標準解決方案，叢集向大規模、分散式快速發展，服務數量激增，拓撲鏈路複雜。

       2016年Buoyant公司CEO William Morgan首次提出ServiceMesh定義：服務網格是一個基礎設施層，用於處理服務間通訊；雲原生應用有著複雜的服務拓撲，服務網格保證請求在這些拓撲中可靠地穿梭；在實際應用當中，服務網格通常是由一系列輕量級的網路代理組成的，它們與應用程式部署在一起，但對應用程式透明。並同年釋出第一代ServiceMesh產品—Linkerd。

       2016年Envoy代理開源，在Lyft作為邊緣代理得到生產級驗證，作為可程式設計代理時代里程碑產品，其定義的xDS(x Discovery Service)協議更是在雲原生場景中大放異彩。

       2017年Google、IBM 和 Lyft 聯合宣佈開源Istio ，確定了資料平面和控制平面的組成以及 Sidecar 模式，被稱為第二代ServiceMesh產品，ServiceMesh理念深入人心。

       2018年雲原生計算基金會（後簡稱CNCF）重新定義雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和宣告式API。

圖5 Istio誕生時間線

總結而言：Istio是一個與K8S緊密結合的、適用於雲原生場景的、ServiceMesh形態下的、用於服務治理的開放平臺，提供流量管理、安全性、可觀測性三大核心功能。

Istio因為ServiceMesh而名聲大噪，但它又不僅僅是一個ServiceMesh產品，因為相較於Linkerd而言，它預設提供了K8S Ingress的解決方案（基於可程式設計代理Envoy）來處理叢集內南北向流量，而且相較於業界其他型別的Ingress Provider（例如Kong），Istio具備以下優勢：

       優質的基因。Envoy作為邊緣代理在Lyft公司中得到生產驗證，隨後成為CNCF第三個畢業的專案；CNCF正式將Service Mesh寫入雲原生第二版定義 ，Istio也於近期成為 CNCF 孵化專案；控制面和資料面隔離架構，搭配xDS動態配置同步方案。

       全面的能力。包括強勁的代理效能，基於c++實現了全非同步事件機制驅動；豐富的流量治理能力，如請求路由、負載均衡、超時、限流、熔斷等，開箱即用；強大的可觀測性支援，具有詳細的監控指標，完整的訪問日誌；靈活的可擴充套件性，可以基於Filter、Lua和WASM方式增強功能。

       強勁的勢頭。2020年CNCF中國雲原生調查顯示：去年排名第四的Envoy近1年內使用量明顯上升，從15%的份額增長到29%，超過F5和HAProxy躍居第二；Istio/Envoy在谷歌、微軟、阿里、騰訊等等國內外頭部公司大規模落地應用，已然成為服務網格/資料面代理的事實標準。

鑑於上述種種，我們最終選擇基於雲原生閘道器Istio來打造我們的2.0版推理架構。

4.2 推理架構2.0實現

推理架構2.0實現如圖6所示，可分為模型服務層、閘道器層和業務應用層。

圖6 推理架構2.0

模型服務層同1.0推理架構相比並無修改，因為基於以下幾點原因考慮，我們沒有啟用Istio的Sidecar方案：

       1、線上推理屬於典型的端到端場景，沒有東西向流量需求。

       2、Istio的Sidecar方案是基於iptables實現請求轉發功能的，會有一定的效能損耗，影響推理效能。

       3、大量的Sidecar容器對於叢集資源來說也是不小的負擔，而且會增加運維管理的複雜度。

架構設計，複雜是萬惡之源，雖然Istio的Sidecar方案是開箱即用的，但我們也要按需使用。

閘道器層則是Istio的原生架構，Istio將控制面Istiod和資料面Ingress Gateway拆分成兩個程式獨立部署以保證資源隔離，互不影響。控制面Istiod包括三大模組：Citadel透過內建的身份和憑證管理實現了強大的服務到服務和終端使用者身份驗證，可以在網格中啟用授權和零信任安全性；Galley是 Istio 配置驗證、提取、處理和分發元件；Pilot為資料面代理提供服務發現、流量管理功能和彈性。資料面Ingress Gateway則又包括Envoy和Pilot-agent兩部分，Envoy具體執行流量代理功能，而Pilot-agent 則負責為Envoy生成靜態配置檔案及Envoy生命週期管理，Pilot-agent就像是Envoy的"Sidecar"。總體來說，閘道器層中控制面向下感知叢集內節點執行狀態變化，向上透過標準介面接收應用層對閘道器行為配置的變更，再對所有資訊進行整合後，透過標xDS協議實時推送給資料面；資料面依據這些資訊來決定如何管理使用者流量，例如執行負載均衡，限流熔斷等策略。兩者各司其職，真正做到了高內聚、低耦合。

業務應用層又可分細分為資料面和控制面。資料面側為了方便使用者的接入及後續流量的管理，我們以部分為粒度做了多租戶的隔離，透過域名+ 58DNS + CLB的組合實現了閘道器的負載均衡和高可用；在控制面側，我們封裝了K8S Manager Service做為業務操作K8S+Istio資源的統一入口，標準化了查詢和變更行為。K8S Manager Service向上對接各種業務場景的呼叫，例如在web頁面修改了模型推理超時配置等場景。

4.3 推理架構升級應用效果

透過此次架構升級，實現了推理平臺從效能、穩定性、易用性方面的全面提升。推理耗時相對於1.0架構減少了50%以上；資料面和控制面從部署層面實現資源隔離，使得服務更加穩定；Istio提供的豐富、開箱即用的流量治理功能，也極大地方便後續開發、運維工作。   

5.1 Istio流量治理基礎-宣告式API

宣告式API，其實就是K8S提供的CRD擴充套件，Istiod中Pilot模組透過List/Watch機制監視所有CRD資源的變更，並將最新的配置整合後同步到資料面代理。在Istio內部定義了上百種CRD，我們簡單介紹其中最常用的四個：

       Gateway：抽象閘道器在L4-L6層負載均衡屬性，例如暴露埠、協議等。

       VirtualService：配置L7層流量路由規則，可以在流量埠、header 欄位、URI 等內容上設定匹配條件，將流量到路由到適當的目標，同時還可以使用路由規則在流量上執行特定操作，例如新增刪除header、重寫URL、為請求設定重試策略等。

       DestinationRule：定義目標服務或其子集，以及呼叫轉發到目標服務或其子集時的流量策略，例如負載均衡策略、熔斷器設定等。

       EnvoyFilter：Istio外掛機制，定製Envoy請求處理邏輯，例如服務Metrics統計、限流等。

在圖7的例子中，Gateway、VirtualService、DestinationRule三種CRD透過name或label關聯到一起，意思是將所有請求*search.wpai.58dns.org:8866並且header包含taskid=666資訊的流量透過輪訓的方式路由到k8S中名稱為service-666的服務所包含的工作負載上。

圖7 宣告式API架構

5.2 閘道器多租戶實現-Gateway拆分

Istio中，Gateway可以部署任意多個，可以共用一個，也可以每個租戶、namespace單獨隔離部署。為了減少閘道器故障爆炸半徑，在保證推理質量的同時兼顧閘道器資源使用率，我們綜合考慮了業務線特徵和流量特徵，將閘道器叢集與namespace之間按照1:1和1:N關係進行了拆分。如圖7是一個閘道器拆分的簡易示例圖，其中test和search namespace都單獨部署了一套閘道器叢集，而其餘的namespace則共用另一套閘道器叢集。

圖8 閘道器拆分示意圖

5.3 自適應限流實現

Istio在Gateway側預設提供了全侷限流和本地限流兩種限流方案。全侷限流需要訪問外部限流服務，在我們高併發測試case中，效能表現差強人意，所以我們選擇了本地限流方案。本地限流是基於Envoy內部提供的令牌桶演算法實現的，透過EnvoyFilter對外提供配置介面，限流配置最小粒度為route（路由），對應K8S中Service的概念，在我們推理場景下即為任務。但是在彈性擴縮容執行機制作用下，任務副本數會隨著流量和自身負載的變化而變化，而任務所能承載的總QPS是由副本數*單副本QPS計算而來，所以為了達到精準限流的效果，我們實現了自適應限流功能，核心邏輯包含以下兩步：

        1、基於平臺可觀測體系監測任務畫像的變更，此處主要指任務副本數。

        2、將副本變更事件經過防抖動處理後，轉換得到任務總QPS，然後透過請求K8S Manager Service來修改EnvoyFilter中任務的限流配置。

圖9 自適應限流方案

5.4 無損上線實現-模型預熱

線上推理場景下，新節點會在首次收到推理請求時，才將模型檔案載入到記憶體/視訊記憶體中，該過程耗時較長，當流量較高時就會導致大量請求阻塞、響應超時甚至資源耗盡最終當機。為了達到節點無損上線要求，我們提供了模型預熱功能，可在任務節點服務釋出之前透過預熱流量提前觸發模型載入流程。

圖10 模型預熱實現方案

首先，考慮到不同的模型對於預熱時長的要求不一樣，我們引入了K8S提供的Startup探針和Readiness探針，其中Readiness探針決定容器服務釋出（探針檢測成功）和下線時機（探針檢測失敗），Startup探針負責檢測容器服務是否啟動成功，並且只有Startup探針檢測成功後，Readiness探針才會啟動。兩個探針的可配置屬性相同，這裡主要利用了initialDelaySeconds這一屬性，在Startup探針中表示容器啟動多長時間後探針開始檢測，在Readiness探針中則表示Startup探針檢測成功多長時間後探針開始檢測，所以透過將Readiness探針中的initialDelaySeconds屬性設定為預熱時長，即可實現服務啟動到服務釋出間隔時長的精準控制，業務方可按需配置預熱時長，做到充分預熱。

再者，不同模型對於輸入、輸出格式要求也各不相同，為此我們對線上模型及推理請求進行整理後抽象出一套模型配置檔案，基於策略模式思想，依靠配置檔案打造了模型專屬的預熱客戶端，演算法同學只要按規定上傳配置檔案後，即可在服務啟動之後，在服務內部傳送預熱請求，提前觸發模型的載入邏輯。

圖11 模型預熱配置

        指標(Metrics)：是一段時間內記錄的各個維度的量化資訊，用來觀察系統的某些狀態和趨勢。

        日誌(Logs)：是帶有時間戳的、結構化或非結構化的、對程式執行過程中目標事件的記錄。

        鏈路追蹤(Traces)：是請求從開始到結束完整生命週期內呼叫鏈路的記錄（主要用在微服務場景）。

圖12 可觀測性架構

可觀測性是Istio的核心功能之一，內部提供了豐富的生態支援，但是因為對閘道器來說最重要的服務指標（例如延遲、流量、異常量等），Istio需要藉助Sidecar才可以生成，所以我們並沒有使用Istio提供的指標生成和採集方案，而是基於Istio的訪問日誌打造了自己的可觀測性建設方案，如圖13所示：

圖13 2.0架構下可觀測建設方案

閘道器結構化(json)訪問日誌及推理服務非結構化日誌皆從磁碟採集併傳送到對應Kafka，後藉助ELK元件實現傳輸、儲存及視覺化，圖14為閘道器訪問日誌視覺化示例。

監控指標包括服務（流量）監控指標和資源監控指標。服務監控指標使用Kafka中閘道器結構化日誌為資料來源，透過流式計算引擎Flink計算得到維度豐富（基礎指標+二次加工指標）、層級多樣(部門級、任務級、副本級等)、跨度靈活（分鐘級、秒級）的服務監控指標，並同時sink到ES及Kafka中；資源監控指標由cAdvisor採集計算，Prometheus負責傳輸和儲存，同時為了構建實時任務畫像，我們透過Prometheus-Kafka-Adapter將所有資源監控指標實時同步到了Kafka中。

監控指標透過Grafana大盤實現查詢、視覺化工作，併為監控報警、服務治理和彈性擴縮等功能提供資料支撐。

圖14 閘道器訪問日誌視覺化效果展示

圖15 推理服務監控指標效果展示

參考文獻：

[1] Pattern: Service Mesh（）

[2] Istio官方文件（）

[3] Beyond Istio OSS —— Istio 服務網格的現狀與未來（https://jimmysong.io/blog/beyond-istio-oss）

[4] Service Mesh Comparison: Istio vs Linkerd（）

[5] 2020年CNCF中國雲原生調查（https://www.cncf.io/blog/2021/04/28/cncf-cloud-native-survey-china-2020）

[6] Hango-雲原生閘道器實踐，為何選擇Envoy（）

[7] 雲原生閘道器的可觀測性體系實（https://mp.weixin.qq.com/s/Hb7vZWhO4ul4L4of6IDCrw）

作者簡介：

魏竹斌，58同城TEG AI Lab AI平臺部後端資深工程師 。2020年7月加入58同城，目前主要負責深度學習推理平臺和vSearch向量檢索平臺相關建設工作。