SACC中國系統架構師大會

2022年10月27日~29日，由IT168旗下ITPUB企業社區平台主辦的第十五屆中國系統架構師大會（SACC2022）在雲端進行網絡直播。本屆大會以「激發架構性能點亮業務活力」為主題，按照技術主線分為傳統架構線（高可用架構、雲架構、分布式存儲）、智能運維線（DevOps、安全設計、網絡架構、數據中心等）、雲原生技術線（雲原生架構、微服務、容器、低代碼）、前沿技術線（5G、DDD、知識圖譜）以及行業架構應用主線（金融行業與製造業），雲集國內CTO、研發總監、高級系統架構師、開發工程師和IT經理等技術人群，力爭為各路豪傑奉獻一場技術的饕餮盛宴。

58同城TEG-AI Lab後端資深工程師魏竹斌受邀出席，於2022年10月28日16:00-16:50在雲架構設計與實踐專場下分享了《58同城深度學習推理平台基於Istio的雲原生網關實踐》。

本文根據分享實錄整理而成，歡迎大家閱讀分享。

導讀

AI正在驅動行業變革，為加速58同城AI應用的落地，AI Lab自2017年9月開始構建機器學習平台WPAI（Wuba Platform of AI），支持機器學習算法一站式開發，以提高AI工程師的研發效率。

圖1 AI Lab產品能力

WPAI包括基礎計算平台、算法應用平台兩部分：

基礎計算平台集中管理GPU、CPU、NPU硬體資源，支持機器學習模型離線訓練和在線推理，在線推理服務支持自動擴縮容（彈性推理服務），離線訓練作業和在線推理服務支持混合部署（離在線混部）。開發者可以向平台申請離線、在線資源，使用機器學習框架開發模型，打造自己的機器學習服務。
為了進一步提高AI工程效率，我們在基礎計算平台之上繼續打造了算法應用平台，包括NLP算法平台WubaNLP、圖像算法平台鳳凰（由58技術委員會AI分會基於WPAI基礎計算平台協同共建）、排序學習平台（應用於搜索、推薦、廣告系統）等。算法應用平台直接集成了相應領域下的常用模型，以Web的方式提供應用，開發者只需要在Web界面做相應配置即可完成訓練和推理，大大提高開發效率。
在AI平台之外，我們還構建了AI周圍子系統，如向量檢索平台vSearch、AB實驗平台日晷，以進一步提高AI工程效率。

WPAI機器學習平台是AI應用的底座，我們基於WPAI打造了靈犀智能語音語義平台、MAI智能營銷引擎、智能寫稿等，感興趣可以添加58技術小秘書（jishu-58）諮詢。

背景

深度學習推理平台在架構上屬於WPAI的子平台，旨在將算法人員使用深度學習框架訓練出來的模型部署到生產環境，提供高性能、高可用的在線推理服務。總體架構如下圖所示，底層依託於Kubernetes和Docker，實現了對GPU/CPU等資源的統一調度和管理，網關側搭配Istio實現了推理服務發現和流量治理功能；算法層集成了TensorFlow、PyTorch和PaddlePaddle等優秀的深度學習框架，同時也支持用戶自定義服務；應用層從模型管理、部署、推理加速和服務高可用保障等方向都提供了一系列功能。支撐了58同城在圖像、NLP、語音、搜索、推薦、廣告、風控領域內的各類AI應用，目前已上線模型數1000+，峰值節點數4000+，日均流量30億。本文主要介紹深度學習推理平台推理架構的演進過程，以及新架構下在流量治理建設和可觀測性建設方面的設計細節。

圖2 深度學習推理平台架構

推理架構1.0

3.1推理架構1.0設計背景

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

在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）。

推理架構2.0

4.1 Istio雲原生網關

為了解決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提供的豐富、開箱即用的流量治理功能，也極大地方便後續開發、運維工作。

2.0架構下流量治理能力建設

從網關角度出發，客戶端流量通常具有不可控、不均衡等特點，而集群內工作負載的流量處理能力雖然可量化但卻並不穩定，作為集群流量的統一出入口，網關的流量治理能力不可或缺。在1.0推理架構下，我們藉助SCF服務分組能力實現了不同業務線間租戶隔離功能，藉助SCF服務管理平台提供了服務監控和告警功能，通過多次版本疊代，在SCF網關內集成了灰度發布、A/B Test、推理超時、秒級限流、節點動態加權負載均衡等功能，保證了推理服務的穩定性，那在2.0推理架構下該如何實現？再者，離在線混部、推理服務自動擴縮容功能的應用使得服務節點上、下線操作變得頻繁，如何保證上、下線期間請求不受影響？下面就將藉由網關多租戶隔離、自適應限流等功能的實現來展示下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 模型預熱配置

2.0架構下可觀測性建設

可觀測性一詞來源於控制理論，是指系統可以由其外部輸出推斷其內部狀態的程度。隨著IT行業在系統監控、告警、問題排查等領域的不斷發展，也逐漸將其抽象形成了一整套可觀測性工程體系，主要包括三部分內容：數據模型、產品工具、觀測能力。其中數據模型是可觀測性建設基礎，主要包括以下三種：

指標(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 推理服務監控指標效果展示

總結

本文主要介紹深度學習推理平台推理架構的演進過程，以及新架構下在流量治理建設和可觀測性建設方面的設計細節。未來我們持續跟進K8S、Istio等基礎設施提供的新特性，豐富平台功能，提升推理性能；持續完善平台可觀測體系建設，讓運維更智能化。

參考文獻：

[1] Pattern: Service Mesh（https://philcalcado.com/2017/08/03/pattern_service_mesh.html）

[2] Istio官方文檔（https://istio.io/latest/docs）

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

[4] Service Mesh Comparison: Istio vs Linkerd（https://dzone.com/articles/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（https://hango-io.github.io/Hango-why-envoy）

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

作者簡介：

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