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

張飛洪[廈門]發表於2020-12-28

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

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

  

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

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

為什麼不用微服務架構?

微服務痛點
  • 資料一致性分發
  • 資料聚合 Join
  • 分散式事務
  • 單體系統解耦拆分
什麼時候開始用微服務

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

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

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

      

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

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

微服務相容的單體架構

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

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

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

總結

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

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

 

相關文章