AI 公司該如何設計基於微服務的 AI SaaS 架構丨硬創公開課

雷鋒網按：技術圈流傳這樣一句話「人工智慧背後的架構和工程問題是武當少林，屬於內功。而演算法則是招式，講究一時之快。」

再強的演算法均需強大的架構和工程作支撐，兩者缺一不可。

那麼 AI 公司該如何設計承載產品背後龐大複雜的演算法、工程核心架構？本期雷鋒網(公眾號：雷鋒網) AI 科技評論特邀極限元 CTO 康利強為大家講述《AI 公司該如何設計基於微服務的 AI SaaS 架構》。

嘉賓介紹

康利強，極限元 CTO，親自主導搭建了支撐極限元現有語音識別、計算機視覺、人機交互解決方案的構架；20 年軟體研發、架構設計以及項目管理經驗，前億贊普集團核心架構設計專家；美國 Borland 軟體公司中國機構分散式存儲架構師及項目負責人。

本期公開課視頻（共 44 分鐘）

如想獲取本期公開課的 PPT 資源，關注雷鋒網人工智慧垂直微信公眾號「 AI 科技評論」，在後台回復關鍵詞「架構」，即可收到本期公開課 32 頁的 PPT 下載鏈接。

以下為分享正文：

今天我給大家分享的內容是，基於微服務的 AI Saas 架構設計。

既然要設計 SaaS 架構，先要了解何為 Saas？SaaS 是雲計算的一種服務形式，關於雲計算，我先簡要做個介紹：

一、雲計算簡介

• 什麼是雲計算？

• 雲計算的分類（分層）

• 雲計算新的服務方式

什麼是雲計算

雲計算是一種計算資源，按量付費，也就是你用多少就支付多少費用，可以便捷的訪問，通過網路進入可配置的資源池，（資源包括網路，伺服器，存儲，應用軟體，服務），這些資源能夠被快速提供，我們只需投入很少的管理工作，或與服務供應商進行很少的交互。

2006 年 8 月 ，Google 提出雲計算的概念，到今天經過了 10 年的發展，雲計算越來越為大家所接受，很多人也在使用雲計算提供的服務，比如雲主機、雲存儲、網盤、雲分發、雲筆記等等；今天的直播也會用到其中的幾項服務，比如雲存儲、雲分發，由於用到雲分發，所以大家在看直播的時候會有一個比較低的延時。

雲計算的分類

接下來介紹 SaaS，除了SaaS 外，雲計算也包含其他幾種類型：

主要有以下幾種類型：

• IaaS(Infrastructure-as-a- Service)：基礎設施即服務。消費者通過 Internet 可以從完善的計算機基礎設施獲得服務。也就是雲主機，比如亞馬遜雲，微軟雲，阿里雲等。

• PaaS(Platform-as-a-Service)：平台即服務。PaaS 實際上是指將軟體研發的平台作為一種服務，以 SaaS 的模式提交給用戶。因此，PaaS 也是 SaaS 模式的一種應用。PaaS 的出現可以加快 SaaS 的發展，尤其是加快 SaaS 應用的開發速度。需要用戶有一定的開發能力，比如谷歌的 GAE。

• SaaS(Software-as-a-Service)：軟體即服務。它是一種通過 Internet 提供軟體的模式，用戶無需購買軟體。例如：各種雲存儲，網盤、雲筆記。

近些年隨著 Docker 的發展，出現了一種新的服務形式：CaaS。

CaaS (Containers-as-a-Service): 容器即服務這是隨著近幾年docker的火熱而出現的一種新的服務形式，使應用的打包與部署自動化，創建輕量、私有的 PAAS 環境，使持續集成/部署、測試自動化，部署可伸縮的 web app、資料庫和後台服務。

因為 docker 基於 Linux Container（Namespace，cgroup,chroot等），抽象出 Libcontainer 的介面，docker 運行於 Libcontainer 介面之上而不關心底層實現，所以這種服務就叫做 CaaS。

雲計算的分類

這是一個簡化版的雲計算分類，通過這個圖可以一目了然看到它們之間的關係。

