2015年3月，從網易BoBo離開，帶著創業的情懷與期待，來到了貝聊。彈指間，已經過了快三年。在這三年的歲月裡，貝聊後臺系統架構經歷了一個困難而又富有成就感的演變過程。
這個演變的過程，大致可分成幾個階段：技術平臺替換階段、服務化萌芽階段、服務化形成階段以及服務化發展階段。
一、技術平臺替換階段
貝聊創業初期，後臺系統架構是基於PHP技術平臺的，由兩個PHP開發人員維護。PHP技術平臺，是大部分公司創業初期的首選。公司創業初期，業務複雜度低，使用者量少，核心就是以儘量低的成本（人力成本、時間成本、技術成本與伺服器成本）完成開發。
從2013年至2015年初，經過三年多的快速發展，原來基於PHP技術平臺的配備（系統與人員）開始無法滿足公司業務發展的需要了。隨後，也就開始了JAVA技術平臺逐步替換PHP技術平臺這一階段。
萬事開頭難，技術平臺替換工作初期面臨了很多困難。
首先，公司業務在快速發展，系統重構與業務需求迭代是並行的。前人說的：這相當於是給高速行駛的跑車換輪子，難度與風險可想而知。
其次，初來乍到的JAVA技術團隊能行麼？沒有成果，還沒有得到領導、同事的認可。
再次，原來的PHP技術團隊能配合好工作麼？重構系統相當於是要推翻他們原來負責的東西。
最後，JAVA技術團隊對幼教行業缺乏瞭解，與網易BoBo的娛樂直播業務完全不同，是一個全新的業務領域。
面對這些困難，領導制訂的技術平臺替換策略是：新的業務系統採用JAVA技術開發，舊的業務繼續在PHP技術上迭代，同時逐步採用JAVA技術進行重構、切換。
現在回想這一階段的經歷，記憶猶新。
新業務系統開發問題不大，重構的工作就頭疼了。跟擔憂的一樣，PHP技術團隊是有情緒的，溝通過程中大大小小的衝突不知道起了多少次。重構的過程中，線上業務大大小小的問題不知道出了多少回，因為責任的問題也不知道扯了多少次皮。加班、通宵、週末在家隨時準備處理問題，都是常態。某天晚上因為身體不適請假提前回，發現“天還是亮的”，居然很不習慣。
還好，這一困難的階段堅持下來了。到2016年初，基本（90%）完成了原有PHP技術平臺系統的替換重構工作。這離不開領導的信任與包容，離不開JAVA技術團隊的付出，也離不開PHP技術團隊的配合與犧牲。這麼多的困難最終都能解決，核心點在於大家目的是一樣的：以公司發展為核心。
二、服務化萌芽階段
技術平臺替換階段的重點是在保障業務正常迭代的情況下，確保系統重構與切換的平穩過渡，還沒有充分考慮新系統架構的可擴充性與可維護性。
2016年3月，在公司完成B輪融資後，技術架構面臨著無法滿足產品線與技術團隊規模快速擴大的風險。多個產品線，一堆開發人員，同時在僅有的幾個應用上來開發，勢必導致應用的業務越來越多、越來越臃腫。開發如何協作，版本如何管理，風險如何管控？搞不好就亂套了。
在對這些問題的思考中，進入了服務化萌芽的階段。原來的架構如下圖所示：
原來單個應用系統裡整合了很多業務，多個應用系統存在重複業務，各個應用系統各自呼叫第三方服務（如簡訊、推送與IM等）。升級調整後的架構如下圖所示：
這一階段工作主要是公共服務的抽取與業務模組複用。比如將簡訊、推送與上傳圖片等抽取至一個公共的Web應用中，提供統一的REST API介面；同時，引入輕量級RPC框架Hessian，實現系統間的業務模組複用。
這樣的架構存在兩個明顯的問題：一是REST API介面的呼叫方式效率不高，二是業務模組Hessian呼叫關係增多後難以管理。同時，在產品線與團隊成員規模擴大的情況下，並不能很有效的解決上面提出的問題風險。
三、服務化形成階段
2016年5月，引入了阿里巴巴的Dubbo分散式服務框架。全面開始對貝聊的系統業務進行分解重構，至2016年底，貝聊分散式服務化架構基本形成。架構如下圖所示：
這一階段，還引入了分散式配置中心Disconf（百度）與分散式任務排程系統Elastic-Job（噹噹）。至此，可以較好的解決產品線與團隊成員規模擴大帶來的問題了。業務服務元件新增與組合的靈活性，可以解決產品線增加的問題；而團隊成員的增加，正是維護大量業務服務元件之所需。同時，基於DUBBO協議的介面呼叫方式，效率也比HTTP
API方式要高很多。
至此，服務化架構基本成型，但同樣也存在兩個明顯的問題：一是服務元件劃分邊界不清晰、服務元件間存在相互呼叫的關係；二是缺乏異常鏈路的監控機制。
四、服務化發展階段
2017年初，重新思考了服務化元件劃分與設計的問題。為了避免出現相互呼叫導致關係混亂的問題，將服務化元件分成兩類：基礎服務元件與業務服務元件。同時，制訂了元件間的呼叫原則：只允許上層元件呼叫下層元件，確保呼叫的單向性。架構如下圖所示：
2017年中，引入了大眾點評的CAT（Central
Application
Tracking）異常監控專案，並於10月份完成所有應用系統的接入。CAT的接入實現了異常棧的監控與告警通知，這讓很多BUG在使用者反饋前已經被精確的發現、解決，極大的提升了使用者體驗與開發人員的成就感。
五、結語
2017年底，整個服務化架構終於是有了那麼點樣子。這裡要感謝研發部每個兄弟的辛苦付出！不管是在貝聊的，還是已經離開貝聊的，SVN/GIT倉庫裡的專案程式碼都已經烙上了你們深深的印記（也留下了很多你們挖下的坑，哈哈）。未來還有很問題與困難在等著，貝聊研發部的兄弟們不要停止前進的腳步，讓我們一起迎難而上。
李歡與高西（PHP兄弟）、鄭曉濱（研發部第2個員工）、林添瑞（研發部第4個員工）、李興光（研發部第5個員工）、李海文、馬玲、藍國棟、江達賢、程健宇、李志鋒、柯涪湘、邱俊、林宋勉