.NET微服務架構及API網關_ZenDei技術網路在線

一、MSA簡介 1.1、MSA是什麼微服務架構MSA是Microservice Architecture的簡稱，它是一種架構模式，它提倡將單一應用程式劃分成一組小的服務，服務之間互相通訊、互相配合，為用戶提供最終價值。它與SOA之間的區別如下： SOA實現微服務架構實現企業級，自頂向下開展實施 ...

一、MSA簡介

1.1、MSA是什麼

微服務架構MSA是Microservice Architecture的簡稱，它是一種架構模式，它提倡將單一應用程式劃分成一組小的服務，服務之間互相通訊、互相配合，為用戶提供最終價值。它與SOA之間的區別如下：

SOA實現	微服務架構實現
企業級，自頂向下開展實施	團隊級，自底向上開展實施
粒度大：服務由多個子系統組成	粒度細：一個系統被拆分成多個服務，且服務的定義更加清晰
重ESB：企業服務匯流排，集中式的服務架構	輕網關：無集中式匯流排，鬆散的服務架構
開發過程複雜	易開發：減少了企業ESB開發的複雜性，與敏捷開發的思想高度結合在一起
單塊架構系統，相互依賴，部署複雜	服務能被獨立部署

1.2、我們的MSA框架

我們的微服務框架MsaFx.dll是個基於ServiceStack 4.0.60包裝實現的.NET Web Services框架，而ServiceStack本身支持通用的輕量級協議和Metadata。MsaFx與普通Web Services框架如WCF相比，主要優勢如下： 1、 高性能：性能好、速度快。 2、 支持跨平臺運行：基於MsaFx開發出的Web Services既能夠運行在Windows環境中，又能夠運行在支持Mono的Linux環境中。 3、 支持多協議：如JSON格式的也支持XSD。 4、 更加Web化：RESTful。 5、 服務端實現與客戶端實現的完全解耦：MSA基於消息的設計，使得服務端的API改變並不會破壞現有的客戶端，達到服務端實現與客戶端實現完全解耦的目的。 6、 MSA API可視化說明文檔便於你調試。 7、 易學：使用MSA進行開發和維護服務所需的技術和時間投入要小很多。 8、 易用：簡化了REST以及WCF SOAP風格的Web Services的開發過程。

1.3、MSA框架實現架構

MSA服務端的架構請見下圖的第一張圖，MSA的HTTP客戶端架構請見下圖的第二張圖。MSA的內部是建立在原生的ASP.NET IHttpHandler之上實現的，支持JSON、XML、JSV、HTML、Message Pack、ProtoBuf、CSV等消息格式。

MSA服務端的架構

MSA HTTP Client的架構

二、MSA框架的使用

1、服務托管

服務端的服務對外提供服務前，必須先要把服務端給托管起來。MSA提供了通過IIS、Self-Host等多種形式把服務端給托管起來，宿主環境可以是控制台應用或Windows Service或ASP.NET Web應用或ASP.NET MVC應用。提供的MSA Demo的宿主環境用的是ASP.NET Web應用。

2、路由

A、MSA自身提供的預設路由是：/[xml|json|html|jsv|csv]/[reply|oneway]/[Request DTO名] [(?query參數1={值}&query參數2={值}&......&query參數n={值})]。 B、創建自定義路由，其創建方法是：使用RouteAttribute或在宿主環境中配置。提供的MSA Demo採用的是在宿主環境中配置路由這種方式來創建自定義路由。

3、如何驗證請求參數的合法性

如果你需要在提交請求參數前，驗證請求參數是否必填或是否合法，那麼驗證邏輯必須寫在繼承自MSA的AbstractValidator<TRequest>的類里（參考例子請見MSA Demo的OrderValidator.cs），然後在宿主環境中進行開啟驗證的配置：

1 Plugins.Add(new ValidationFeature()); 
2 container.RegisterValidator(typeof(OrderValidator));

4、服務

創建MSA服務時，必須繼承來自MSA的Service類。

5、MSA內置的客戶端

5.1、MSA內置了一些便捷訪問的客戶端，這些對象都實現了IServiceClient介面，其中支持REST的客戶端還都實現了IRestClient介面。這些客戶端對象包括：JsonServiceClient、JsvServiceClient、XmlServiceClient、MsgPackServiceClient、ProtoBufServiceClient、Soap11ServiceClient、Soap12ServiceClient等。從名稱可以看出，這幾種不同之處在於支持的序列化和反序列化格式不同。因為它們實現的是相同的介面，所以它們的用法相同，也可以相互替換。 MSA Demo中用到了JsonServiceClient和ProtoBufServiceClient這兩種客戶端，其中當用到ProtoBufServiceClient客戶端時，你還需要完成如下工作： a、除了需要引用MSA.dll外，還需要引用protobuf-net.dll。 b、需要在宿主環境中進行如下配置：

1 Plugins.Add(new ProtoBufFormat());

c、必須分別給Request DTO對象和Response DTO對象的各屬性標上[DataMember(Order = {0})]特性，具體寫法請見MSA Demo的ProductRequestDTO.cs和ProductResponseDTO.cs。

5.2、MSA內置的客戶端提供Get、Send、Post、Put、Delete等方法。查詢數據一般用Get方法，新增操作一般用Post方法，更新操作一般用Put方法，刪除操作一般用Delete方法。這些方法都有重載。 以下是Get方法的其中一個簽名：