二、應用架構模式

既然講架構設計，所以要了解一下架構模式，題目是基於微服務的架構設計有微服務，那麼是不是有宏大的服務呢，答案是肯定的。

一般來說，有以下兩種架構模式：

• 單體式架構（Monolithic Architecture）

• 微服務架構（Microservices Architecture）

什麼是單體式架構？

下面我們來看一下單體式架構：

單體式架構就是所有功能打包運行在一個進程，比如一個war包，從這個架構圖我們也可以看到，這是一個叫車應用，中間部分是一個整體，包含很多功能，有乘客管理，通知，支付，司機管理 ，路線規劃等功能。

優點是開發，部署，測試，水平擴展比較容易，可以放到一個工程，打一個包，擴展的時候只把這一個包複製到新的位置即可。缺點就是隨著功能增多，代碼變多， 維護成本高，交付周期長。

與此同時，不同模塊發生資源衝突時，擴展將會非常困難。造成資源的浪費，有的要大內存，有的高帶寬，有的要大的存儲空間等。為了同時滿足這些條件，這樣就造成了資源的浪費。

還有一個問題是，技術選項成本高，必須謹慎選擇，因為一旦選定很難更改，如果要更改的話，肯能要全部推到重來。另外可靠性也存在問題，一個模塊故障會影響整個服務。

什麼是微服務架構？

在了解微服務之前，首先了解什麼是微服務，其次需要了解微服務架構的設計要點，最後需知道微服務的優缺點。先看一下什麼是微服務？

微服務沒有一個公認的確切定義，但是有一些共性，微服務是是面向服務架構的一種特例，有以下特性：

• 容易替換（升級）。

• 服務輕量級，可獨立部署，構建發布自動化。

• 與其他服務通過網路協作完成任務。

• 根據功能來劃分服務，比如用戶前端，推薦，物流，賬單等。

• 可以用不同的語言、資料庫、軟硬體實現。

所以微服務本身天然就具有模塊化特性，適合於持續交付的開發部署，業務改變只需要重新發布部署少量的服務。了解微服務以後，進入今天的主題：為微服務架構設計。

微服務架構設計

微服務架構的優缺點

三、基於微服務的 AI SaaS 架構設計

我們知道，人工智慧的核心是機器學習，因為機器不會自己學習，所以要明確指明一些特徵來讓機器知道符合這個條件的是什麼，符合那個條件的是什麼，這就需要編寫複雜的程序來讓機器來學習，在某些場合，隨著需要的特徵約來越多，編寫程序越來越困難，我們無法用足夠實用並且可靠的方式明確指定所要優化的特徵。

以讓機器識別一隻貓為例，假設這隻貓是白色的，先不考慮其他特徵，只說顏色特徵。其它特徵+白色這兩個特徵讓計算機知道這是一隻貓，那麼來一隻黑色貓就不認識了，或者來一隻加菲貓計算機就有可能就會把它識別成色情圖片了。

這就導致所需的特徵越來越多，這時候發現程序沒法寫了。於是深度學習順勢而生，大量數據通過深度神經網路的訓練，讓計算機學習，機器會自己提取特徵並跟測試集來比較，然後自己調整進行下一輪的訓練，直到訓練出合適的結果。所以說目前的 AI 更多是數據的比拼。

為什麼需要 AI Saas 服務？

首先我們要了解 AI 能做什麼，AI 可以做一些色情檢測、廣告檢測、涉爆涉恐言論以及電信詐騙檢測，這些都是 AI 可以做的事情。用 AI 來做的話可以節省大量的人力，但是，不是所有公司都有能量構建 AI 系統，從上圖中可以看出，構建 AI 系統需要大量數據，需要大量計算資源，需要專業技術人員。

所以隨著社會分工越來越細，專註於自己的業務，專業的事情交給專業的公司來做就好，避免自己精力過於分散。以直播平台為例，其需要檢測上面所述的一些違規內容，也可以用 AI 來檢測。但是不一定要自己做 AI 系統，你可以把更多的精力放在直播的流暢度、延時、互動性等提升上。

為什麼微服務架構比較適合 AI SaaS

