0
雷鋒網按：技術圈流傳這樣一句話“人工智能背后的架構和工程問題是武當少林，屬于內功。而算法則是招式，講究一時之快?！?br/>
再強的算法均需強大的架構和工程作支撐，兩者缺一不可。
那么 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 更多是數據的比拼。
首先我們要了解 AI 能做什么，AI 可以做一些色情檢測、廣告檢測、涉爆涉恐言論以及電信詐騙檢測，這些都是 AI 可以做的事情。用 AI 來做的話可以節省大量的人力，但是，不是所有公司都有能量構建 AI 系統，從上圖中可以看出，構建 AI 系統需要大量數據，需要大量計算資源，需要專業技術人員。
所以隨著社會分工越來越細，專注于自己的業務，專業的事情交給專業的公司來做就好，避免自己精力過于分散。以直播平臺為例，其需要檢測上面所述的一些違規內容，也可以用 AI 來檢測。但是不一定要自己做 AI 系統，你可以把更多的精力放在直播的流暢度、延時、互動性等提升上。
由于 AI SaaS 需要提供多種服務，不同的服務需要不同的計算資源，AI 算法需要 GPU 資源，所以微服務的架構更適合 AI SaaS。
傳統的架構設計一般從這 5 個方面來設計，所謂的五視圖：邏輯架構，開發架構，運行架構，部署架構，數據架構。
邏輯架構主要是考慮需求，并根據職責劃分邏輯層，子系統、子模塊兒，同時考慮模塊兒的接口。
開發架構：源文件管理，工程組織方式，依賴的庫、框架，以及構建系統。
運行架構：子系統需要幾個進程，進程之間怎么通信，以及怎么啟停。
部署架構：系統的物理架構，需要那些服務器，服務器之間的網絡拓撲結構，以及系統運行到那些服務器上。同時還需要考慮冗余，因為系統出問題是必然的。
邏輯架構是根據需求劃分的幾個邏輯層，主要分為接入層，業務層，存儲層，管理層，這幾層分別有不同的服務。
整體架構
上面講到邏輯架構要根據需求劃分子系統，子模塊，以及定義模塊的接口。對應的微服務架構的話就是怎么根據需求分解成微服務，以及怎么定義服務間的通訊接口。與單體應用不同的是還需要確定服務的位置，所以需要服務定位。此外，由于微服務通過網絡來訪問，所以需要有對應的故障處理機制。
服務的劃分
所以下面就從服務的劃分，接口設計，服務定位（注冊與發現），故障處理來講解一下邏輯架構。
第一，服務的劃分，服務劃分的原則跟面向對象設計原則基本一致，單一職責，高內聚，低耦合。我們知道對于需求來說分為功能性需求跟非功能性需求，那么微服務也按這種方式來劃分。
首先來看功能性需求：
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，想必刷過票的都有體會。
斷路器模式：就是先跟蹤成功、失敗調用的次數，當比率達到設定的閾值，打開斷路器，后續的調用就會立即失敗，這時候斷路器會啟動一個定時器，來給服務器恢復服務，計時器時間到了就會去允許一定數量的請求操作，而不是立即返回失敗，如果全部調用成功就關閉斷路器開始正常服務，否則繼續啟動定時器，進入下一個循環。
負載均衡方式：后面對應多個服務實例，一個服務失敗會自動切換到另一個，這也是一種故障處理方案。某些業務情況直接返回錯誤可能不太友好，所以可以返回緩存的數據，或者返回默認的數據，比如別人發了朋友圈，你刷新的時候還給你返回舊的數據，也不會影響你的體驗，過一會兒再一刷，他就出來了。邏輯架構這部分就結束了，上面所說的這些功能都是需要開發來實現的，所以下面我們看一下開發架構。
開發架構主要是一些軟件資源以及人員的問題。隨著開源軟件的發展，它們可以減少我們大量的工作，我們有許多服務，這些服務之間需要通訊，所以可以選擇一些通訊框架，比如 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 寫的。
主要有一下幾個進程，如圖所示，請求的流程如圖所示。
確定了運行的服務，那么接下來我們來看看怎么部署這些服務，也就是服務的部署架構。
首先看下怎么部署：
每個主機一個 Service 實例，這些主機可以是真實主機、虛擬機、容器、Docker。部署的時候要考慮災備，可以同一個服務部署多個實例。對于微服務來說，由于服務數量比較多，手工部署比較繁瑣，也容易出錯，所以需要一些自動化的部署工具。比如 puppet,saltstack,chef,ansible，k8s(kubernetes) 是 Docker 的編排工具。CoreOS 提供 docker 的運行環境，精簡版的 Linux，很快的可以部署出一個系統出來，包括一些 Marathon/Mesos。
部署原則
API Gateway 對外提供服務，所以需要高帶寬，AI 服務部署到 GPU 計算資源的主機。文件服務部署存儲空間大的主機，緩存服務需要內存大的主機。所有應用都部署在云上，方便擴容。
部署架構圖
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
專題
