持續提高程序員幸福指數——使用abp vnext設計一款面向微服務的單體架構

可能你會面臨這樣一種狀況，在架構設計以前，你對業務不甚瞭解，需求給到的也模棱兩可，這個時候你既沒法明確究竟是要使用單體架構仍是使用微服務架構，若是使用單體，後續業務擴展可能帶來大量修改，若是使用微服務，前期可能在工期上把項目給耽誤了，你該怎麼辦？這就是這篇文章想要研討的面向微服務的單體架構的由來。

爲何不用傳統單體架構？

  

  

　　咱們能夠看到隨着業務的升級，單塊的代碼的拆分會變得愈來愈困難，若是在前期沒有作好規劃和伏筆，那麼後續的演化就是一場災難。因此，目前的設計若是是企業級別的，都必然要作架構的適當冗餘，由於沒有人能知道將來長什麼樣，架構必然和業務同樣是隨着綜合因素慢慢長出來的，不可能一蹴而就，一步到位。

爲何不用微服務架構？

微服務痛點

• 數據一致性分發
• 數據聚合 Join
• 分佈式事務
• 單體系統解耦拆分

何時開始用微服務

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

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

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

      

　　「交叉點代表，業務已經到達了必定的複雜性，單塊應用已經沒法知足業務增加的須要，研發效率開始降低了，而微服務能夠提高研發和交付的效率。這個點須要架構師去綜合、權衡。我的經驗，通常團隊須要達到百人規模，纔去考慮微服務。」

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

微服務兼容的單體架構

演化方便——低代碼演化

　　如上所示，咱們能夠看到API在拆解過程當中，基本沒有作任何代碼變動(具體代碼能夠查看個人GitHub或者你也能夠參看個人視頻《ABP vNext框架實戰系列》)，Domain的演化也只是作代碼簡單遷移，整個重構過程並無作多大的變化。這就是所謂「持續提高程序員幸福指數"的模塊化之道啊。

總結

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

　　Abp vNext是一款優秀的框架，可是要從零開始能把每一個角落都熟悉起來須要很多摸索時間，但願經過本身的經驗給你的快速學習賦能，拋開生成器，一塊兒從零開始，手工打磨一款生產級別的框架，讓你對AbpvNext知其然，知其因此然。