我在2019年中國.NET開發者峰會上為大家分享了我們的微服務電商安全工程實踐，那次會議分享的高清錄播已經上傳到我的騰訊課堂，大家可以通過底部的小程序打開直接觀看（復習）。

在大會上跟大家提到，我們當時只有4個人的創業團隊。追求的是一個既可以單體部署，又可以進行分布式部署的架構方式。我們需要同時滿足云上SaaS部署（流量偏大）和私有部署（流量小，看重服務器成本）。當然這種架構方式我們也是經過好幾次的框架迭代才實現的，框架暫時沒有開源的打算，但是現在利用ABP VNext的幾個核心組件已經完全可以方便的實現業務拼接組裝，同時實現單體和分布式部署。今天我將這種架構風格推薦給所有中小企業。

微服務架構再理解

組織結構的重要性?

人們在談到微服務的時候必須會提到康威定律：“Communication dictates design（組織溝通方式決定系統設計）”如果大家想更詳細的了解一下這個定律可以自己百度一下。但也許因為它是定律，所以大家總把它說的很玄乎，導致我們一下子很難真正理解到它的精髓。當然這很大的原因其實在于我們從技術的角度出發是不能理解組織結構對企業效率的重要性

微軟的現任CEO 薩蒂亞·納德拉，執掌微軟的第一件事情就是對組織結構的調整。在下面的圖中你可以看到以前大家是如何看待微軟的組織結構的, 騰訊這兩年動不動就做事業部的調整也是出于這個考量?

任何的組織架構之所有存在必然有其特殊性， 蘋果的絕對中心化那個時候能成功是因為中心是喬布斯，現在中心靈魂人物沒有了，這種組織結構還適用嗎？

既然在微服務架構中"康威定律"被如此廣泛的引用，我就用大白話給大家解釋一下：“如果你是一個團隊在一起維護好幾十個服務，那你們就沒有必要用微服務架構。”

一個服務一個團隊

請大家記住上面的這個鐵律，如果是整個團隊維護很多微服務，哪怕是要用這些微服務拼成多個產品，那也不是微服務的最佳實踐。微服務強調：一個服務一個完整團隊(這個團隊中包括產品開發和測試) 。

微服務按DDD中的界限上下文來進行拆分之后, 每一個服務都可以為這個領域業務的客戶提供最小化服務,直到業務做到足夠復雜,某些業務長大成為另一個獨立的上下文。這也完全符合敏捷和精益創業的思路。

充分授權小團隊

一個服務一個團隊還不能完全發揮這種架構的威力，這個團隊需要充分的授權。任正非說：“讓聽得見炮火的人指揮戰斗”就是這個原因。大部分情況下直接和客戶打交道的前線最了解實際情況，知道客戶要什么以及如何去改進產品。微服務架構將組織結構拆分之后，每個團隊都可以集中力量解決自己團隊所在領域內客戶最關心的問題，快速做也改進，快速發布將改進送到客戶面前拿到正確的反饋。所以“每個服務獨立部署，獨立交付” 如此重要。?

中小企業不建議采用微服務架構

資源不夠，最嚴重緊缺的就是產品經理。沒有人去正確、快速地從用戶那里拿到反饋來快速改進產品。最壞的情況可能用更快的速度堆了更多不需要也不那么正確的“功能” 。?

資源不夠，即使我們使用k8s降低和解除了很多運維的功能，依舊還有配置中心、分布式追蹤、和集中日志的問題解決的不是很好。這是一個很“重”的話題。?

資源不夠，這是一個永恒的話題， 孫子兵法以及很多戰略思想中都提到要集中兵力，中小企業的資源只夠集中優勢資源優先解決關鍵問題，企圖想要快速把所有問題都解決到最后基本都是失敗。?

利用模塊化打造單體與分布式都適用的架構

中小企業愿意去深度微服務架構的兩個初衷：

• 希望最大化避免重復開發，降低開發成本?

• 防止將來業務做大要整體重構

