雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
背景
最近研究的同僚對識别核心做了一些優化，将原先內建在casrserver的核心計算邏輯單獨抽離出來做成了服務并且測試後性能有提升，需要casrserver服務配合做一些改造，我之前也有過類似的想法，這次正好識别工程團隊沒有人力支援，加上我之前維護過casrserver, 于是就去協助casrserver改造了。在修改之前先介紹一下目前的架構
目前架構
如上圖，目前casrserver中既處理了網絡連接配接，又完成了識别的計算任務，圖中是一次語音請求的核心互動邏輯, 一條用戶端連接配接過來，網絡程序裡會對應三個協程:
- recv協程負責接收用戶端發上來的資料
- rpc協程負責将recv的資料發送給計算程序，然後接收計算程序傳回的識别結果
- send協程将識别結果再回給用戶端
為了做到異步三個協程之間用了兩個隊列進行通信, 關于這套架構更詳細的介紹，見順哥在2016年openresty大會做的 ppt分享。之前的架構介紹到這裡，讓我們再來看看新版修改後的架構。
改動後的架構
如圖，原先在openresty中worker程序fork出來的計算程序已經抽離出來成為獨立的服務，casrserver和asr kernel server通過cosocket進行通信。
實作
針對上述架構，在新的casrserver中主要做了如下修改:
消息格式
asr-kernel-server服務的同僚定義了一套新的消息格式, casrserver對應的實作如下:
- 針對這個消息格式，casrserver裡封裝了protocol.lua, 用于tcp底層的資料包封裝。
- 針對上層的業務資料，由 asr_kernel_helper.lua 中的pack和unpack完成業務資料的打包, 使用protobuf對資料進行序列化。
處理邏輯
- 用戶端websocket連接配接進來的時候，同步建一條到asr-kernel-server的連接配接
- 在主協程中新起了兩個協程分别做接收和發送邏輯，接收和發送可以全雙工進行，不再需要發送完後一幀資料後等計算程序傳回了才能發送下一幀資料，具體實作在asr_kernel.lua中的kernel.send和kernel.recv。
其他
由于移除了計算程序，是以對原有的代碼進行了删減，主要有這些：
- 移除了服務啟動前資源的同步、預熱邏輯
- 移除了原先的rpc協程
- 移除了計算程序池的管理
- 移除了與計算程序的luasocket通信
優勢
我認為将識别計算部分分離出來有如下好處
1.職責更加單一化，使基于openresty的casrserver可以更加專注于自身的業務邏輯，團隊分工更加明确，識别核心的更新，不再需要casrserver出版本。
2.計算服務分離後，不再需要程序池管理，worker中也不用進行fork，可以充分發揮多worker的優勢，使casrserver可以更加專注地處理網絡io。
3.解決了casrserver和計算核心的綁定，單個casrserver支援更多的client連接配接，可以更好地進行分布式部署
4.原先nginx worker和計算核心通信使用的是阻塞式的luasocket，可以改造為cosocket進行通信
5.困擾casrserver很久的計算核心相關的監控和日志問題，可以更好的解決掉。
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/live立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-06-11
本文作者：gerrard
本文來自：“
掘金”，了解相關資訊可以關注“掘金”