作者：苗廣藝
編輯：王雪燕 高陽
作者經歷了學霸君在線答疑業務從設計、研發、上線、迭代、步步優化，直到穩定的整個過程。
從一個技術負責人的角度來對這項業務的技術發展做一個全面的回顧。
2013年左右，深度學習技術在國內開始熱起來，我也參與其中，將深度技術應用於人臉識別算法當中。接觸了學霸君之後我發現，在教育行業，深度學習技術大有可為，因此我決定加入他們，並很快將深度學習技術應用到拍照搜題這個領域。
學霸君是一家教育行業的創業公司，主要面向的用戶是中學生和小學生。學霸君APP最初的主要功能就是拍照搜題，學生可以拿起手機對著題拍照，框選出題目範圍，進行搜索。搜索結果不僅有ABCD答案，還包含豐富全面解析，如題幹、題目簡析、推導過程、點評、題目考點相關介紹等。這個功能上線後，受到學生們的歡迎，因為學霸群APP的搜題準確度較高，APP的用戶量增長非常快。
學霸君在只有拍照搜題這一個業務的時候，後端技術主要是題庫的建設、搜索、OCR識別（文字識別技術），產品注重體驗及App的開發。實時在線答疑業務等功能的出現，促使學霸君的技術快速發展，特別是後端技術。
在線答疑業務的流程是怎樣的？
老師和學生各有一個客戶端軟件，老師端需在PC端登錄，學生手機端登錄。
學生對難題進行拍照
點擊呼叫老師的按鈕
之後這道題目就會生成一個訂單
發送給全國各地的老師
系統會對老師進行篩選
推薦合適的老師與學生建立在線通話
由老師給學生講解
如果老師說話不能解釋明白，還可使用我們提供的數碼筆。數碼筆是通過藍牙或者 USB 與 PC 建立一個連接，將老師在紙上寫的內容實時傳輸到學生的手機屏幕上。
針對學生的題目，系統還會給老師推薦題目的答案以及解題過程作為參考，這樣做可以大大節省老師審題的時間。
在線答疑業務的重要特點
特點一，實時對話。通過語音和筆記讓老師和學生進行實時溝通。系統需要做到不卡不斷不延遲，音質儘量好。
特點二，Uber模式。在線答疑係統的邏輯和 Uber 打車相似，老師由我們系統自動分配，老師和學生建立連接之後，我們需要讓老師和學生的連接儘量穩定。
特點三：分配策略。我們希望能夠儘快給學生分配到最合適的老師，分配策略會涉及到用戶畫像等方面。
特點四：識別算法。學生是通過對題目進行拍照進行提問的，系統需要識別出題目的內容、年級、學科等，如果沒有這些識別結果，系統無法做到自動分配老師。
在線答疑業務系統的演變之路
在線答疑業務從備戰→上線→穩定經歷了三個階段：
最初我們開發了一個基於 Web 客戶端的簡單的 Demo 版本，來驗證業務的可行性；
然後正式立項，開始組建團隊、攻關難點技術，完成了 Beta 版本產品正式上線。
上線後，又對系統進行了大量的優化，使得產品達到了很好的效果和體驗。
我是在第一個階段的中後期加入到這個項目的，不久後被任命為技術負責人。
Demo 版
是最小可用的簡單版系統，一方面用來評估產品是否能立項，一方面實驗一些技術。
這個版本的老師端是瀏覽器，通過插件驅動數碼筆，音頻數據都沒有壓縮，音頻傳輸服務器用 Node.js 做的，業務後臺也非常簡單。
因為做的簡單，可用性比較差，如果學生網絡條件不好，訂單的成功率不到 70%。這樣的情況完全無法直接上線使用。
Beta 版
是在線答疑業務系統正式上線的版本，包含幾個核心業務模塊。
音頻服務用來音頻和筆跡的傳輸，客戶端需要集成一個音頻引擎的 SDK；
答疑中控負責整個答疑流程的核心邏輯，包括維持長連接和各種狀態切換；
識別集群是做一些圖像、學科識別的算法等。
當時的狀況是，公司在音頻實時傳輸方面完全沒有任何技術基礎，在圖像識別方面有一些技術積累。
實時音頻傳輸技術有較大的技術難度：兩個用戶進行在線語音對話，整個對話流程會經過很多很複雜的技術環節，包括採集、預處理、壓縮、打包、發送、傳輸、接收、緩衝、解碼、後處理和播放等，這些環節會互相影響。
因此整個流程也會有很多不確定的因素，在真實場景中，還會遇到各種困難，如各種網絡環境和複雜的適配。
“
我們面臨的第一個問題就是技術選型問題，這個決定了後面產品的效果以及開發的難度。
”
在協議選擇上，如果直接選擇 RTMP 和 HLS，相對開發簡單一些 ，但這些協議是基於 UDP 協議的封裝，在實際應用場景中往往會經過多次 CDN 轉發，至少有兩秒鐘的延遲，如網絡不好還會有更多的延遲或者累積延遲。在線答疑業務的場景是老師和學生實時的對話，對延遲問題需求較高。
PTP 協議雖然是專門為音視頻傳輸而生，但比較老舊，不能完全滿足我們的需求，如果使用的話需要在它的基礎上再封裝一些協議。
最後我們選擇了自有協議，在 UDP 協議上進行封裝。雖然在開發上有難度，但是其延遲可以做到特別低，靈活度比較高，可以自控。
除了音頻傳輸，我們的業務場景還需要傳輸筆記，可以考慮直接用視頻傳輸音頻和筆記，這樣做雖然很靈活，但對網絡和設備要求比較高，所以最終沒有考慮。
我們將筆記的原始數據壓縮後直接傳輸到對方終端，然後實時畫出來，這樣筆記傳輸的數據就會非常小，可做到延遲特別低。
另外，我們也可以直接用第三方技術，有的公司有相對成熟的 SDK 可以直接集成到我們產品中，但這樣做會增加很多溝通成本，產品升級的速度會變慢，不掌握核心技術，無法完全根據我們的業務場景定製。長遠考慮，最終我們選擇自己研發一套我們自己的音頻傳輸技術。
自研技術有很大挑戰，因為上線時間緊迫，我們當時制定原則就是先儘量簡單，快速做起來，做成一個可用的系統，然後再不斷升級優化。
我們用 ZK 集群管理所有服務器，其中音頻服務器用於傳輸數據，每一個師生連接都會生成一個 room，老師和學生進入同一個 room 內進行通話；
調度服務器用於管理音頻服務器資源以及 room 資源；
老師和學生客戶端都需要集成一個 SDK，SDK 上包含了採集數據、編解碼、緩衝、網絡傳輸等模塊，把所有邏輯打包在一起，這樣業務開發人員就不用關心這些技術細節了。
Beta 版的音頻服務雖然沒有做到儘量好，但及時趕上了業務上線的時間，為業務快速在市場推廣爭取了時間。以下是音頻服務的一些技術選擇：
採樣：音頻 8k，筆記 59 幀
預處理：WebRTC 中的 audio_process 模塊
編解碼：FFmpeg 框架，G723.1，固定碼率
打包：均勻切分成 udp 包，自增 sn
緩存：固定緩衝長度
丟包處理：音頻不管，筆記重傳
傳輸：服務端中轉，以 room 為單位
錄音：服務端存儲 udp 包，異步轉碼
“
再說一下識別集群
”
學生用手機拍照上傳題目的圖片後，圖片在系統中會經歷 OCR 識別、語法糾正、題目搜索和學科識別四個環節。
OCR 識別，就是把圖像上的文字識別成具體的一段文字；
語法糾正，就是通過語法分析糾正那些識別錯的字，儘量提高識別的準確率；
識別出的文本會通過搜索服務來找到這個題目的答案；
學科識別 是通過文本分類識別出題目所對應的年級和學科，有了題目的年級學科等信息，系統可以自動地把題目分配給該年級該學科的老師。
整個識別集群裡，最複雜的是 OCR 識別。印刷體文字識別看似簡單，但在實際業務場景中卻是非常難的，因為會面臨大量的模糊、圖片扭曲、照片低質量、複雜公式排版等問題，一般的 OCR 算法在這樣的業務場景中基本不能用。
我們的 OCR 識別的算法的大體流程是這樣：首先對圖片進行預處理，如圖片角度糾正，圖片亮度均勻糾正等；然後進行版面分析；最終得到識別結果。
版面分析是最複雜的部分：
我們通過自研的二值化算法來定位文字的像素，並將像素轉化成小碎塊；
然後進行排版組合，找到文本行的段落結構，順便進行文本行扭曲矯正。
這其中涉及到大量的圖像處理算法，重點是選擇合適的高效的算法進行組合。版面分析的同時，還會用到字符識別。
對於中文來說，一般會用卷積神經網絡，也就是CNN 算法；
對於英文來說，一般會用遞歸神經網絡，就是RNN。
我們用的是 RNN 中的一種經典網絡 LSTM（長短記憶模型）。因為我們識別的是學生的題目，學生提問數學題的情況特別多，數學題中包含著大量的公式，公式識別需要做一些特殊處理，這也是所有識別中最難的部分，需要結合單字識別和公式版面分析綜合來識別。
在線答疑業務系統的深度優化
Beta 版系統上線以後，隨著用戶量增大，各種各樣的真實場景對系統的可用性提出了更大的挑戰，加上產品需求不斷增加，我們對整個系統進行了全面的升級。主要的升級有四個方面：
音頻通信（音質優化、延時降低、連接穩定等）
老師調度策略（更好策略、用戶畫像、供需調整等）
系統架構（架構優化，模塊化，監控報警）
識別算法（更多科學、知識點分類、講題模塊等）
首選音頻服務遇到了不少問題，例如：有的學生會反饋說和分配的老師連接不上，系統不是高可用，有時音質差，系統對網絡抖動敏感、卡頓、掉線、超時、安卓記性適配等。針對這些問題，我們主要做了三點：
音頻引擎升級
網絡傳輸升級
雲適配
我們拋棄了 FFmpeg 框架，重新採用了 WebRTC 的整體音頻引擎，增加了多種採樣率、動態碼率、多種編碼方式、FEC（Forward Error correction）、DTX（Discontinuous Transmission），並將這些配置全部做成了動態可變的，針對網絡狀況和主機本身狀態的不同，這些配置會實時地自適應變化。
比如，當主機 CPU 使用率較高的時候，引擎會切換到 CPU 效率較低的音頻編碼算法。為了減少傳輸的數據包數量，我們將筆記數據包和音頻數據包進行了合併，通過自研的算法協調數據包的重發策略。
網絡傳輸方面，我們沒有使用 WebRTC 的傳輸模塊，而是重新寫了一套傳輸模塊。整體架構如圖：
音頻服務器負責傳輸音頻數據
調度服務器負責協調資源
ZK 集群負責監控各服務的生死
選擇 BGP 機房作為核心機房，ZK 集群必須全部部署在同一個核心機房，調度服務器可以部署在不同的核心機房，客戶端通過調度服務器獲取到可用的音頻服務器，以及建議的傳輸路由。
音頻服務器可以部署在任何機房，音頻傳輸的時候，也會經過一個或多個機房。調度服務器會提供多條路由，客戶端和音頻服務器都會不斷地探測各條路由線路的網絡狀況，如果當前的傳輸路由網絡不好，客戶端會自動切換到網絡狀況最好的那條路由線路。
值得一提的是，我們的傳輸架構是雙向獨立傳輸，也就是說，近端到遠端的路由與遠端到近端的路由可能是不一樣的。為了進一步提高連接成功率，系統還支持 TCP 協議傳輸和 P2P 直連。
為了解決安卓機型的適配問題，我們採用了雲適配的架構。根據線上的錄音和日誌數據，人工設置出最合適的配置參數和策略，將配置和策略寫入數據庫，供調度服務器選擇。隨著不斷的動態調整，配置和策略達到了最優效果。我們最終完成了4000多種機型的適配。
分發服務拆分
隨著產品的發展，加上調度邏輯都放在答疑中控服務裡，導致中控服務裡的邏輯特別多，代碼越來越臃腫。針對上面問題，我們從答疑中控中把調度邏輯拆出來單獨放在一個分發服務裡，通過消息隊列解耦。
拆完之後產品和運營的需求就很快得到釋放，調度策略的升級速度大大加速。分發服務後接模型和策略庫，模型和策略庫決定分發服務的各種調度策略。
從調度算法架構上，我們可以看到分發服務可以做到的一些事情。
最下面是知識圖譜和知識分類，我們有一個教研團隊，專門研究知識圖譜和知識分類方法，我們希望把問題分配給對這個題目背後的知識點最擅長的老師；
然後上面是用戶畫像，我們通過老師和學生的行為數據來分析老師和學生的特點，比如有的學生特別喜歡講得快的老師；
再上面是需求與供給模型及預測，學生提問的需求量在不同時間段不一樣，比如平時晚上會有一個提問高峰，而老師的供給量也有一個規律，我們的系統可以預估供給與需求的情況並進行調節，比如老師不夠用的時間段提前給某些老師發消息；
最上面是分發算法，根據下面幾層提供的各種能力，通過多種策略實現實時調度和最優化。
整個業務邏輯是由答疑中控來控制的，由於當時上線時間緊，我們正好有一個 C++ 的異步網絡框架，就用 C++ 開發了業務中控。但 C++ 做這個業務中控並不是特別合適，如 C++ 語言開發起來相對慢、容易出 Bug、網絡庫複雜等。我們決定重構業務中控，並升級整體架構。
在架構調整之前，中控服務既要做基礎服務（如TCP連接、消息重傳等），又要做業務邏輯。我們把基礎服務和業務邏輯拆開，拆出一個單獨的消息網關服務，專門負責長連接，通過消息隊列與業務服務通信。
這樣一來，消息網關服務可以將長連接做得更加可靠以及高可用，而業務服務可以只關心業務邏輯，整體架構更加合理。在架構調整的時候，我們採用了 GO 語言來開發，因為 GO 語言對網絡和併發支持得更好，並且支持內存回收，使得開發效率更高。
答疑中控業務流程比較複雜，答疑中控需要維持老師、學生、服務器三者的狀態一致，有很多異常情況需要處理。我們在重構中控業務邏輯的時候，引入了狀態機的概念。我們用狀態圖詳細地描述出整個答疑過程中老師、學生、服務器三者的所有的狀態情況、狀態的轉化條件、狀態的轉化動作。
除了核心業務升級，我們還做了其他一些補充，如日誌與監控。監控分為物理監控（zabbix+grafana）、接口監控（自研後臺）、業務監控（ELK，自研後臺）。日誌收集基本上是用 ELK，主要是服務端日誌，客戶端 debug 用的日誌也可以上傳服務端再同步到 ELK。
除了上述的重點優化模塊，我們還對整體服務做了很多拆分，最終形成了一個整體有序的業務架構。最上面的是客戶端，然後是接入層，包括長連接和接口服務等，然後是主要的業務服務層，下面是一些公司公共的基礎服務，最下面是存儲服務。同時貫穿整個架構的有 BI 體系、日誌體系和監控體系。
技術思考
一個技術負責人很容易過分關注技術本身，比如：
團隊的技術如何選型？
後端是不是要做服務化？
各業務是不是要做統一的監控？
是一步到位還是要小步快走？
到底什麼樣的技術才是最牛逼的？
......
我認為最重要的反而是在業務上，因為所有的技術都是基於業務而存在的。如果拋開業務只談技術，不能創造任何的價值。特別是一個技術總監或 CTO，他的腦子裡最先考慮的應該是業務。他需要明確公司的戰略和業務方向，未來半年到一年業務會變成什麼樣子，然後再把業務發展分解為技術的打發和節奏，最後量化到各個技術團隊或成員。
苗廣藝
學霸君高級技術總監
在加入學霸君之前，先後擔任央視網高級研發工程師、搜狐研究院副研究員、歡聚時代（YY多玩）資深算法工程師、奇虎360資深算法工程師。早期工作經驗以圖像識別算法為主，研發過分佈式存儲內核，後投入深度學習技術研發。在業內最早將深度學習技術引入到拍照搜題領域，幫助學霸君App以技術優勢快速佔領市場。從頭組建了直播答疑技術團隊以及北京君君輔導事業部技術團隊。目前在學霸君擔任技術總監，負責學霸君App技術開發以及整個公司的基礎技術研發。
本文選自《CTO說》
30+導師的傾情分享
掃描二維碼
進入購買頁面
相關推薦