但是實施微服務框架會給企業帶來比較高的運維成本，即使在使用K8S的情況下依然會比單體的運維成本要高出很多。并且如果是屬于客戶訂制化項目需要部署到客戶現場，維護費用會更高。

業務模塊化可以讓團隊把特定的業務封裝在一個模塊內，由多個業務模塊組裝完成一個系統 。比如我們常見的租戶、用戶、商品、論壇、博客、訂單、客戶等等。

業務模塊化如果部署成分布式那就是微服務架構，需要面對同樣的挑戰。如果部署成單體那將可以收獲以下好處

• 服務器成本更低?

• 不需要考慮服務治理（比如：服務發現與注冊、分布式追蹤等）

• 不需要考慮分布式配置中心

當然，由于我們同時需要考慮兼容分布式部署。所以以下問題還是一樣的

• 由于數據庫按模塊獨立，數據一致性依舊是一個挑戰（實在不得已集中提供一些面向報表庫的查詢服務也是可以接受的）?

• 不允許跨模塊join數據查詢，所以復雜數據報表展示也同樣需要找到相應的解決辦法

模塊拆分原則

• 微服務拆分的大部份原則依舊適用

• 一個業務模塊對應一個數據庫，不能直接查另一個業務模塊的數據庫

• 模塊之間的調用通過抽象契約接口來完成?

• 模塊之間互相依賴只能依賴于抽象契約

模塊項目模板?

abp默認的項目模板中將DDD也引入進來，但是由于應用DDD對大多數開發者來說依舊是一個問題。所以我推薦的項目模板中沒有引入DDD領域實體和領域服務的概念。也比較簡單，只包括兩層：

• ModuleName.Contracts 契約層

• Module 實現層?

契約層

契約層中主要包括ApplicationService接口和DTO。

實現層

實現層主要是ApplicationServer的實現以及數據庫的Entity。如果你對DDD有一定的理解的話可以把這里理解為失血模型的領域分層 。在ApplicationService中通過倉儲IRepository來完成領域實體Entity的持久化操作。需要注意的是這里不是簡單的BLL和DAL三層架構的思路，而是DDD領域分層中的六邊形架構。

你可以在我的github上找到demo源碼：https://github.com/jessetalk/Galaxy (請一定要切換到abp分支，master分支是grpc的demo)?

模塊間調用/通信?

遵循“依賴于接口而不依賴于實現”原則。業務模塊化之后，各個模塊之間的通信通過契約接口來完成。

在我們的場景中，OrderService在創建訂單時需要使用到IProductService的查詢接口，那么Galaxy.Order項目需要添加Galaxy.Product.Contacts的引用。

private IProductService productService { get; set; } public OrderService(IProductService productService) {this.productService = productService; } public async Task<OrderDto> GetAsync(string id) {var items = await this.productService.GetListAsync(new ProductQueryDto());var?task?=?await?Task.Run(()?=>????????????????????????{Thread.Sleep(100);return?new?OrderDto()?{?Id?=?id,?OrderNo?=?"1234",?ProductItems?=?items?};});return task; }

單體部署?

單獨創建一個Api項目，通過nuget引用所有業務模塊包。通過對外暴露模塊內的ApplicationService來實現后端的業務處理。

各個模塊之間由于注入的都是本地類，所以模塊之間的調用也會是本地方法調用。

分布式部署

在分布式部署的場景下，需要為每一個業務模塊建立一個對應的api項目，并將對應的業務模塊實現包引入到項目。我們在上面的模塊間通信上講到了具體模塊之間的調用是通過抽象接口來完成的，所以在分布式部署的情況下需要注入一個遠程代理來替代原來的本地調用。?

比如我們可以實現一個ProductServiceProxy，并將它注入到OrderService中。但如果是這樣，我們需要為每一個業務模塊都實現一個Proxy模塊。好消息是ABP VNext為我們實現了動態客戶客戶端代理。

關鍵點

ABP 動態客戶端代理

ABP提供的動態客戶端代理功能，可以讓我們只需要添加一行代碼即擁有通過 http實現遠程模塊調用的功能 。?

