一、概述

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

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

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

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

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

根據(jù)日常工作的總結(jié)，主要是有以上三方面的挑戰(zhàn)：

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

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

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

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

1、開發(fā)和部署：CI/CD 系統(tǒng)提供自動打包和部署

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

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

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

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

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

4、性能監(jiān)控：Trace 系統(tǒng)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

四、微服務所面臨的調(diào)度問題

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

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

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

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

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

① P99/P50 差異可達 10 倍；

② P999/P50 差異可達 20 倍。

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

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

為什么動態(tài)負載均衡難以完美？

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

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

方案二：實時獲取每一臺機器的狀態(tài)，把任務發(fā)給負載最輕的。

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

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

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

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

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

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

我們在 Master 機器上增加了兩個部件，Idle-Queue 和 Amnesia。Idle-Queue 用來記錄目前有哪些 Worker 處于空閑狀態(tài)。Amnesia 記錄在最近一段時間內(nèi)有哪些 Worker 給自己發(fā)送過心跳包，如果某個 Worker 長期沒有發(fā)送過心跳包，那么 Amnesia 就會逐漸將其遺忘掉。每一個 Worker 周期性上報自己是否空閑，空閑的 Worker 選擇一個 Master 上報自己的 IdIeness，并且報告自己可以處理的數(shù)量。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 倍的提升。

五、總結(jié)

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

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

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

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