由於 AI SaaS 需要提供多種服務，不同的服務需要不同的計算資源，AI 演算法需要 GPU 資源，所以微服務的架構更適合 AI SaaS。

四、SaaS 架構設計

傳統的架構設計一般從這 5 個方面來設計，所謂的五視圖：邏輯架構，開發架構，運行架構，部署架構，數據架構。

邏輯架構主要是考慮需求，並根據職責劃分邏輯層，子系統、子模塊兒，同時考慮模塊兒的介面。

開發架構：源文件管理，工程組織方式，依賴的庫、框架，以及構建系統。

運行架構：子系統需要幾個進程，進程之間怎麼通信，以及怎麼啟停。

部署架構：系統的物理架構，需要那些伺服器，伺服器之間的網路拓撲結構，以及系統運行到那些伺服器上。同時還需要考慮冗餘，因為系統出問題是必然的。

1.邏輯架構

邏輯架構是根據需求劃分的幾個邏輯層，主要分為接入層，業務層，存儲層，管理層，這幾層分別有不同的服務。

• 整體架構

• 

  上面講到邏輯架構要根據需求劃分子系統，子模塊，以及定義模塊的介面。對應的微服務架構的話就是怎麼根據需求分解成微服務，以及怎麼定義服務間的通訊介面。與單體應用不同的是還需要確定服務的位置，所以需要服務定位。此外，由於微服務通過網路來訪問，所以需要有對應的故障處理機制。

• 服務的劃分

所以下面就從服務的劃分，介面設計，服務定位（註冊與發現），故障處理來講解一下邏輯架構。

第一，服務的劃分，服務劃分的原則跟面向對象設計原則基本一致，單一職責，高內聚，低耦合。我們知道對於需求來說分為功能性需求跟非功能性需求，那麼微服務也按這種方式來劃分。

首先來看功能性需求：

API Server api 的接入，認證，負載均衡。

Service Registry服務註冊與發現。

AI 網關：AI 服務的流量控制與負載均衡。

AI 服務：提供 AI 服務，比如圖像識別，語音識別等。

計費服務 計費的管理

文件服務 存儲文件

非功能性需求

緩存服務：提高性能

監控服務：監控系統及應用的情況

日誌服務：應用日誌收集分析

• 介面設計

介面設計分為：對外介面，內部介面。為了方便多語言的開發，所以對外提供 http 協議介面，不一定完全按照 REST ful 去設計，根據業務確定。每個請求需要確定訪問者的身份，而 http 無狀態，故可以用 JSON Web Token(JWT) 來做認證。

內部調用分為兩種：同步調用，非同步調用。

同步調用可以這幾種方式去做：REST API ，RPC框架，比如 thrift，gRPC 等，或者可以基於 PB 自定義通訊，當然也可以完全用完全自定義的協議，根據公司開發資源靈活選擇。

非同步調用主要是通過消息隊列去做 （RabbitMQ，RocketMQ,kafka,NSQ）等。

• 服務定位（註冊與發現）

既然有這麼多服務，這些服務有會同時存在好多實例，那麼怎麼去定位這些服務也是一個要解決的問題。

這就是服務定位，也就是服務註冊與發現。

為什麼需要定位呢，一是服務位置的變化，另一個就是數量的變化。服務位置可能會變化由於某些原因要遷移到不同的 ip 地址，數量會變化，比如增加一台伺服器，需要對外提供服務，就要告訴網關，如果用固定配置文件方式就會比較麻煩，所以需要動態的去獲取服務的位置。

現在常用的幾個開源服務包括 ZooKeeper、Etcd、Consul 等，服務啟動註冊到註冊表服務，當一個請求到來時，網關去註冊表查詢。服務位置，然後把請求轉發到其中某一個服務，服務與註冊表服務之間會定時檢測，如果一個服務掛了，那麼就會從註冊表刪除，同時通知網關，這樣就可以避免訪問到失敗的服務。而如果有新加入的服務，它會註冊到註冊表，網關也會收到通知，這樣請求就可以轉發到新服務，不需要手工做任何的配置。

• 故障處理

