云知聲研發(fā)平臺總監(jiān)張勁輝：人工智能公司云服務的打造

　　近日，云知聲IoT研發(fā)平臺總監(jiān)張勁輝在Ucloud主辦的中國云計算行業(yè)盛會Think in Cloud上發(fā)表《人工智能公司云服務的打造》的主題演講，他表示，目前云服務已經(jīng)成為一種業(yè)界常態(tài)，如何在高頻次復雜需求的情況下提供高效的AI服務，可以引入“微服務”的解決方案。

　　云知聲是一家借助語音識別為切入點的物聯(lián)網(wǎng)人工智能公司，2012年9月，上線了國內(nèi)第一家免費的語音云平臺UniCloud，并率先將深度學習引入到語音交互產(chǎn)業(yè)領域。目前，云知聲云平臺的日調(diào)用量已經(jīng)超過2億次，覆蓋的城市超過647個，覆蓋設備超過1億臺。

　　微服務架構(gòu)和語音云平臺的結(jié)合

　　張勁輝表示，“一個服務剛開始是很簡單的，后來做著做著就越來越大，可能包羅萬象什么都會有，比如說用戶的登錄注冊，包括通訊、數(shù)據(jù)庫、數(shù)據(jù)庫分表邏輯的耦合，都會在這里面，這說明什么?并且經(jīng)常是一旦產(chǎn)品上有一個需求變化的時候，技術團隊需要從頭改到尾。包括在安全上的一些考慮，例如這個接口有沒有加校驗簽名，是否都需要從頭改到尾。在這種情況下，微服務設計的引入是非常重要的。”

　　微服務的優(yōu)勢是什么?

　　第一，可以提供端到端的解耦，以及并行的開發(fā)、持續(xù)的集成和發(fā)布。第二，合理的顆粒度切分，一定可以提高應用系統(tǒng)的復用性，以及平臺服務的高可靠。第三，我們可以讓研發(fā)團隊技術路線更為豐富，以及團隊管理成本更為降低。各應用體系對外有明確的邊界和接口，用什么語言和技術手段的重要性和必要性就會降低，所以就不會出現(xiàn)一個公司的技術體系是依賴于一兩個技術大俠來支撐的風險。

　　最后的一個核心問題，是如何提供給業(yè)務層面，快速的低成本的試錯能力，以及業(yè)務變化的適應性能力。任何一家公司商業(yè)模式包括產(chǎn)品路線，都是經(jīng)過不斷的嘗試，所以如何以一種方式有效的幫助產(chǎn)品去快速試錯和驗證，或是減少它明顯的錯誤，以及降低它的試錯成本，本身就是技術團隊應該解決的問題。

　　所以光懂寫代碼的研發(fā)不是一個合格的研發(fā)，研發(fā)必須得懂業(yè)務，必須得對業(yè)務進行抽象和理解。

　　古希臘有一位哲學家對這類問題有著更加深層的認知。“一堆建材不能叫做房子,如同一群暴民不能叫做軍隊一樣”。希臘不僅有著光輝的歷史和哲學，以及我們熟知的經(jīng)濟危機，還可能是“微服務認知的最早起源”

　　微服務的弊端

　　有利就必有弊，當把很多的服務從大往小的敲碎的時候，我們會面臨什么?第一，會面臨運維成本的增大。更多的服務也就意味著更多的運維資源的投入;第二分布式系統(tǒng)的復雜性，意味著開發(fā)者需要考慮網(wǎng)絡延遲、容錯、消息序列、不可靠的網(wǎng)絡、異步交互、版本控制、負載等;第三，開發(fā)人員經(jīng)常犯的毛病，從架構(gòu)的角度來說，要防止超前設計和過度抽象的問題。

　　微服務在云知聲云平臺UniCloud中的應用

　　“我今天主要從兩個應用角度來闡述一下微服務在云知聲云平臺UniCloud中的實際案例，第一個是用戶體系的統(tǒng)一認證，第二個是使用場景下的雙向?qū)崟r通訊。”張勁輝稱。

　　用戶有多種登錄鑒權的方式，包括和不限于用戶名+密碼、手機號+驗證碼、聲紋、指紋、人臉識別，以及第三方Oauth方式等。并通過生成token和其生命周期的管理，保證在使用上的安全性，以及與應用服務邏輯的解耦，提供統(tǒng)一的用戶安全策略(密碼更改)和登錄策略(多登錄狀態(tài))的支持。

　　第一步，登錄鑒權，不同方式對應不同的登錄接口即可。第二步，生成并返回一個token。應用服務在使用ID化的時候，我們可以把他的業(yè)務模型抽向成某個ID要做什么?當使用該邏輯時就把token傳過去，應用服務為了要識別這個token只能來驗證token。這樣的一套服務體系，我既可以掌控應用的用戶權限，也可以不打擾它的應用邏輯的業(yè)務，實現(xiàn)高內(nèi)聚、低耦合，以及用戶級別的安全的策略。

　　再舉一個例子，消息服務提供統(tǒng)一的雙向?qū)崟r通訊支持，支持手機客戶端和各種可穿戴設備場景的通訊需求;實現(xiàn)三種業(yè)務抽象，就是端到平臺(上行信息)，平臺到端(下行信息)，以及端到端。

　　用戶接入的時候來獲取他使用的協(xié)議連接點，然后接入到集群和消息服務，使用定義的Massage去通信。消息服務針對應用服務抽象了幾種事件和標準接口。

　　第一，用戶連接了(上線)。第二，用戶離線了(下線)。第三，收到消息。第四，發(fā)送消息。

　　整個一個架構(gòu)是能夠支撐以任何一種協(xié)議都能夠接入的，不管你是用的TCP還是UDP，以及這個星球能夠任何的一種通信協(xié)議，只要有我就可以快速的接入和使用。應用服務只需要做好自己的邏輯，不用理解前面連接狀態(tài)，就可以實現(xiàn)雙向的通信，并且可以靈活的支持各種加密，保證產(chǎn)品的安全性。