網際網路是如何把“原始人”逼成“機器人”

【導讀】網際網路快速發展的這十多年，我們見證了企業軟體架構的多次迭代和演變。初期階段都使用JSP+Servlet，工程師感覺程式碼直接寫在jsp頁面上不優雅，也不方便除錯。後續發展為JSP+Javabean，把業務程式碼封裝到JavaBean裡面，頁面之間的跳轉透過JSP來完成，有了真正意義上的程式碼邏輯封裝。雖然架構簡單，但是技術棧簡單上手非常容易，雖原始但是很快樂，不脫髮，也沒有996。Struts的出現解決了所有的邏輯都在程式碼中跳轉的弊端，透過配置化來解決跳轉和程式碼的耦合。但人都是惰性動物，配置的地方太多了也感覺太麻煩，Spring提倡減少配置或者不配置來讓程式碼更快捷的執行，最終Spring接管了軟體開發工程師的技術棧，同時單體應用的時代也有了一個飛躍的進步，我們進入了現代人的社會。

我們也是一個創業型公司，在創業階段快樂的使用著Spring所提供的全家桶和便利性，隨著業務規模和需求迭代頻率的增加，單體應用也從原來的“美男子”變成“中年油膩大叔”反應遲鈍了，也抗不住壓力了，快也快不了，各種問題隨之而來。

一、業務規模以及面臨問題

流量為王、使用者為王的網際網路時代，隨著投放廣告力度的增大，以及私域流量的爆發，使用者量也帶來了爆炸式的增長。整個結束團隊在“痛”並“快樂”的環境下一次又一次的交付著迭代。痛是因為現有的架構模式滿足不了業務的需求，快樂是因為業務發展的好，大家的收益會更好。 

隨著研發隊伍的壯大，專案以及迭代需求的增加，技術架構出現多種問題，這些問題極大的影響了交付速度和交付質量。主要包括如下：

程式碼衝突加劇：多個人或者一個團隊一起維護一個模組，共同開發。當提交程式碼的時候發現大量衝突，每次提測或者發版的時候需要花大量的時間來解決衝突。隨著團隊規模的增大以及專案複雜程度增加，程式碼衝突的現象越嚴重；

模組耦合嚴重：模組之間透過介面或者DB相互依賴，耦合越來越嚴重。而且不同的人，寫程式碼的風格不一樣，程式碼質量也不一樣，上線前需要協調多個團隊，任何小模組的異常都會導致整個專案釋出失敗；

專案質量下降：由於所有的程式碼都是在一個服務裡面，做一次改動，可能會牽一髮而動全身，程式碼衝突以及耦合嚴重，導致測試覆蓋範圍不充分，經常會出現沒有更改的模組線上上突然出現問題，查詢後發現是由於工程師不小心做了某種改動，但是測試用例並沒有覆蓋；

團隊效率下降：由於大量時間在處理程式碼衝突，消耗了研發人員大量的時間；而測試人員為了提高專案質量，不得不在每次發版之前做全方位的迴歸測試，本身一次小的迭代結果專案時間卻很長；

效能達到瓶頸：QPS以及達到天花板，增加硬體配置都沒有辦法來提升效能，導致運營同學不敢大規模的做活動，因為一旦使用者量上升就會導致介面訪問超時或者資料庫CPU飆升到100%；

運維手段乏力：當線上出現問題的時候，只能透過重啟的方式來暫時緩解問題。

所以我們意識到系統架構必須要改變了，單體應用肯定不能滿足當前以及後續業務的發展了，否則會被認定技術阻礙業務的發展，這種情況是大忌，有可能會被抓出去“祭天”的。但是在技術部門上方懸浮的標語“架構方案千萬條，按時上線第一條”也提示著大家業務在發展，不會因為技術架構的變動而暫停前進。

二、平臺架構演變過程

微服務的首要階段是框架選型，在Spring Cloud和Dubbo的選型上團隊中間出現了很多爭論，經過多維度的考核最終選定Dubbo做微服務的框架。由於時間緊迫，團隊一邊做著需求迭代以及新功能上線，一邊還得做新架構開發。然而，在大家辛苦半個月後第一個版本交付測試的時候卻出現了問題，每個人負責的模組的程式碼風格不統一，框架結構不統一，其他人如果想參與到對應的模組卻不清楚從哪裡入手，培訓成本過高，所以我們必須得造輪子，讓車子跑到更快，更穩。

