ABP VNext框架如果不考慮在微服務上的應用，也就是開發單體應用解決方案，雖然也是模組化開發，但其整合使用的難度會降低一個層級。 ABP VNext 框架引入微服務後，就需要使用API閘道器來，ABP框架可以使用Ocelot來做閘道器統一處理上游的HTTP請求，並在內部網路上使用內部閘道器，處理微服務之間的呼叫，從而把微服務的呼叫介面統一為一個固定的模式處理。本篇隨筆介紹一下閘道器的基本知識，以及ABP VNext 框在引入Ocelot來做閘道器後的架構圖場景，介紹一下ABP VNext 微服務的案例的基本情況。

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微服務架構

eShopOnContainer是基於Docker技術微服務架構demo，由微軟架構師利用.net core技術實現並在github上開源，同時釋出的還有關於微服務架構的白皮書(點這裡)，微服務架構是一個比較新的架構模式，通讀白皮書並結合該demo程式碼，可以做到按圖索驥的作用，對理解.net core技術實現微服務架構可以做到事半功倍。

在Github中的微軟eShopOnContainer 專案地址：https://github.com/dotnet-architecture/eShopOnContainers

eShopOnContainer 的開發架構示意圖如下所示。

包含閘道器的架構架構圖如下圖所示，其中包含多個閘道器服務處理客戶端的請求。

4、微服務的模組拆分

微服務根據功能或者應用場景進行拆分，如把一個大型複雜的系統應用，拆分為多個微服務應用模組，然後進行整合使用。

或者按下面界限上下文進行劃分

不過微服務也不是拆分的越細越好，一般根據實際情況進行度量，引入微服務雖然能夠解決一些技術上和效能上的問題，不過拆分過多可能會導致開發和維護上災難。

主要研究技術：程式碼生成工具、會員管理系統、客戶關係管理軟體、病人資料管理軟體、Visio二次開發、酒店管理系統、倉庫管理系統等共享軟體開發
專注於Winform開發框架/混合式開發框架、Web開發框架、Bootstrap開發框架、微信門戶開發框架的研究及應用。
  轉載請註明出處：
撰寫人：伍華聰  http://www.iqidi.com