<mark id="oztn4"></mark>
0
| 本文作者： 老王 | 2017-02-13 12:23 | 專題：雷峰網(wǎng)公開課 |
雷鋒網(wǎng)按：技術(shù)圈流傳這樣一句話“人工智能背后的架構(gòu)和工程問題是武當(dāng)少林，屬于內(nèi)功。而算法則是招式，講究一時(shí)之快。”
再強(qiáng)的算法均需強(qiáng)大的架構(gòu)和工程作支撐，兩者缺一不可。
那么 AI 公司該如何設(shè)計(jì)承載產(chǎn)品背后龐大復(fù)雜的算法、工程核心架構(gòu)？本期雷鋒網(wǎng) AI 科技評論特邀極限元 CTO 康利強(qiáng)為大家講述《AI 公司該如何設(shè)計(jì)基于微服務(wù)的 AI SaaS 架構(gòu)》。
康利強(qiáng)，極限元 CTO，親自主導(dǎo)搭建了支撐極限元現(xiàn)有語音識別、計(jì)算機(jī)視覺、人機(jī)交互解決方案的構(gòu)架；20 年軟件研發(fā)、架構(gòu)設(shè)計(jì)以及項(xiàng)目管理經(jīng)驗(yàn)，前億贊普集團(tuán)核心架構(gòu)設(shè)計(jì)專家；美國 Borland 軟件公司中國機(jī)構(gòu)分布式存儲架構(gòu)師及項(xiàng)目負(fù)責(zé)人。
本期公開課視頻（共 44 分鐘）
如想獲取本期公開課的 PPT 資源，關(guān)注雷鋒網(wǎng)人工智能垂直微信公眾號“ AI 科技評論”，在后臺回復(fù)關(guān)鍵詞“架構(gòu)”，即可收到本期公開課 32 頁的 PPT 下載鏈接。
以下為分享正文：
今天我給大家分享的內(nèi)容是，基于微服務(wù)的 AI Saas 架構(gòu)設(shè)計(jì)。
既然要設(shè)計(jì) SaaS 架構(gòu)，先要了解何為 Saas？SaaS 是云計(jì)算的一種服務(wù)形式，關(guān)于云計(jì)算，我先簡要做個(gè)介紹：
什么是云計(jì)算？
云計(jì)算的分類（分層）
云計(jì)算新的服務(wù)方式
云計(jì)算是一種計(jì)算資源，按量付費(fèi)，也就是你用多少就支付多少費(fèi)用，可以便捷的訪問，通過網(wǎng)絡(luò)進(jìn)入可配置的資源池，（資源包括網(wǎng)絡(luò)，服務(wù)器，存儲，應(yīng)用軟件，服務(wù)），這些資源能夠被快速提供，我們只需投入很少的管理工作，或與服務(wù)供應(yīng)商進(jìn)行很少的交互。
2006 年 8 月 ，Google 提出云計(jì)算的概念，到今天經(jīng)過了 10 年的發(fā)展，云計(jì)算越來越為大家所接受，很多人也在使用云計(jì)算提供的服務(wù)，比如云主機(jī)、云存儲、網(wǎng)盤、云分發(fā)、云筆記等等；今天的直播也會(huì)用到其中的幾項(xiàng)服務(wù)，比如云存儲、云分發(fā)，由于用到云分發(fā)，所以大家在看直播的時(shí)候會(huì)有一個(gè)比較低的延時(shí)。
接下來介紹 SaaS，除了SaaS 外，云計(jì)算也包含其他幾種類型：
主要有以下幾種類型：
IaaS(Infrastructure-as-a- Service)：基礎(chǔ)設(shè)施即服務(wù)。消費(fèi)者通過 Internet 可以從完善的計(jì)算機(jī)基礎(chǔ)設(shè)施獲得服務(wù)。也就是云主機(jī)，比如亞馬遜云，微軟云，阿里云等。
PaaS(Platform-as-a-Service)：平臺即服務(wù)。PaaS 實(shí)際上是指將軟件研發(fā)的平臺作為一種服務(wù)，以 SaaS 的模式提交給用戶。因此，PaaS 也是 SaaS 模式的一種應(yīng)用。PaaS 的出現(xiàn)可以加快 SaaS 的發(fā)展，尤其是加快 SaaS 應(yīng)用的開發(fā)速度。需要用戶有一定的開發(fā)能力，比如谷歌的 GAE。
SaaS(Software-as-a-Service)：軟件即服務(wù)。它是一種通過 Internet 提供軟件的模式，用戶無需購買軟件。例如：各種云存儲，網(wǎng)盤、云筆記。
近些年隨著 Docker 的發(fā)展，出現(xiàn)了一種新的服務(wù)形式：CaaS。
CaaS (Containers-as-a-Service): 容器即服務(wù)這是隨著近幾年docker的火熱而出現(xiàn)的一種新的服務(wù)形式，使應(yīng)用的打包與部署自動(dòng)化，創(chuàng)建輕量、私有的 PAAS 環(huán)境，使持續(xù)集成/部署、測試自動(dòng)化，部署可伸縮的 web app、數(shù)據(jù)庫和后臺服務(wù)。
因?yàn)?docker 基于 Linux Container（Namespace，cgroup,chroot等），抽象出 Libcontainer 的接口，docker 運(yùn)行于 Libcontainer 接口之上而不關(guān)心底層實(shí)現(xiàn)，所以這種服務(wù)就叫做 CaaS。
這是一個(gè)簡化版的云計(jì)算分類，通過這個(gè)圖可以一目了然看到它們之間的關(guān)系。
既然講架構(gòu)設(shè)計(jì)，所以要了解一下架構(gòu)模式，題目是基于微服務(wù)的架構(gòu)設(shè)計(jì)有微服務(wù)，那么是不是有宏大的服務(wù)呢，答案是肯定的。
一般來說，有以下兩種架構(gòu)模式：
單體式架構(gòu)（Monolithic Architecture）
微服務(wù)架構(gòu)（Microservices Architecture）
下面我們來看一下單體式架構(gòu)：
單體式架構(gòu)就是所有功能打包運(yùn)行在一個(gè)進(jìn)程，比如一個(gè)war包，從這個(gè)架構(gòu)圖我們也可以看到，這是一個(gè)叫車應(yīng)用，中間部分是一個(gè)整體，包含很多功能，有乘客管理，通知，支付，司機(jī)管理 ，路線規(guī)劃等功能。
優(yōu)點(diǎn)是開發(fā)，部署，測試，水平擴(kuò)展比較容易，可以放到一個(gè)工程，打一個(gè)包，擴(kuò)展的時(shí)候只把這一個(gè)包復(fù)制到新的位置即可。缺點(diǎn)就是隨著功能增多，代碼變多， 維護(hù)成本高，交付周期長。
與此同時(shí)，不同模塊發(fā)生資源沖突時(shí)，擴(kuò)展將會(huì)非常困難。造成資源的浪費(fèi)，有的要大內(nèi)存，有的高帶寬，有的要大的存儲空間等。為了同時(shí)滿足這些條件，這樣就造成了資源的浪費(fèi)。
還有一個(gè)問題是，技術(shù)選項(xiàng)成本高，必須謹(jǐn)慎選擇，因?yàn)橐坏┻x定很難更改，如果要更改的話，肯能要全部推到重來。另外可靠性也存在問題，一個(gè)模塊故障會(huì)影響整個(gè)服務(wù)。
在了解微服務(wù)之前，首先了解什么是微服務(wù)，其次需要了解微服務(wù)架構(gòu)的設(shè)計(jì)要點(diǎn)，最后需知道微服務(wù)的優(yōu)缺點(diǎn)。先看一下什么是微服務(wù)？
微服務(wù)沒有一個(gè)公認(rèn)的確切定義，但是有一些共性，微服務(wù)是是面向服務(wù)架構(gòu)的一種特例，有以下特性：
容易替換（升級）。
服務(wù)輕量級，可獨(dú)立部署，構(gòu)建發(fā)布自動(dòng)化。
與其他服務(wù)通過網(wǎng)絡(luò)協(xié)作完成任務(wù)。
根據(jù)功能來劃分服務(wù)，比如用戶前端，推薦，物流，賬單等。
可以用不同的語言、數(shù)據(jù)庫、軟硬件實(shí)現(xiàn)。
所以微服務(wù)本身天然就具有模塊化特性，適合于持續(xù)交付的開發(fā)部署，業(yè)務(wù)改變只需要重新發(fā)布部署少量的服務(wù)。了解微服務(wù)以后，進(jìn)入今天的主題：為微服務(wù)架構(gòu)設(shè)計(jì)。
我們知道，人工智能的核心是機(jī)器學(xué)習(xí)，因?yàn)闄C(jī)器不會(huì)自己學(xué)習(xí)，所以要明確指明一些特征來讓機(jī)器知道符合這個(gè)條件的是什么，符合那個(gè)條件的是什么，這就需要編寫復(fù)雜的程序來讓機(jī)器來學(xué)習(xí)，在某些場合，隨著需要的特征約來越多，編寫程序越來越困難，我們無法用足夠?qū)嵱貌⑶铱煽康姆绞矫鞔_指定所要優(yōu)化的特征。
以讓機(jī)器識別一只貓為例，假設(shè)這只貓是白色的，先不考慮其他特征，只說顏色特征。其它特征+白色這兩個(gè)特征讓計(jì)算機(jī)知道這是一只貓，那么來一只黑色貓就不認(rèn)識了，或者來一只加菲貓計(jì)算機(jī)就有可能就會(huì)把它識別成色情圖片了。
這就導(dǎo)致所需的特征越來越多，這時(shí)候發(fā)現(xiàn)程序沒法寫了。于是深度學(xué)習(xí)順勢而生，大量數(shù)據(jù)通過深度神經(jīng)網(wǎng)絡(luò)的訓(xùn)練，讓計(jì)算機(jī)學(xué)習(xí)，機(jī)器會(huì)自己提取特征并跟測試集來比較，然后自己調(diào)整進(jìn)行下一輪的訓(xùn)練，直到訓(xùn)練出合適的結(jié)果。所以說目前的 AI 更多是數(shù)據(jù)的比拼。
首先我們要了解 AI 能做什么，AI 可以做一些色情檢測、廣告檢測、涉爆涉恐言論以及電信詐騙檢測，這些都是 AI 可以做的事情。用 AI 來做的話可以節(jié)省大量的人力，但是，不是所有公司都有能量構(gòu)建 AI 系統(tǒng)，從上圖中可以看出，構(gòu)建 AI 系統(tǒng)需要大量數(shù)據(jù)，需要大量計(jì)算資源，需要專業(yè)技術(shù)人員。
所以隨著社會(huì)分工越來越細(xì)，專注于自己的業(yè)務(wù)，專業(yè)的事情交給專業(yè)的公司來做就好，避免自己精力過于分散。以直播平臺為例，其需要檢測上面所述的一些違規(guī)內(nèi)容，也可以用 AI 來檢測。但是不一定要自己做 AI 系統(tǒng)，你可以把更多的精力放在直播的流暢度、延時(shí)、互動(dòng)性等提升上。
由于 AI SaaS 需要提供多種服務(wù)，不同的服務(wù)需要不同的計(jì)算資源，AI 算法需要 GPU 資源，所以微服務(wù)的架構(gòu)更適合 AI SaaS。
傳統(tǒng)的架構(gòu)設(shè)計(jì)一般從這 5 個(gè)方面來設(shè)計(jì)，所謂的五視圖：邏輯架構(gòu)，開發(fā)架構(gòu)，運(yùn)行架構(gòu)，部署架構(gòu)，數(shù)據(jù)架構(gòu)。
邏輯架構(gòu)主要是考慮需求，并根據(jù)職責(zé)劃分邏輯層，子系統(tǒng)、子模塊兒，同時(shí)考慮模塊兒的接口。
開發(fā)架構(gòu)：源文件管理，工程組織方式，依賴的庫、框架，以及構(gòu)建系統(tǒng)。
運(yùn)行架構(gòu)：子系統(tǒng)需要幾個(gè)進(jìn)程，進(jìn)程之間怎么通信，以及怎么啟停。
部署架構(gòu)：系統(tǒng)的物理架構(gòu)，需要那些服務(wù)器，服務(wù)器之間的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，以及系統(tǒng)運(yùn)行到那些服務(wù)器上。同時(shí)還需要考慮冗余，因?yàn)橄到y(tǒng)出問題是必然的。
邏輯架構(gòu)是根據(jù)需求劃分的幾個(gè)邏輯層，主要分為接入層，業(yè)務(wù)層，存儲層，管理層，這幾層分別有不同的服務(wù)。
整體架構(gòu)
上面講到邏輯架構(gòu)要根據(jù)需求劃分子系統(tǒng)，子模塊，以及定義模塊的接口。對應(yīng)的微服務(wù)架構(gòu)的話就是怎么根據(jù)需求分解成微服務(wù)，以及怎么定義服務(wù)間的通訊接口。與單體應(yīng)用不同的是還需要確定服務(wù)的位置，所以需要服務(wù)定位。此外，由于微服務(wù)通過網(wǎng)絡(luò)來訪問，所以需要有對應(yīng)的故障處理機(jī)制。
服務(wù)的劃分
所以下面就從服務(wù)的劃分，接口設(shè)計(jì)，服務(wù)定位（注冊與發(fā)現(xiàn)），故障處理來講解一下邏輯架構(gòu)。
第一，服務(wù)的劃分，服務(wù)劃分的原則跟面向?qū)ο笤O(shè)計(jì)原則基本一致，單一職責(zé)，高內(nèi)聚，低耦合。我們知道對于需求來說分為功能性需求跟非功能性需求，那么微服務(wù)也按這種方式來劃分。
首先來看功能性需求：
API Server api 的接入，認(rèn)證，負(fù)載均衡。
Service Registry服務(wù)注冊與發(fā)現(xiàn)。
AI 網(wǎng)關(guān)：AI 服務(wù)的流量控制與負(fù)載均衡。
AI 服務(wù)：提供 AI 服務(wù)，比如圖像識別，語音識別等。
計(jì)費(fèi)服務(wù) 計(jì)費(fèi)的管理
文件服務(wù) 存儲文件
非功能性需求
緩存服務(wù)：提高性能
監(jiān)控服務(wù)：監(jiān)控系統(tǒng)及應(yīng)用的情況
日志服務(wù)：應(yīng)用日志收集分析
接口設(shè)計(jì)
接口設(shè)計(jì)分為：對外接口，內(nèi)部接口。為了方便多語言的開發(fā)，所以對外提供 http 協(xié)議接口，不一定完全按照 REST ful 去設(shè)計(jì)，根據(jù)業(yè)務(wù)確定。每個(gè)請求需要確定訪問者的身份，而 http 無狀態(tài)，故可以用 JSON Web Token(JWT) 來做認(rèn)證。
內(nèi)部調(diào)用分為兩種：同步調(diào)用，異步調(diào)用。
同步調(diào)用可以這幾種方式去做：REST API ，RPC框架，比如 thrift，gRPC 等，或者可以基于 PB 自定義通訊，當(dāng)然也可以完全用完全自定義的協(xié)議，根據(jù)公司開發(fā)資源靈活選擇。
異步調(diào)用主要是通過消息隊(duì)列去做 （RabbitMQ，RocketMQ,kafka,NSQ）等。
服務(wù)定位（注冊與發(fā)現(xiàn)）
既然有這么多服務(wù)，這些服務(wù)有會(huì)同時(shí)存在好多實(shí)例，那么怎么去定位這些服務(wù)也是一個(gè)要解決的問題。
這就是服務(wù)定位，也就是服務(wù)注冊與發(fā)現(xiàn)。
為什么需要定位呢，一是服務(wù)位置的變化，另一個(gè)就是數(shù)量的變化。服務(wù)位置可能會(huì)變化由于某些原因要遷移到不同的 ip 地址，數(shù)量會(huì)變化，比如增加一臺服務(wù)器，需要對外提供服務(wù)，就要告訴網(wǎng)關(guān)，如果用固定配置文件方式就會(huì)比較麻煩，所以需要?jiǎng)討B(tài)的去獲取服務(wù)的位置。
現(xiàn)在常用的幾個(gè)開源服務(wù)包括 ZooKeeper、Etcd、Consul 等，服務(wù)啟動(dòng)注冊到注冊表服務(wù)，當(dāng)一個(gè)請求到來時(shí)，網(wǎng)關(guān)去注冊表查詢。服務(wù)位置，然后把請求轉(zhuǎn)發(fā)到其中某一個(gè)服務(wù)，服務(wù)與注冊表服務(wù)之間會(huì)定時(shí)檢測，如果一個(gè)服務(wù)掛了，那么就會(huì)從注冊表刪除，同時(shí)通知網(wǎng)關(guān)，這樣就可以避免訪問到失敗的服務(wù)。而如果有新加入的服務(wù)，它會(huì)注冊到注冊表，網(wǎng)關(guān)也會(huì)收到通知，這樣請求就可以轉(zhuǎn)發(fā)到新服務(wù)，不需要手工做任何的配置。
故障處理
剛才提到服務(wù)掛了注冊表會(huì)檢測到，但是并不是實(shí)時(shí)的，所以這個(gè)時(shí)候的調(diào)用就會(huì)失敗，那怎么處理這些調(diào)用失敗呢？通過故障處理這節(jié)我們有以下這些處理方式。我們可以看到有超時(shí)機(jī)制、限流、熔斷機(jī)制、負(fù)載均衡、降級（本地緩存）。在解釋這些處理機(jī)制之前我，我們先通過這個(gè)圖看一下如果出現(xiàn)故障，不管是服務(wù)掛了也好，網(wǎng)絡(luò)斷了也好，還是訪問量太大處理不過來，會(huì)發(fā)生什么情況，會(huì)造成服務(wù)不可用，沒法處理新的請求。
這種情況的第一個(gè)處理方式就是超時(shí)機(jī)制，就是每個(gè)調(diào)用都要有個(gè)超時(shí)時(shí)間，防止資源被無限制的占用，這樣避免影響后面的調(diào)用。如果流量太大處理不過來，就可以通過限流來處理，比如用請求隊(duì)列大小來限制訪問量，避免訪問量過大造成服務(wù)不可用，就像早期的 12306，想必刷過票的都有體會(huì)。
斷路器模式：就是先跟蹤成功、失敗調(diào)用的次數(shù)，當(dāng)比率達(dá)到設(shè)定的閾值，打開斷路器，后續(xù)的調(diào)用就會(huì)立即失敗，這時(shí)候斷路器會(huì)啟動(dòng)一個(gè)定時(shí)器，來給服務(wù)器恢復(fù)服務(wù)，計(jì)時(shí)器時(shí)間到了就會(huì)去允許一定數(shù)量的請求操作，而不是立即返回失敗，如果全部調(diào)用成功就關(guān)閉斷路器開始正常服務(wù)，否則繼續(xù)啟動(dòng)定時(shí)器，進(jìn)入下一個(gè)循環(huán)。
負(fù)載均衡方式：后面對應(yīng)多個(gè)服務(wù)實(shí)例，一個(gè)服務(wù)失敗會(huì)自動(dòng)切換到另一個(gè)，這也是一種故障處理方案。某些業(yè)務(wù)情況直接返回錯(cuò)誤可能不太友好，所以可以返回緩存的數(shù)據(jù)，或者返回默認(rèn)的數(shù)據(jù)，比如別人發(fā)了朋友圈，你刷新的時(shí)候還給你返回舊的數(shù)據(jù)，也不會(huì)影響你的體驗(yàn)，過一會(huì)兒再一刷，他就出來了。邏輯架構(gòu)這部分就結(jié)束了，上面所說的這些功能都是需要開發(fā)來實(shí)現(xiàn)的，所以下面我們看一下開發(fā)架構(gòu)。
開發(fā)架構(gòu)主要是一些軟件資源以及人員的問題。隨著開源軟件的發(fā)展，它們可以減少我們大量的工作，我們有許多服務(wù)，這些服務(wù)之間需要通訊，所以可以選擇一些通訊框架，比如 netty，libevent 等，這樣可以減少很多工作量，提高效率。還有一些開源應(yīng)用可以直接使用，如 nginx，redis，mysql，prometheus，grafana 等。
nginx 可以用作反向代理，redis 用于緩存，mysql 作為數(shù)據(jù)庫，Prometheus，Grafana 用于監(jiān)控。
源碼版本控制可以直接用 gitlab 社區(qū)版，當(dāng)然也可以用 GitLab 收費(fèi)版。如果完全開源，那么也可以直接用 GitLab 的免費(fèi)服務(wù)。
Bug 管理選擇 redmine，當(dāng)然也可以用 jira，那就需要不少的費(fèi)用。
人員方面根據(jù)團(tuán)隊(duì)擅長的語言，比如 Java，可以做網(wǎng)關(guān)，計(jì)費(fèi)系統(tǒng)等，而 AI Server 通常用 C++ 去做，當(dāng)然有些應(yīng)用也可以用 Go 語言做，如 prometheus 就是用 Go 寫的。
主要有一下幾個(gè)進(jìn)程，如圖所示，請求的流程如圖所示。
確定了運(yùn)行的服務(wù)，那么接下來我們來看看怎么部署這些服務(wù)，也就是服務(wù)的部署架構(gòu)。
首先看下怎么部署：
每個(gè)主機(jī)一個(gè) Service 實(shí)例，這些主機(jī)可以是真實(shí)主機(jī)、虛擬機(jī)、容器、Docker。部署的時(shí)候要考慮災(zāi)備，可以同一個(gè)服務(wù)部署多個(gè)實(shí)例。對于微服務(wù)來說，由于服務(wù)數(shù)量比較多，手工部署比較繁瑣，也容易出錯(cuò)，所以需要一些自動(dòng)化的部署工具。比如 puppet,saltstack,chef,ansible，k8s(kubernetes) 是 Docker 的編排工具。CoreOS 提供 docker 的運(yùn)行環(huán)境，精簡版的 Linux，很快的可以部署出一個(gè)系統(tǒng)出來，包括一些 Marathon/Mesos。
部署原則
API Gateway 對外提供服務(wù)，所以需要高帶寬，AI 服務(wù)部署到 GPU 計(jì)算資源的主機(jī)。文件服務(wù)部署存儲空間大的主機(jī)，緩存服務(wù)需要內(nèi)存大的主機(jī)。所有應(yīng)用都部署在云上，方便擴(kuò)容。
部署架構(gòu)圖
雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
專題
