中小型研發團隊架構實踐三：微服務架構（MSA）

1、MSA 簡介

     1.一、MSA 是什麼

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

    

     1.二、咱們的 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.三、MSA 框架實現架構

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

    

                                                  MSA 服務端的架構

    

                                             MSA HTTP Client 的架構

2、MSA 框架的使用

     一、服務託管

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

     二、 路由

          A、MSA 自身提供的默認路由是：

/[xml|json|html|jsv|csv]/[reply|oneway]/[Request DTO 名] [(?query 參數 1={值}&query 參數 2={值}&......&query 參數 n={值})]。

          B、建立自定義路由，其建立方法是：使用 RouteAttribute 或在宿主環境中配置。提供的 MSA Demo 採用的是在宿主環境中配置路由這種方式來建立自定義路由。

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

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

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

     四、服務

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

     五、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、須要在宿主環境中進行以下配置：

                    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 方法的其中一個簽名：

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

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

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

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 可視化說明文檔中顯示各請求參數、響應的含義說明

     七、運行結果

     先運行託管應用（如 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 可視化說明文檔界面

3、微服務治理

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

    

                                                  MSA 接口註冊頁

4、微服務網關 API Gateway

     4.一、API Gateway 的簡介

     API Gateway 風格的核心理念是使用一個輕量級的消息網關做爲全部客戶端的主入口，而且在 API Gateway 層面上實現通用的非功能性需求。以下圖所示：全部的服務經過 API 網關來暴露，這是全部客戶端訪問的惟一入口；若是一個服務要訪問另外一個服務，也要經過這個網關。

    

                                        全部服務經過一個 API 網關來暴露

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

     4.二、API Gateway 的優勢

    

• 網絡隔離：微服務部署在了內網，經過 API Gateway 開放給 PartnerAPI、WebAPI 或 MobileAPI。
• 在網關層面的輕量級消息路由和轉換。
• 在網關層面對存在的微服務提供必要的抽象。例如，網關能夠選擇對不一樣的用戶暴露不一樣的 API。
• 一箇中心的地方提供非功能性的能力，這些能力可複用， 好比超時、限流、熔斷、監控、日誌記錄等。
• 經過適用 API 網關模式，微服務能夠變得更加輕量，由於非功能性需求都在網關上實現了。
• 統一安全管控。

     4.三、API Gateway 的架構

    

     4.四、API Gateway 的功能

     API Gateway 主要實現如下功能：

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

     4.五、API Gateway 的使用

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

    

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

5、Demo 下載及更多資料

• MSADemo 下載地址：https://github.com/das2017/MSADemo
• APIGatewayDemo 下載地址：https://github.com/das2017/ApiGatewayDemo
• ServiceStack 官網：https://servicestack.net/

 

文章轉載自：http://www.infoq.com/cn/articles/architecture-practice-06-microservice-architect?utm_source=infoq&utm_campaign=user_page&utm_medium=link