微服務還是單體，應用架構怎麼選？

近幾年，由於微服務生態建設的完善，微服務架構漸成趨勢，逐漸流行。業內人士也都在爭先恐後想一睹微服務芳容，甚至想王老虎搶親。但同時存在沒有認真考慮微服務架構是否適合自己的應用場景以及組織文化的問題。

本人在前幾篇博文已經對微服務生態有了闡述。所謂生態，實際上講的是天時地利人和，講的是各方和諧。微服務生態的好壞，對微服務架構的實現有著直接的關聯。所以，在實施微服務架構應用的同時，大家應該著力

打造微服務生態。

以下是本人對於選擇微服務架構還是單體架構提出的八個原則。本人才疏學淺，冒昧班門弄斧，讓各位大咖見笑了。

1.對於業務需求而言，單體架構適合需求穩定可見，專案排期固定，變更在可控範圍內，投資穩定的業務需求。而微服務架構適合於需求vuca，使用者量大，使用者體驗要求高（無時無刻，無論何處）、需要持續更新迭代的專案，當然需要持續投資。

2.對於系統執行而言，單體架構適合於訪問量穩定可預期，系統效能需求可控，效能壓力均衡，沒有集中的突出的效能壓力點的系統執行狀態；而微服務架構通過對資料庫分拆、業務功能分拆、和執行時資源動態伸縮的方法（參考《the

art of

scalability》），使得應用能面對訪問量突變，效能突變、效能壓力不均衡、壓力點集中的系統執行狀態。

3.對於開發過程而言，傳統的瀑布式開發模式比較適合單體應用的開發，基於精益理念的敏捷開發模式適合於微服務架構，當然這不是絕對的，單體應用也可以採用敏捷開發模式。

4.對於專案開發模式而言，單體架構應用可以用外包模式，開發外包，運維外包，需求和實施兩頭在外，甲方專案經理主要負責在規定時間內需求落地，專案經理和運維經理可以分開；微服務架構適合於自開發自運維，或者與長期戰略合作夥伴共同開發運維，適合於產品經理責任模式，「誰開發，誰運維」。

5.對於架構設計而言，單體應用無需考慮太多解耦問題，事務一致性很容易實現。而微服務為分布式架構，業務上需要領域專家和架構師一起進行合理的業務分拆和功能分拆，同時要保證執行時事務的最終一致性，還要考慮跨微服務session管理和統一認證鑑權問題，所以架構設計要求極高。

6.對於infrastructure而言，單體應用結構簡單，所以實體機技術和虛機技術就可以滿足單體架構了，而支援微服務架構應用的開發需要基礎架構快速ready

和自動伸縮的能力，所以更適合在雲平台下進行。

7.對於團隊運作而言，由於單體架構的建設(需求設計開發測試發布運維等過程)按部就班進行，各個團隊聯絡無需很緊密，故對devops要求不高。而對於微服務建設，需要全棧團隊自助服務，團隊內部聯絡緊密，反饋及時，因此，特別依賴於持續整合持續部署和devops。（康威定律）

8.對於測試發布運維而言，由於單體應用架構簡單，且技術單一成熟，故測試發布運維壓力不大；而由於微服務架構的分布式架構，服務元件眾多，服務排程複雜，資源分配會動態變化，發布過程要求無感知發布，且廣泛使用開源技術，所以測試發布運維難度加大，需要投入大量自有人力和專業的第三方支援。