一、概述

馬斯克收購了推特，但對其技術表示不滿。認為主頁速度過慢是因為有 1000 多個 RPC。先不評價馬斯克所說的原因是否正確，但可以看出，互聯網上為用戶提供的一個完整的服務，背后會有大量的微服務調用。

以微信讀書推薦為例，分為召回和排序兩個階段。

請求到達后，會先從用戶特征微服務拉取特征，把特征組合在一起進行特征篩選，然后調用召回相關的微服務，這一流程還需要乘以一個 N，因為我們是多路召回，會有很多類似的召回流程在同時運行。下面的是排序階段，從多個特征微服務中拉取相關特征，組合后多次調用排序模型服務。獲得最終結果后，一方面將最終結果返回給調用方，另一方面還要將流程的一些日志發送給日志系統留檔。

讀書推薦只是微信讀書整個 APP 中非常小的一部分，由此可見，即便是一個比較小的服務后面也會有大量的微服務調用。管中窺豹，可以意料到整個微信讀書的系統會有巨量的微服務調用。

大量的微服務帶來了什么問題？

根據日常工作的總結，主要是有以上三方面的挑戰：

① 管理方面：主要是圍繞如何高效地管理、開發以及部署大量的算法微服務。

② 性能方面：要盡量提升微服務，特別是算法微服務的性能。

③ 調度方面：如何在多個同類算法微服務之間實現高效合理的負載均衡。

二、微服務所面臨的管理問題

1、開發和部署：CI/CD 系統提供自動打包和部署

第一點是我們提供了一些自動打包和部署的流水線，減輕算法同學開發算法微服務的壓力，現在算法同學只需要寫一個 Python 函數，流水線會自動拉取預先寫好的一系列微服務模板，并將算法同學開發的函數填入，快速搭建微服務。

2、擴縮容：任務積壓感知自動擴縮容

第二點是關于微服務的自動擴縮容，我們采取的是任務積壓感知的方案。我們會主動去探測某一類任務積壓或空閑的程度，當積壓超過某一閾值后就會自動觸發擴容操作；當空閑達到某一閾值后，也會去觸發縮減微服務的進程數。

3、微服務組織：圖靈完備 DAG / DSL / 自動壓測 / 自動部署

第三點是如何把大量的微服務組織在一起，來構造出完整的上層服務。我們的上層服務是用 DAG 去表示的，DAG 的每一個節點代表一個對微服務的調用，每一條邊代表服務間數據的傳遞。針對 DAG，還專門開發了 DSL（領域特定語言），更好地描述和構造 DAG。并且我們圍繞 DSL 開發了一系列基于網頁的工具，可以直接在瀏覽器里進行上層服務的可視化構建、壓測和部署。

4、性能監控：Trace 系統

第四點性能監控，當上層服務出現問題時要去定位問題，我們構建了一套自己的 Trace 系統。針對每一個外來請求，都有一整套的追蹤，可以查看請求在每一個微服務的耗時，從而發現系統的性能瓶頸。

三、微服務所面臨的性能問題

一般來說，算法的性能耗時都在深度學習模型上，優化算法微服務的性能很大一部分著力點就在優化深度學習模型 infer 性能。可以選擇專用的 infer 框架，或嘗試深度學習編譯器，Kernel 優化等等方法，對于這些方案，我們認為并不是完全有必要。在很多情況下，我們直接用 Python 腳本上線，一樣可以達到比肩 C++ 的性能。

不是完全有必要的原因在于，這些方案確實能帶來比較好的性能，但是性能好不是服務唯一的要求。有一個很著名的二八定律，以人與資源來描述，就是 20% 的人會產生 80% 的資源，換句話說，20% 的人會提供 80% 的貢獻。對于微服務來說，也是適用的。

我們可以把微服務分為兩類，首先，成熟穩定的服務，數量不多，可能只占有 20%，但是承擔了 80% 的流量。另一類是一些實驗性的或者還在開發迭代中的服務，數量很多，占了 80%，但是承擔的流量卻只占用的 20%，很重要的一點是，經常會有變更和迭代，因此對快速開發和上線也會有比較強的需求。

