一、概述
馬斯克收購了推特，但對其技術表示不滿。認為主頁速度過慢是因為有 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 演算法，大幅緩解了服務耗時的長尾問題。
#
以上是微信 NLP 演算法微服務治理的詳細內容。更多資訊請關注PHP中文網其他相關文章！
