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

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

　　微服務架構和語音云平臺的結合

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

　　微服務的優勢是什么?

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

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

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

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

　　微服務的弊端

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

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

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

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

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

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

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

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

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