可能你會面臨這樣一種情況，在架構設計之前，你對業務不甚瞭解，需求給到的也模稜兩可，這個時候你既無法明確到底是要使用單體架構還是使用微服務架構，如果使用單體，後續業務擴充套件可能帶來大量修改，如果使用微服務，前期可能在工期上把專案給耽誤了，你該怎麼辦？這就是這篇文章想要研討的面向微服務的單體架構的由來。

為什麼不用傳統單體架構？

　　我們可以看到隨著業務的升級，單塊的程式碼的拆分會變得越來越困難，如果在前期沒有做好規劃和伏筆，那麼後續的演化就是一場災難。所以，目前的設計如果是企業級別的，都必然要做架構的適當冗餘，因為沒有人能知道未來長什麼樣，架構必然和業務一樣是隨著綜合因素慢慢長出來的，不可能一蹴而就，一步到位。

為什麼不用微服務架構？

• 資料一致性分發
• 資料聚合 Join
• 分散式事務
• 單體系統解耦拆分

　　這裡引用架構師楊波(前Ebay架構師/攜程/拍拍貸研發部總監，資深技術架構師，微服務技術專家)的一些觀點：

“企業一開始不推薦直接使用微服務，因為微服務需要前期基礎設施的投資，複雜性很高(詳見下面微服務的四大痛點)，如果對問題領域並不是很理解，一開始用微服務，你很難去劃分服務的邊界，你的生產力反而會比較低，而且你花了很大精力進行開發，你的產品並沒有被市場驗證過，有可能會失敗，所以這個選項風險會比較高。所以我們推薦的是單塊優先，先從單塊運用做起，這樣成本低，團隊成員也比較少，無須太多研發投入，就可以交付一些基本的功能給客戶使用。

　　隨著應用越來越成功，客戶增加，你的系統複雜度會越來越高，就會出現單塊應用和團隊規模之間的矛盾，生產力會隨著業務複雜度逐漸降低。所以在一些初創型公司，你更多看到的是單塊應用，只有一些中大型的公司會看到微服務架構。”

　　“交叉點表明，業務已經到達了一定的複雜性，單塊應用已經無法滿足業務增長的需要，研發效率開始下降了，而微服務可以提升研發和交付的效率。這個點需要架構師去綜合、權衡。個人經驗，一般團隊需要達到百人規模，才去考慮微服務。”

• 併發量不高——業務流量並沒有達到千萬或億級別
• 團隊規模——團隊成員並沒有達到百位規模
• 系統複雜度——沒有高併發也就談不上覆雜度
• 適用場景——網際網路/物聯網

微服務相容的單體架構

演化方便——低程式碼演化

　　如上所示，我們可以看到API在拆解過程中，基本沒有做任何程式碼變更(具體程式碼可以檢視我的GitHub或者你也可以參看我的視訊《ABP vNext框架實戰系列》)，Domain的演化也只是做程式碼簡單遷移，整個重構過程並沒有做多大的變化。這就是所謂“持續提升程式設計師幸福指數"的模組化之道啊。

總結

　　ABP vNext的模組化思想給了微服務演化提供了底層能力，我在這兒只是拋磚引玉，希望有更多的人能參與進來進行分享。如果你想了解更多ABP vNext的地方，你也可以參看我的另外一篇文字《淺談Abp vNext的模組化設計》，謝謝您的捧場。

　　Abp vNext是一款優秀的框架，但是要從零開始能把每個角落都熟悉起來需要不少摸索時間，希望通過自己的經驗給你的快速學習賦能，拋開生成器，一起從零開始，手工打磨一款生產級別的框架，讓你對AbpvNext知其然，知其所以然。

&n