前面提到的方法，比如 Infer 框架，Kernel 優化等，不可避免的需要額外消耗開發成本。成熟穩定的服務還是很適合這類方法，因為變更比較少，做一次優化能持續使用很久。另一方面，這些服務承擔的流量很大，可能一點點的性能提升，就能帶來巨大的影響，所以值得去投入成本。

但這些方法對于實驗性服務就不那么合適了，因為實驗性服務會頻繁更新，我們無法對每一個新模型都去做新的優化。針對實驗性服務，我們針對 GPU 混合部署場景，自研了 Python 解釋器 —— PyInter。實現了不用修改任何代碼，直接用 Python 腳本上線，同時可以獲得接近甚至超過 C++ 的性能。

我們以 Huggingface 的 bert-base 為標準，上圖的橫軸是并發進程數，表示我們部署的模型副本的數量，可以看出我們的 PyInter 在模型副本數較多的情況下 QPS 甚至超越了 onnxruntime。

通過上圖，可以看到 PyInter 在模型副本數較多的情況下相對于多進程和 ONNXRuntime 降低了差不多 80% 的顯存占用，而且大家注意，不管模型的副本數是多少，PyInter 的顯存占用數是維持不變的。

我們回到之前比較基礎的問題：Python 真的慢嗎？

沒錯，Python 是真的慢，但是 Python 做科學計算并不慢，因為真正做計算的地方并非 Python，而是調用 MKL 或者 cuBLAS 這種專用的計算庫。

那么 Python 的性能瓶頸主要在哪呢？主要在于多線程下的 GIL（Global Interpreter Lock），導致多線程下同一時間只能有一個線程處于工作狀態。這種形式的多線程對于 IO 密集型任務可能是有幫助的，但對于模型部署這種計算密集型的任務來說是毫無意義的。

那是不是換成多進程，就能解決問題呢？

其實不是，多進程確實可以解決 GIL 的問題，但也會帶來其它新的問題。首先，多進程之間很難共享 CUDA Context/model，會造成很大的顯存浪費，這樣的話，在一張顯卡上部署不了幾個模型。第二個是 GPU 的問題，GPU 在同一時間只能執行一個進程的任務，并且 GPU 在多個進程間頻繁切換也會消耗時間。

對于 Python 場景下，比較理想的模式如下圖所示：

通過多線程部署，并且去掉 GIL 的影響，這也正是 PyInter 的主要設計思路，將多個模型的副本放到多個線程中去執行，同時為每個 Python 任務創建一個單獨的互相隔離的 Python 解釋器，這樣多個任務的 GIL 就不會互相干擾了。這樣做集合了多進程和多線程的優點，一方面 GIL 互相獨立，另一方面本質上還是單進程多線程的模式，所以顯存對象可以共享，也不存在 GPU 的進程切換開銷。

PyInter 實現的關鍵是進程內動態庫的隔離，解釋器的隔離，本質上是動態庫的隔離，這里自研了動態庫加載器，類似 dlopen，但支持“隔離”和“共享”兩種動態庫加載方式。

以“隔離”方式加載動態庫，會把動態庫加載到不同的虛擬空間，不同的虛擬空間互相之間看不到。以“共享”方式加載動態庫，那么動態庫可以在進程中任何地方看到和使用，包括各個虛擬空間內部。

以“隔離”方式加載 Python 解釋器相關的庫，再以“共享”方式加載 cuda 相關的庫，這樣就實現了在隔離解釋器的同時共享顯存資源。

四、微服務所面臨的調度問題

多個微服務起到同等的重要程度以及同樣的作用，那么如何在多個微服務之間實現動態的負載均衡。動態負載均衡很重要，但幾乎不可能做到完美。

為什么動態負載均衡很重要？原因有以下幾點：

（1）機器硬件差異（CPU / GPU）；

（2）Request 長度差異（翻譯 2 個字 / 翻譯 200 個字）；

（3）Random 負載均衡下，長尾效應明顯：

① P99/P50 差異可達 10 倍；

