人工智慧應用微服務化：從模型到線上系統搭建的最佳實踐

人工智慧和微服務是當下最火的兩個技術趨勢，在由七牛雲和極客邦聯合主辦的 QCon2017 北京站「深度學習最新進展與實踐」專場中，深知科技 CEO 陳輝老師分享了團隊從實踐中積累的機器學習微服務化經驗，並通過一些具體的案例展示了如何使用微服務搭建機器學習平台，以及微服務在圖像識別和文本分析上的具體應用。

陳輝，深知科技 CEO

陳輝，AI 領域創業者。機器學習領域專家，曾任職阿里巴巴和 Google，負責廣告精準定向業務和分布式系統開發。熱衷開源軟體，github 主頁 http://github.com/huichen。微服務倡導者。

今天的演講內容會比較偏實操性。首先會給大家展示一個圖像識別的 Demo，並且將代碼進行開放；然後會講一下 Kubernetes 微服務的實踐；第三部分就是 Go + Docker 實現部署的 Tensorflow 深度學習模型。

希望大家從這次分享中能夠得到：

1. 代碼： Go 微服務程序、模型轉換腳本、深度學習訓練代碼

2. 手把手教你在筆記本上跑一個深度學習服務

3. TensorFlow 深度學習模型微服務化的各種坑大揭秘

1. 圖像識別 Demo 演示

解釋一下這個 Demo 。大家應該知道這是 Google 的一個項目，簡單來說就是提供一張圖，用一段非常直白的英文來描述這個圖中的內容。在圖 1 的四個例子中，左邊能識別出來這張圖是一個在海灘上的男人在放風箏，右邊是一個黑白火車的一個圖，火車在鐵軌上。

這個模型其實很簡單，就是 CNN 的模型，Inception V3 + LSTM + word embedding ，最終的輸出是帶有概率的一個狀況。如圖 2 所示。

圖2

2. 微服務之於深度學習

為什麼要有微服務？

如圖 3 所示，這張圖的意思橫軸指的是時間，或者指的是項目的複雜程度，縱軸是這個團隊的生產效益，其中有兩條線分別是描述了兩種不同的開發模式，團隊效率和時間複雜度的一個關係，這條藍色的線是微服務，綠色的線指的是微服務以外單體架構的一個情況。

圖3

最開始當團隊比較小，或項目比較簡單的時候，微服務的優勢沒有那麼明顯。原因在於，最開始的時候為了完成微服務的架構要做很多前期準備工作，要做各種腳本和自動化，所以單體架構其實更能滿足比較簡單的業務需求。

但是隨著複雜度越來越高，單體架構的缺陷會越來越明顯。大家如果用過單體架構會知道，當一個團隊 70 人同時提交代碼的時候，要做很多的測試包括一些集成的工作，才能保證上線的代碼沒有問題。

微服務部分解決了這個問題，原因在於它能夠比較獨立的把各個部門封裝成不同 API 的服務，各個團隊只需要維護自己 API 的內容。

圖4

當團隊比較大，或者服務很複雜的時候，應該儘可能的將服務拆分。我們團隊拆分大概花了三個月的時間，大概拆分了 60 多個微服務，每一個服務是由唯一的一個工程師來負責開發和運維的。

大家可以想到這張圖（圖 4）一共有多少人，60 多個微服務是多少人做的嗎？實際上只有三個工程師。平均每個工程師大概維護 20 到 30 個服務。

我們用的 KOS 整套體系，其中綠色的方塊指的是一個部署，藍色的方塊指一個 SVN 的接入點，中間圓的部分用來做非同步通訊。

這張圖不是手畫出來的，是通過腳本自動生成，因為要求所有的代碼和配置一定要版本化，所有的調用關係都可以在代碼裡面反映出來，所以我們用腳本自動的處理所有的配置文件，最終就可以生成這樣的一張圖。

如果你的團隊號稱是微服務，但你畫不出來這樣一張圖，說明你的微服務自動化上可能存在一定的問題。

微服務三個特點

對於微服務我總結三個特點：

1）調用關係即架構

怎麼去處理這種調用關係，意味著你的架構是什麼樣子的。在我們的架構裡面，圖裡面一定是單向的，不允許出現循環的依賴的關係。因為如果那樣的話，你的項目會出現一個很大的災難，當其中一個點出了問題之後，你會回饋到達一個節點本身，整個服務就會出現這種情況。

2）工程師獨立推動架構演化

因為我們微服務不僅按照項目來切分的，而且是按照人來切分的，所有每一位工程師獨立負責不同的微服務，這樣意味著所有的架構是由我們的工程師——實際上只有三位工程師——獨立推進的。

3）開發即運維

我們沒有運維只有開發的同學，但是我們給開發的同學提供了非常好的運維的工具。從代碼開始，根據配置文件生成新的版本提交到KPS上去，部署上線之後，我們會有一些監控的腳本去核實這個 API 是不是可用，如果沒有問題就可以直接部署上去。

中間也會出現問題，但是對於一個比較小的團隊來說，快速出現問題永遠比不出現問題要好。

微服務技術選型

團隊的技術選型如圖 5 所示。

3. 機器學習系統框架演進

深度學習模型的存儲量主要在 CPU，非常適合用微服務解決。

如果是用 CPU 來做 Kubernetes 的話，深度學習模型的存儲量主要是在 CPU 上，所以使用帶有彈性擴容的微服務架構是比較適合的。圖 6 所示用的是 Concurrency，平均的的 Time per second 是將近 600 毫秒，基於 Kubernetes 實現了這樣一套比較簡單的框架。

圖6

傳統做法、改進做法和最優做法