討論最後一致認定，如果依賴制度和文件是不可能約束研發人員的，必須提供工具來快速的生成框架結構以及程式碼邏輯，完成常用的資料庫以及快取操作，程式設計師只需要往對應的虛擬碼中加入業務程式碼即可。本地測試透過提交Jenkins後自動編譯，服務自動註冊、自動釋出Dubbo服務。同時，團隊內部約定了新框架的呼叫流程，避免不規範的行為再次發生。

生成程式碼後的框架結構以及呼叫關係如下，以產品服務為例。

同時約定了系統的訪問流程和服務之間的呼叫原則，由於服務之間透過介面呼叫，原則只要上釋出出來的服務都可以被呼叫，會形成A呼叫B，B也有可能呼叫A的迴圈依賴呼叫。所以團隊的約定如下：基礎服務（basic）層主要做資料庫的操作和一些簡單的業務邏輯，不允許呼叫其他任何服務；聚合服務（back）層，允許呼叫基礎服務層，完成複雜的業務邏輯聚合操作；不允許呼叫其他back層。

老系統逐步的往新架構來遷移，新平臺的TPS有非常大的提升，平臺執行的穩定性也有較大程度的提升。工程師的“痛”也逐步減輕，加班頻率也降低了很多，驚喜的發現部分人員的髮量竟然增加了不少。然而，平臺是在一直演變的，沒有哪一種架構能永遠保持不變，隨著時間的推薦，使用者量還在不斷的增加，同時新專案數量也逐步增加，新架構也逐步暴露出很多問題。

微服務架構提倡將單一應用程式劃分成一組小的服務，服務之間透過RPC方式互相協調、互相配合，形成分散式呼叫，橫向擴充服務的數量來提高整體的QPS量。然而在簡單業務場景下並沒有任何問題，當業務場景複雜的時候就會出現A->B->C->D->E->F->G->H->I->J…N,會導致服務整體不穩定，稍微修改下業務邏輯影響一整條鏈路。或者上游需要同時通知多個下游的時候微服務的架構就會顯得單薄乏力，所以需要使用MQ來縮短整個呼叫鏈或者解耦同步通知多個下游的場景。例如使用者註冊流程，在未使用MQ的時候，下游需要關注使用者註冊資訊的時候，只有通知上游去呼叫介面。但是使用MQ後，上游只需要傳送MQ即可，下游訂閱MQ消費訊息並處理，同時上游並不會關注下游的個數，最終整體的呼叫鏈縮短了，效能也有較大的提升。

每逢大促活動的時候，如何快速觸達使用者？之前的做法是先查詢使用者登錄檔，然後批次寫入待發訊息中心，訊息中心收到請求後快速寫入DB中，然後透過定時任務來掃描並呼叫簡訊、PUSH介面。但是透過MQ可以大大提高系統的QPS。

三、MQ的選型

目前業內比較主流的 MQ 包括 RocketMQ、ActiveMQ、RabbitMQ、Kafka等，關於效能、儲存、社群活躍度等各方面的技術對比都相差不大，但我們發現透過簡單的選型對比，很難抉擇到底選擇哪款MQ產品。因為金融行業對於資料一致性以及服務可用性的要求非常高，所以任何關於技術的選項都顯得尤為重要。在做技術選型的時候，我們重點關注如下：

另外，在微服務中分散式事務是一個經典話題，如何簡單、高效的完成分散式事務對於架構者來說非常重要，在眾多的MQ中我們最終選定了商用版的RocketMQ，對於分散式事務也能非常好的支援。

經過幾次的重構後微服務中存在的問題也逐步消除，隨著MQ的加入系統的TPS又有了較大的提升，同時透過本地快取和遠端快取相結合的方式來高效實用快取。對於非核心流程的RPC介面也梳理了降級和熔斷的流程，目前穩定性提升的非常多。新版的微服務架構如下：

平臺架構沒有終點、最佳化沒有終點，單體應用有單體應用的優勢和亮點，分散式系統有分散式系統的不足，每一家網際網路企業所面臨的階段不一樣，所以做法也不一樣。但是不要為了追求技術而使用技術，夠用就好、解決問題就好。

四、總結

構建複雜的應用真的是非常困難，單體式的架構更適合輕量級的簡單應用。如果你用它來開發複雜應用，那真的會很糟糕。微服務架構模式可以用來構建複雜應用，當然，這種架構模型也有自己的缺點和挑戰。微服務實施過程中由於會引入各種中介軟體，所以會出現各種各樣異常資訊，對於開發人員和架構師來說都是一種挑戰。目前“雲”是趨勢所在，如果條件允許的話，建議所有的中介軟體全部使用“雲”上的產品，穩定性有保障、降低了維護成本。最後如果能真正成功實施微服務，無非是合理的組織架構、對於專案的認可、工具的合理化、持續整合過程。