剛才提到服務掛了註冊表會檢測到，但是並不是實時的，所以這個時候的調用就會失敗，那怎麼處理這些調用失敗呢？通過故障處理這節我們有以下這些處理方式。我們可以看到有超時機制、限流、熔斷機制、負載均衡、降級（本地緩存）。在解釋這些處理機制之前我，我們先通過這個圖看一下如果出現故障，不管是服務掛了也好，網路斷了也好，還是訪問量太大處理不過來，會發生什麼情況，會造成服務不可用，沒法處理新的請求。

這種情況的第一個處理方式就是超時機制，就是每個調用都要有個超時時間，防止資源被無限制的佔用，這樣避免影響後面的調用。如果流量太大處理不過來，就可以通過限流來處理，比如用請求隊列大小來限制訪問量，避免訪問量過大造成服務不可用，就像早期的 12306，想必刷過票的都有體會。

斷路器模式：就是先跟蹤成功、失敗調用的次數，當比率達到設定的閾值，打開斷路器，後續的調用就會立即失敗，這時候斷路器會啟動一個定時器，來給伺服器恢復服務，計時器時間到了就會去允許一定數量的請求操作，而不是立即返回失敗，如果全部調用成功就關閉斷路器開始正常服務，否則繼續啟動定時器，進入下一個循環。

負載均衡方式：後面對應多個服務實例，一個服務失敗會自動切換到另一個，這也是一種故障處理方案。某些業務情況直接返回錯誤可能不太友好，所以可以返回緩存的數據，或者返回默認的數據，比如別人發了朋友圈，你刷新的時候還給你返回舊的數據，也不會影響你的體驗，過一會兒再一刷，他就出來了。邏輯架構這部分就結束了，上面所說的這些功能都是需要開發來實現的，所以下面我們看一下開發架構。

2.開發架構

開發架構主要是一些軟體資源以及人員的問題。隨著開源軟體的發展，它們可以減少我們大量的工作，我們有許多服務，這些服務之間需要通訊，所以可以選擇一些通訊框架，比如 netty，libevent 等，這樣可以減少很多工作量，提高效率。還有一些開源應用可以直接使用，如 nginx，redis，mysql，prometheus，grafana 等。

nginx 可以用作反向代理，redis 用於緩存，mysql 作為資料庫，Prometheus，Grafana 用於監控。

源碼版本控制可以直接用 gitlab 社區版，當然也可以用 GitLab 收費版。如果完全開源，那麼也可以直接用 GitLab 的免費服務。

Bug 管理選擇 redmine，當然也可以用 jira，那就需要不少的費用。

人員方面根據團隊擅長的語言，比如 Java，可以做網關，計費系統等，而 AI Server 通常用 C++ 去做，當然有些應用也可以用 Go 語言做，如 prometheus 就是用 Go 寫的。

3.運行架構

主要有一下幾個進程，如圖所示，請求的流程如圖所示。

確定了運行的服務，那麼接下來我們來看看怎麼部署這些服務，也就是服務的部署架構。

4.部署架構

首先看下怎麼部署：

每個主機一個 Service 實例，這些主機可以是真實主機、虛擬機、容器、Docker。部署的時候要考慮災備，可以同一個服務部署多個實例。對於微服務來說，由於服務數量比較多，手工部署比較繁瑣，也容易出錯，所以需要一些自動化的部署工具。比如 puppet,saltstack,chef,ansible，k8s(kubernetes) 是 Docker 的編排工具。CoreOS 提供 docker 的運行環境，精簡版的 Linux，很快的可以部署出一個系統出來，包括一些 Marathon/Mesos。

部署原則

API Gateway 對外提供服務，所以需要高帶寬，AI 服務部署到 GPU 計算資源的主機。文件服務部署存儲空間大的主機，緩存服務需要內存大的主機。所有應用都部署在雲上，方便擴容。

部署架構圖

雷鋒網原創文章，未經授權禁止轉載。詳情見轉載須知。

更多硬創公開課文章，可關注主頁：

http://www.leiphone.com/special/ycopen

微信公眾號：硬創公開課