圖 7 所示是傳統的做法，需要三個不同的部門，因為這個模型是一個 CNN 模型，而且不是一次得到的結果，要反覆做多輪。就是平均來說，一個 VGG 模型在 CNN 上大概需要 40 毫秒左右，所以如果你要去 Serve 一個跟圖象相關的模型，在 CPU 上超過 100 毫秒是非常正常的事情。

以上是常見團隊的劃分。比如需要一些月薪 50K 以上的演算法工程師，他們做的事情就是要搜集清理他們的數據，要訓練模型，要用 Python。然後牛逼的模型就出現了，交給牛逼的系統工程師。

系統工程師發現這個模型不能直接用，要寫一些代碼，就是要把腳本粘合在一起，而且有一些邏輯，比如用 Python 來實現 Bm Sersev 需要一秒的時間，才能生成一句話，這個在線上是無法忍受的。同時發現效率也很差，需要做調優，有一些調優可能涉及到模型的東西，所以要反覆跟演算法工程師溝通，所以用 Java 或者 C++ 把這個東西搞定之後再交給運維工程師。

運維工程師再去運維，運維工程師也很頭疼，本身它的資源耗用率很高，怎麼能夠動態的擴容是很大的挑戰。

圖 7

圖 8 是 2.0 做法，大家也可以把 Tensorflow 這個詞換成其他的框架。50K 的演算法工程師做同樣的事情不變，系統工程師如果做的好的話，可以直接部署這個模型，可以自己運維，可以用 Go 或者 C++，但是這裡面還是有很多坑，從演算法工程師訓練出來的模型到系統工程師直接使用的模型之間有很多的問題。

圖 8

圖 9 則是我們的流程，我們多加了一些錢，花 60K 請能力更強一點的演算法工程師，不給他配人，他自己搞定全棧。

演算法工程師需要自己清理數據、在 GPU 的環境下訓練這個模型，以及用 Go 去載入這個模型部署。需要自己開發及部署，自己運維，而且端到端。

這看起來要求有點高，但是對於創業公司來說很正常，或者對於大公司創業團隊是一定要這樣做的，這樣可以降低內部溝通帶來的一些問題，所幸的是我們團隊成員都做到了這一點。

4. 從訓練模型到模型部署的坑

現在各種各樣深度學習的講座，大家對怎麼部署模型基本上都是很簡單就概括了，只會說內部有一個很牛逼的平台，但是在實際做的時候，就會發現從 Python 訓練出來的模型到最終部署的 C++ 或者 Go 的代碼中間，要有很多工作要做。那些工作其實是非常討厭的。

• Inference 模型需要重新提取

問題描述：訓練模型無法直接使用，inference 要有單獨模型

• 模型外計算效率很差

問題描述：模型之外有其他計算代碼（如 beam search），Python 實現效率很差。

• 模型需要靜態化

問題描述：模型最好靜態化為常量參數，而且要轉化成為單一模型文件，方便載入。

• 容器內部部署 Tensorflow 的環境

解決方案：

首先需要編譯 libtensorflow.so 動態鏈接庫：

這裡面有一個小坑，就是不要用 1.0 的版本，因為 1.0 的版本很奇怪的，他不支持超過 32M 的模型載入，如果模型超過 32M 的話，它限定死了，這個文件不能超過 32M，所以用 git HEAD 版本是可以的；

這裡已經打了一份 Docker 鏡像，如果大家伺服器上已經裝了 Docker，只要一行命令就可以啟動這樣一個服務：

docker run -d -p 8080:80 unmerged/gotalk

現場提問集錦

Q1：你們有 60 個微服務，是不是每一個微服務都是獨立部署的？每個微服務規模代碼大概有多少？

陳輝：一個微服務基本上是一個基本模塊，比如說 VE、ID 的服務，或者一種類型 API 的巨頭，比如說在交易模塊裡面可能有交易模塊，搜索模塊等等，所有這些拆分成小服務；規模如果你指的是代碼量，語言大概是一兩千行代碼。

Q2：部署的時候，像這種微服務，你們覺得會不會太細了？

陳輝：本質上來講，一個模塊是由一個工程師開發的，所以它獨立去開發，我覺得問題應該不大。

Q3：服務機的調用有多少？

陳輝：有一些模塊，比如說唯一 ID 服務，你可以看一下剛才那個圖，比如說最右邊這個負責人，他可能有 20 多個服務會調用它，但是有一些服務依賴關係比較少，根據你服務的情況不一樣。所以對於一些 KPI 比較高的服務，可以增大它的部署 Docker 的數目。

Q4：剛才提到了有一套基本的環境，就是整套微服務代碼存儲的一些服務，我想問一下工程師是作為一個產品，這種服務化的產品還是其他的一些產品？

陳輝：我們是面向企業服務的，所以有一些平台性的東西，我們會部署在自己這邊，有一些需要跟客戶定製的話，我們會部署在客戶那邊，我剛才開放那個是我手工挑選出來的三個項目發給大家，開源是不需要購買的，但是閉源是需要交月費的。

Q5：比如說企業有一些服務是比較大的，你們怎麼來做？

陳輝：微服務並不是說我們給企業做的方案，而是我們內部的一些平台性的產品，企業方面，不一定所有企業都有 Kubernetes ，它相對來說比較簡單，它的模塊是內部的，所以這個只是局限在我們內部，因為這個需要一整套的服務。

活動預告：

七牛架構師實踐日－新時代下的高效運維之道將於 5 月13日在北京舉行，屆時七牛雲高級運維總監高磊、OneAPM 研發總監高海強、唱吧高級運維總監李玉峰、中國站長第一人高春輝將就運維主題帶來精彩分享，感興趣的小夥伴可點擊底部「閱讀原文」報名喲～