② P999/P50 差異可達 20 倍。

（4）對微服務來說，長尾才是決定整體速度的關鍵。

處理一個請求的耗時，變化比較大，算力區別、請求長度等都會影響耗時。微服務數量增多，總會有一些微服務命中長尾部分，會影響整個系統的響應時間。

為什么動態負載均衡難以完美？

方案一：所有機器跑一遍 Benchmark。

這種方案不“動態”，無法應對 Request 長度的差異。并且也不存在一個完美的 Benchmark 能反應性能，對于不同模型來說不同機器的反應都會不同。

方案二：實時獲取每一臺機器的狀態，把任務發給負載最輕的。

這一方案比較直觀，但問題在于在分布式系統中沒有真正的“實時”，信息從一臺機器傳遞到另一臺機器一定會花費時間，而在這一時間中，機器狀態就可以發生了改變。比如在某一瞬間，某一臺 Worker 機器是最空閑的，多臺負責任務分發的 Master 機器都感知到了，于是都把任務分配給這臺最空閑的 Worker，這臺最空閑的 Worker 瞬間變成了最忙的，這就是負載均衡中著名的潮汐效應。

方案三：維護一個全局唯一的任務隊列，所有負責任務分發的 Master 都把任務發送到隊列中，所有 Worker 都從隊列中取任務。

這一方案中，任務隊列本身就可能成為一個單點瓶頸，難以橫向擴展。

動態負載均衡難以完美的根本原因是信息的傳遞需要時間，當一個狀態被觀測到后，這個狀態一定已經“過去”了。Youtube 上有一個視頻，推薦給大家，“Load Balancing is Impossible” https://www.youtube.com/watch?v=kpvbOzHUakA。

關于動態負載均衡算法，Power of 2 Choices 算法是隨機選擇兩個 worker，將任務分配給更空閑的那個。這個算法是我們目前使用的動態均衡算法的基礎。但是 Power of 2 Choices 算法存在兩大問題：首先，每次分配任務之前都需要去查詢下 Worker 的空閑狀態，多了一次 RTT；另外，有可能隨機選擇的兩個 worker 剛好都很忙。為了解決這些問題，我們進行了改進。

改進后的算法是 Joint-Idle-Queue。

我們在 Master 機器上增加了兩個部件，Idle-Queue 和 Amnesia。Idle-Queue 用來記錄目前有哪些 Worker 處于空閑狀態。Amnesia 記錄在最近一段時間內有哪些 Worker 給自己發送過心跳包，如果某個 Worker 長期沒有發送過心跳包，那么 Amnesia 就會逐漸將其遺忘掉。每一個 Worker 周期性上報自己是否空閑，空閑的 Worker 選擇一個 Master 上報自己的 IdIeness，并且報告自己可以處理的數量。Worker 在選擇 Master 時也是用到 Power of 2 Choices 算法，對其他的 Master，Worker 上報心跳包。

有新的任務到達時，Master 從 Idle-Queue 里隨機 pick 兩個，選擇歷史 latency 更低的。如果 Idle-Queue 是空的，就會去看 Amnesia。從 Amnesia 中隨機 pick 兩個，選擇歷史 latency 更低的。

在實際的效果上，采用該算法，可以把 P99/P50 壓縮到 1.5 倍，相比 Random 算法有 10 倍的提升。

五、總結

在模型服務化的實踐中，我們遇到了三個方面的挑戰：

首先是對于大量的微服務，如何進行管理，如何優化開發、上線和部署的流程，我們的解決方案是盡量自動化，抽取重復流程，將其做成自動化流水線和程序。

第二是模型性能優化方面，如何讓深度學習模型微服務運行得更加高效，我們的解決方案是從模型的實際需求出發，對于比較穩定、流量較大的服務進行定制化的優化，對于實驗型的服務采用 PyInter，直接用 Python 腳本上線服務，也能達到 C++ 的性能。

第三是任務調度問題，如何實現動態負載均衡，我們的解決方案是在 Power of 2 Choices 的基礎上，開發了 JIQ 算法，大幅緩解了服務耗時的長尾問題。