貝聊系統架構服務化之路

2015年3月，從網易BoBo離開，帶着創業的情懷與期待，來到了貝聊。彈指間，已通過了快三年。在這三年的歲月裏，貝聊後臺系統架構經歷了一個困難而又富有成就感的演變過程。

這個演變的過程，大體可分紅幾個階段：技術平臺替換階段、服務化萌芽階段、服務化造成階段以及服務化發展階段。

1、技術平臺替換階段

貝聊創業初期，後臺系統架構是基於PHP技術平臺的，由兩個PHP開發人員維護。PHP技術平臺，是大部分公司創業初期的首選。公司創業初期，業務複雜度低，用戶量少，核心就是以儘可能低的成本（人力成本、時間成本、技術成本與服務器成本）完成開發。

從2013年至2015年初，通過三年多的快速發展，原來基於PHP技術平臺的配備（系統與人員）開始沒法知足公司業務發展的須要了。隨後，也就開始了JAVA技術平臺逐步替換PHP技術平臺這一階段。

萬事開頭難，技術平臺替換工做初期面臨了不少困難。

首先，公司業務在快速發展，系統重構與業務需求迭代是並行的。前人說的：這至關因而給高速行駛的跑車換輪子，難度與風險可想而知。

其次，初來乍到的JAVA技術團隊能行麼？沒有成果，尚未獲得領導、同事的承認。

再次，原來的PHP技術團隊能配合好工做麼？重構系統至關因而要推翻他們原來負責的東西。

最後，JAVA技術團隊對幼教行業缺少了解，與網易BoBo的娛樂直播業務徹底不一樣，是一個全新的業務領域。

面對這些困難，領導制訂的技術平臺替換策略是：新的業務系統採用JAVA技術開發，舊的業務繼續在PHP技術上迭代，同時逐步採用JAVA技術進行重構、切換。

如今回想這一階段的經歷，記憶猶新。

新業務系統開發問題不大，重構的工做就頭疼了。跟擔心的同樣，PHP技術團隊是有情緒的，溝經過程中大大小小的衝突不知道起了多少次。重構的過程當中，線上業務大大小小的問題不知道出了多少回，由於責任的問題也不知道扯了多少次皮。加班、通宵、週末在家隨時準備處理問題，都是常態。某天晚上由於身體不適請假提早回，發現「天仍是亮的」，竟然很不習慣。

還好，這一困難的階段堅持下來了。到2016年初，基本（90%）完成了原有PHP技術平臺系統的替換重構工做。這離不開領導的信任與包容，離不開JAVA技術團隊的付出，也離不開PHP技術團隊的配合與犧牲。這麼多的困難最終都能解決，核心點在於你們目的是同樣的：以公司發展爲核心。

2、服務化萌芽階段

技術平臺替換階段的重點是在保障業務正常迭代的狀況下，確保系統重構與切換的平穩過渡，尚未充分考慮新系統架構的可拓展性與可維護性。

2016年3月，在公司完成B輪融資後，技術架構面臨着沒法知足產品線與技術團隊規模快速擴大的風險。多個產品線，一堆開發人員，同時在僅有的幾個應用上來開發，勢必致使應用的業務愈來愈多、愈來愈臃腫。開發如何協做，版本如何管理，風險如何管控？搞很差就亂套了。

在對這些問題的思考中，進入了服務化萌芽的階段。原來的架構以下圖所示：

原來單個應用系統裏集成了不少業務，多個應用系統存在重複業務，各個應用系統各自調用第三方服務（如短信、推送與IM等）。升級調整後的架構以下圖所示：

這一階段工做主要是公共服務的抽取與業務模塊複用。好比將短信、推送與上傳圖片等抽取至一個公共的Web應用中，提供統一的REST API接口；同時，引入輕量級RPC框架Hessian，實現系統間的業務模塊複用。

這樣的架構存在兩個明顯的問題：一是REST API接口的調用方式效率不高，二是業務模塊Hessian調用關係增多後難以管理。同時，在產品線與團隊成員規模擴大的狀況下，並不能頗有效的解決上面提出的問題風險。

3、服務化造成階段

2016年5月，引入了阿里巴巴的Dubbo分佈式服務框架。全面開始對貝聊的系統業務進行分解重構，至2016年末，貝聊分佈式服務化架構基本造成。架構以下圖所示：

這一階段，還引入了分佈式配置中心Disconf（百度）與分佈式任務調度系統Elastic-Job（噹噹）。至此，能夠較好的解決產品線與團隊成員規模擴大帶來的問題了。業務服務組件新增與組合的靈活性，能夠解決產品線增長的問題；而團隊成員的增長，正是維護大量業務服務組件之所需。同時，基於DUBBO協議的接口調用方式，效率也比HTTP API方式要高不少。

至此，服務化架構基本成型，但一樣也存在兩個明顯的問題：一是服務組件劃分邊界不清晰、服務組件間存在相互調用的關係；二是缺少異常鏈路的監控機制。

4、服務化發展階段

2017年初，從新思考了服務化組件劃分與設計的問題。爲了不出現相互調用致使關係混亂的問題，將服務化組件分紅兩類：基礎服務組件與業務服務組件。同時，制訂了組件間的調用原則：只容許上層組件調用下層組件，確保調用的單向性。架構以下圖所示：

2017年中，引入了大衆點評的CAT（Central Application Tracking）異常監控項目，並於10月份完成全部應用系統的接入。CAT的接入實現了異常棧的監控與告警通知，這讓不少BUG在用戶反饋前已經被精確的發現、解決，極大的提高了用戶體驗與開發人員的成就感。

5、結語

2017年末，整個服務化架構終因而有了那麼點樣子。這裏要感謝研發部每一個兄弟的辛苦付出！不論是在貝聊的，仍是已經離開貝聊的，SVN/GIT倉庫裏的項目代碼都已經烙上了大家深深的印記（也留下了不少大家挖下的坑，哈哈）。將來還有很問題與困難在等着，貝聊研發部的兄弟們不要中止前進的腳步，讓咱們一塊兒迎難而上。

感謝大家在貝聊的付出！

李歡與高西（PHP兄弟）、鄭曉濱（研發部第2個員工）、林添瑞（研發部第4個員工）、李興光（研發部第5個員工）、李海文、馬玲、藍國棟、江達賢、程健宇、李志鋒、柯涪湘、邱俊、林宋勉