2.2.3 哪些原因導致系統架構往微服務架構的方向演進

前文已經對網站架構演進做了總結。這個演進過程比較常見，不過，在不同的業務和技術團隊中，優化和演進肯定不會完全相同，中間可能會有微小的差異。不過總結下來，網站架構演進主要包括三個原因，如圖2-14所示。

圖2-14 網站架構演進的原因

隨著業務的增長和技術團隊的完善，系統在逐漸優化。在優化方案應用后，業務量還在不斷增長，此時為了應對日益復雜的業務場景，就要使用分而治之的手段進行服務化拆分。將整個網站業務拆分成不同的產品線，通過分布式服務來協同工作。

導致系統架構向微服務架構方向演進的原因如圖2-15所示。

圖2-15 向微服務架構方向演進的原因總結

（1）從業務規模來說，初始的系統架構肯定無法支撐越來越復雜的業務場景，此時就需要進行系統優化，優化手段有緩存、集群、前后端分離、動靜分離、讀寫分離、分布式數據庫和分布式文件系統等。若這些系統優化手段都已經用上，還是不能滿足業務的成長速度，就要進行業務梳理和系統拆解。

（2）從溝通成本和敏捷開發的角度來說，當技術團隊中的成員已經有成千上萬個，技術小組也有成百上千個的時候，如果還在一個巨無霸的單體項目上開發，都在一個工程里提交代碼、修改Bug、切換不同的分支，這就是災難了。系統的分工不明確、責任不清晰，導致溝通成本高、研發效率低，也無法做到快速迭代。畢竟不是在項目剛開始的階段，當時可能只有一個技術團隊和少量的開發人員。

（3）從團隊的技術儲備來說，項目剛開始的階段，技術團隊人數比較少，團隊人員主要是以開發人員為主。但是隨著業務規模和企業規模的擴大，在項目架構的不斷優化過程中，各種人才的儲備已經充足。技術團隊也日趨完善，前端技術團隊、后端技術團隊、測試團隊、公共服務團隊、DBA團隊、運維團隊、架構團隊等都已經存在，此時再進行業務拆分和架構的完善就有了足夠的底層支撐。

（4）從“微服務架構”的發展來說，微服務架構的實踐并不是空中樓閣，可以實際落地了。近幾年的時間里，微服務架構已經由最初的理論派逐漸落地和完善，與微服務相關的生態已經建立起來，開源框架和企業內部自研的框架都已投入生產，技術實踐也不再是遙不可及的了。比如Spring Cloud框架及與之相關配套的微服務組件為行業提供了一站式的解決方案，解決了很多企業和技術團隊關于架構選型和維護方面的困難。

當然，此時可能有讀者會繼續思考下去，難道只能往微服務架構的方向上演進嗎？答案肯定不是，在前面的架構演進圖中，演進方向是一條筆直的線。而現實情況中肯定是有不同分支的，微服務架構也只是眾多技術架構中的一個，適合自身業務系統和技術團隊的才是最好的架構。