ABP VNext框架如果不考慮在微服務上的應用，也就是開發單體應用解決方案，雖然也是模塊化開發，但其集成使用的難度會降低一個層級，不過ABP VNext和ABP框架一樣，基礎內容都會設計很多內容，如數據庫都支持Oracle、SQLServer、MySql、PostgreSQL、SQLite，都有利用Redis作為分布式緩存，使用RabbitMQ作為事件總線的消息處理方式，使用MongoDB的NoSQL類型數據庫作為特殊數據的存儲服務，使用Quartz/HangFire作為定時任務的處理等。如果考慮引入微服務的話，會更需要了解IdentityServer服務，以及了解Ocelot庫管理網關，使用 Elasticsearch & Kibana 來存儲和可視化日志 (使用Serilog寫日志)，有時候感覺引入框架並非一件輕松的事情，各種知識點一股腦的涌來。
"作為面向服務架構(SOA)的一個變體,微服務是一種將應用程序分解成松散耦合服務的新型架構風格. 通過細粒度的服務和輕量級的協議,微服務提供了更多的模塊化,使應用程序更容易理解,開發,測試,並且更容易抵抗架構侵蝕. 它使小型團隊能夠開發,部署和擴展各自的服務,實現開發的並行化.它還允許通過連續重構形成單個服務的架構. 基於微服務架構可以實現持續交付和部署."
ABP VNext 框架引入微服務后，就需要使用API網關來，ABP框架可以使用Ocelot來做網關統一處理上游的HTTP請求，並在內部網絡上使用內部網關，處理微服務之間的調用，從而把微服務的調用接口統一為一個固定的模式處理。本篇隨筆介紹一下網關的基本智知識，以及ABP VNext 框在引入Ocelot來做網關后的架構圖場景，介紹一下ABP VNext 微服務的案例的基本情況。
1、網關和認證服務的介紹
API網關是系統暴露在外部的一個訪問入口。就像一個公司的門衛承擔着尋址、限制進入、安全檢查、位置引導、等等功能。從面向對象設計的角度看，它與外觀模式類似。API網關封裝了系統內部架構，為每個客戶端提供一個定制的API。它可能還具有其它職責，如身份驗證、監控、負載均衡、緩存、請求分片與管理、靜態響應處理等等。
API網關方式的核心要點是，所有的客戶端和消費端都通過統一的網關接入微服務，在網關層處理所有的非業務功能。通常，網關也是提供REST/HTTP的訪問API。
Ocelot是一個用.NET Core技術實現並且開源的API網關技術，它的功能包括了：路由、請求聚合、服務發現、認證、鑒權、限流熔斷、並內置了負載均衡器、Service Fabric、Butterfly Tracing等的集成。而且這些功能都只需要簡單的配置即可完成。
Ocelot首先通過配置將HttpRequest對象保存到一個指定的狀態直到它到達用來創建HttpRequestMessage對象並將創建的HttpRequestMessage對象發送到下游服務中的請求構造中間件。通過中間件來發出請求是Ocelot管道中做的最后一件事。它不會再調用下一個中間件。下游服務的響應會存儲在每個請求 scoped repository中，並作為一個請求返回到Ocelot管道中。有一個中間件將HttpResponseMessage映射到HttpResponse對象並返回給客戶端。
單網關服務示意圖如下所示。
API 網關一般放到微服務的最前端，並且要讓API 網關變成由應用所發起的每個請求的入口。這樣就可以明顯的簡化客戶端實現和微服務應用程序之間的溝通方式。
上游和下游描述消息流：所有 消息從上游流動到下游。
網關作為上游會接收所有的客戶端請求，並路由到對應的下游服務器進行處理，再將請求結果返回。而這個上下游請求的對應關系也被稱之為路由。
我們的下游服務接口都是公開的，沒有經過任何的認證，只要知道接口的調用方法，任何人都可以隨意調用，因此，很容易就造成信息泄露或者服務被攻擊。
正如，我要找Wlling干活之前，我得先到 HR 部門那里登記並且拿到屬於我自己的工卡，然后我帶着我的工卡去找Wlling，亮出我是公司員工的身份，並且有權利要求他幫我完成一個任務。
IdentityServer4認證服務器有多種認證模式，包括用戶密碼、客戶端等等。客戶端需要先想IdentityServer4 請求認證，獲得一個token，然后再帶着這個token向下游服務發出請求。
ApiResources 為數組類型，表示identityserver管理的所有的下游服務列表。
- Name: 下游服務名稱
- DisplayName: 下游服務別名
Clients為數組類型，表示identityserver管理的所有的上游客戶端列表
- ClientId: 客戶端id
- ClientSecret: 客戶端對應的密鑰
- GrantType: 該客戶端支持的認證模式
- Scope: 該客戶端支持訪問的下游服務列表，必須是在
apiresources列表中登記的
當接入ocelot網關時，我們要達到內外互隔的特性，於是就把identityserver服務也托管到ocelot網關中，這樣我們就能統一認證和服務請求時的入口。
如ABP案例中的微服務網關【PublicWebSiteGateway.Host】項目中的配置內容，配置服務器上下游的信息如下所示。
"Routes": [ { "DownstreamPathTemplate": "/api/productManagement/{everything}", "DownstreamScheme": "https", "DownstreamHostAndPorts": [ { "Host": "localhost", "Port": 44344 } ], "UpstreamPathTemplate": "/api/productManagement/{everything}", "UpstreamHttpMethod": [ "Put", "Delete", "Get", "Post" ] }, { "DownstreamPathTemplate": "/api/blogging/{everything}", "DownstreamScheme": "https", "DownstreamHostAndPorts": [ { "Host": "localhost", "Port": 44357 } ], "UpstreamPathTemplate": "/api/blogging/{everything}", "UpstreamHttpMethod": [ "Put", "Delete", "Get", "Post" ] } ], "GlobalConfiguration": { "BaseUrl": "https://localhost:44397" },
多網關服務示意圖如下所示，這種模式是針對不同的客戶端來實現一個不同的API網關。
ABP VNext 框架里面也采用了多網關的應用，其微服務的整體架構圖如下所示。
其中網關包含了后台管理應用網關【BackendAdminAppGateway.Host】，以及公開的應用接入網關【PublicWebSiteGateway.Host】，而內部網關服務【InternalGateway.Host】，則是用於內部微服務之間調用的統一網關解析。
ABP VNext框架中的微服務，有各個模塊的微服務組成一個集合，一起為各個應用提供不同的數據處理服務。
2、ABP VNext項目的微服務項目
前面說到，ABP VNext 框架里面也采用了多網關的應用，其中網關包含了后台管理應用網關【BackendAdminAppGateway.Host】，以及公開的應用接入網關【PublicWebSiteGateway.Host】，而內部網關服務【InternalGateway.Host】，則是用於內部微服務之間調用的統一網關解析。
ABP VNext的微服務項目如下所示。
生成的數據庫包含兩個部分，其中基礎數據庫包含IdentityServer4所需的基礎表，以及用戶、角色、租戶、日志、組織機構、權限等權限模塊的基礎表；另外一個部分就是業務模塊的數據庫了，如下所示。
我們通過AuthServer.Host和ProductService.Host項目，初始化相關的數據庫。
最后獲得兩個初始數據庫，包含基礎的表信息。
之前隨筆也提到過，雖然ABP VNext的官方提供了構建權限系統的相關表信息，但是組織機構、用戶、角色業務表和中間表的管理沒有在其對應的Identity項目中提供，官方提供的Identity項目如下所示。
這部分完善的應用接口及管理，他們是在ABP VNext商業版中進行開發並提供的，因此我們開發具體的應用所需的權限基礎內容，需要自己進行項目模塊的擴展，然后完善組織機構、角色、用戶、菜單、日志（審計日志、對象修改日志）、權限點的管理和維護等內容。
3、微軟的eShopOnContainer微服務架構
在Github中的微軟eShopOnContainer 項目地址：https://github.com/dotnet-architecture/eShopOnContainers
eShopOnContainer 的開發架構示意圖如下所示。
包含網關的架構架構圖如下圖所示，其中包含多個網關服務處理客戶端的請求。
4、微服務的模塊拆分
微服務根據功能或者應用場景進行拆分，如把一個大型復雜的系統應用，拆分為多個微服務應用模塊，然后進行整合使用。
或者按下面界限上下文進行划分
不過微服務也不是拆分的越細越好，一般根據實際情況進行度量，引入微服務雖然能夠解決一些技術上和性能上的問題，不過拆分過多可能會導致開發和維護上災難。