[DependsOn(typeof(AbpAspNetCoreMvcModule))] [DependsOn(typeof(AbpAutofacModule), typeof(GalaxyOrderModule))] public class GalaxyOrderWebModule : AbpModule {public override void ConfigureServices(ServiceConfigurationContext context){//創建動態客戶端代理context.Services.AddHttpClientProxies(typeof(GalaxyProductContractModule).Assembly, remoteServiceConfigurationName: "ProductStore");} }

ABP框架按約定式的方式默認注冊服務實例，所以如果項目添加了對Galaxy.Product模塊的依賴則ProductService會自動成為IProductService的實現（即本地方法調用）。? 如果在模塊配置手動添加了HttpClientProxies則會自動為IProductService添加一個動態的實現(采用http的方式調用遠程服務）。

關于如何配置遠程服務的地址可以參考abp官方文檔(abp.io)。?

ABP動態Controller?

大量使用業務模塊化的時候，單體的情況下所有的Controller都在單體的那個api項目中，如果我們要轉成微服務的方式部署則需要把原來在單體中的Controller都轉移到對應的微服務api項目中。如果要同時在這兩種架構下切換則每添加一個Action都需要在兩個地方都做對應的調整 。

ABP提供的動態Controller功能，支持通過ApplicationService直接暴露成API Controller。這樣我們就可以只寫業務的契約接口和本地的實現， 在對應的API項目中只需要引用對應業務模塊的nuget包即可。

我們只需要在order api項目的web module中將對應業務模塊添加到 ConventionalControllers即可。

[DependsOn(typeof(AbpAspNetCoreMvcModule))] [DependsOn(typeof(AbpAutofacModule), typeof(GalaxyOrderModule))] public class GalaxyOrderWebModule : AbpModule {public override void ConfigureServices(ServiceConfigurationContext context){Configure<AbpAspNetCoreMvcOptions>(options => {options.ConventionalControllers.Create(typeof(GalaxyOrderModule).Assembly);});} }

ABP會將ApplicationService中的所有公有方法按照約定自動生成Action，具體的生成規則可以參考abp相關的文檔。當然你也可以在方法上加Route或者HttpVerb的標簽來定制路由。

?

以上是我們在Order的API項目中，只需要把Order相關的實現暴露為Web API。如果想通過一個API項目把所有的業務模塊都通過web api 暴露出來，也只需要多添加一行代碼。

public class GalaxyWebModule : AbpModule {public override void ConfigureServices(ServiceConfigurationContext context){Configure<AbpAspNetCoreMvcOptions>(options =>{options.ConventionalControllers.Create(typeof(GalaxyOrderModule).Assembly);options.ConventionalControllers.Create(typeof(GalaxyProductModule).Assembly);});} }

由此在Swagger文檔中即可以看到Product和Order兩個模塊的Web API。

也就是通過這種方式，我們只需要開發相關的業務模塊然后通過動態Controller的方式來靈活控制是進行單體部署還是分布式部署。也許你已經發現了，這種情況下我們沒有Controller層，也就意味著我們所有的邏輯都需要寫在ApplicationService層，包括驗證等。

結尾

在這種架構風格下，你可以很靈活的決定系統的部署方式。?既沒有必要被技術捆綁，也可以進行最大化的復用同時免除未來業務快速增長的后顧之憂。

由于篇幅有限，如果有描述不清或者疑問的地方歡迎給我留言。希望這些實踐能給廣大中小企業的研發團隊一些啟發。?我將繼續關注中小企業信息化以及產品研發中的技術架構、團隊管理、運維等領域。如果你有相關的問題或者新思路，歡迎溝通?:)?

這是關于中小企業產品研發體系建設的第二篇，你也可以查看我的上一篇《中小企業團隊敏捷產品開發流程最佳實踐》

我已將去年2019年中國.NET開發者峰會上為大家的分享上傳到我的騰訊課堂，以及之前為大家錄制的《ASP.NET Core核心模塊》 以及《.Net Core ON K8S快速入門》 兩個系列都可以免費加入。?

總結

以上是生活随笔為你收集整理的业务模块化打造单体和分布式部署同步支持方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。