.NET微服務架構及API網關 原文:.NET微服務架構及API網關

一、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形式使用它來暴露這個微服務所實現的業務邏輯。A posted on 2019-02-13 14:57 NET未來之路 閱讀(...) 評論(...) 編輯 收藏

轉載于:https://www.cnblogs.com/lonelyxmas/p/10369868.html

總結

以上是生活随笔為你收集整理的.NET微服务架构及API网关的全部內容，希望文章能夠幫你解決所遇到的問題。

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