1 TResponse Get<TResponse>(IReturn<TResponse> requestDto);

6、MSA API可視化說明文檔自動生成的實現

在宿主環境中加如下配置：

1 Plugins.Add(new SwaggerFeature());

如果需要在MSA API可視化說明文檔中能夠看到各請求參數、響應的含義說明，那麼需要為Request DTO、Response DTO對象的各屬性標上ApiMember，代碼參考如下：

 1 public class OrderRequest : IReturn<OrderResponse>
 2 {
 3    [ApiMember(Name = "Id", Description = "訂單ID號", IsRequired = false)]
 4    public int Id { get; set; }
 5    [ApiMember(Name = "CustomerName", Description = "客戶名", IsRequired = false)]
 6    public string CustomerName { get; set; }
 7    //......
 8    [ApiMember(Name = "OrderItemList", Description = "訂購的產品列表", IsRequired = false)]
 9    public List<OrderItem> OrderItemList { get; set; }
10 }

運行結果如下圖所示：

在MSA API可視化說明文檔中顯示各請求參數、響應的含義說明

7、運行結果

先運行托管應用（如MSA Demo中ServiceHost項目），出現下圖所示的Metadata頁。然後再運行客戶端來調用微服務；也可通過瀏覽器查看數據，網址輸入格式如： http://localhost:34833/orders/1.html?CustomerName=客戶_1&IsTakeAway=true&StatusCode=1&CreatedDate=2017-08-21 10:58:48.230，或： http://localhost:34833/html/reply/GetOrderRequest?Id=1&CustomerName=客戶_1&IsTakeAway=true&StatusCode=1&CreatedDate=2017-08-21 10:58:48.230，其中，第1個網址格式規則就是MSA Demo中在宿主環境中所配的自定義路由規則，第2個網址格式規則就是由MSA提供的預設路由規則。單擊下圖所示Metadata頁中的【MSA API UI】後，進入下圖所示的MSA API可視化說明文檔界面，開發人員可以通過這份由MSA自動生成的說明文檔進行調試，十分方便。

Metadata頁

MSA API可視化說明文檔界面

三、微服務治理

在我們自主開發的框架管理系統中，進行介面註冊，請見下圖。其中，規定內部服務訪問名的命名規範是：/{***Service}/方法名，如/OrderService/CreateOrder；規定外部服務訪問名OpenApiName的命名規範是：{各產品線的縮寫英文名}方法名，如FltCreateOrder，其中Flt表示國內機票業務的縮寫英文名。

MSA介面註冊頁

四、微服務網關API Gateway

4.1、API Gateway的簡介

API Gateway風格的核心理念是使用一個輕量級的消息網關作為所有客戶端的主入口，並且在 API Gateway層面上實現通用的非功能性需求。如下圖所示：所有的服務通過API 網關來暴露，這是所有客戶端訪問的唯一入口；如果一個服務要訪問另一個服務，也要通過這個網關。

所有服務通過一個API網關來暴露 一旦API網關允許客戶端消費一個受管理的API，那麼我們就可以以受管理的API形式使用它來暴露這個微服務所實現的業務邏輯。API網關以NIO、IOCP來連接內部受管理的API，以實現API網關的高併發。

4.2、API Gateway的優點

網路隔離：微服務部署在了內網，通過API Gateway開放給PartnerAPI、WebAPI或MobileAPI。

在網關層面的輕量級消息路由和轉換。

在網關層面對存在的微服務提供必要的抽象。例如，網關可以選擇對不同的用戶暴露不同的API。

一個中心的地方提供非功能性的能力，這些能力可復用，比如超時、限流、熔斷、監控、日誌記錄等。

通過適用API網關模式，微服務可以變得更加輕量，因為非功能性需求都在網關上實現了。

統一安全管控。

4.3、API Gateway的架構

4.4、API Gateway的功能

API Gateway主要實現以下功能： 1、路由映射：外部服務訪問名映射到對應的內部服務訪問名。 2、許可權驗證：包括針對客戶角色的訪問授權驗證、針對客戶的訪問授權驗證、IP黑名單驗證。 3、超時處理：當API網關調用的內部服務響應時間超過了在自主開發的API網關後臺管理子系統中所設置的允許最長的超時時間時，API網關會立即停止調用，並返回相關消息給你。 4、限流控制：當你通過API網關調用內部服務的頻率達到在某個閾值時，API網關會立即做斷開鏈路處理。過了時間後，鏈路會自動閉合回去。 5、熔斷處理：熔斷處理對避免無謂的資源消耗特別有用，當通過API網關調用的內部服務出現異常的頻率達到某個閾值時，那麼API網關會做臨時熔斷處理即臨時斷開鏈路，暫時停止你對那個內部服務的調用。臨時熔斷後，過了一段時間後，鏈路會自動閉合回去。 6、日誌信息記錄：會記錄客戶IP、客戶請求參數、返回結果、異常信息等信息。

4.5、API Gateway的使用

在使用API Gateway之前，需要先配置網關參數。網關參數的配置是在自主開發的API網關後臺管理子系統中進行：

在自主開發的API網關後臺管理子系統中配置網關參數

五、Demo下載及更多資料

MSADemo下載地址：https://github.com/das2017/MSADemo

APIGatewayDemo下載地址：https://github.com/das2017/ApiGatewayDemo

ServiceStack官網：https://servicestack.net/

.NET微服務架構及API網關