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

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

一、MSA 簡介

1.1、MSA 是什麼

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

1.2、我們的 MSA 框架

我們的微服務框架 MsaFx.dll 是個基於 ServiceStack 4.0.60 包裝實現的.NET Web Services 框架，而 ServiceStack 本身支持通用的輕量級協議和 Metadata。MsaFx 與普通 Web Services 框架如 WCF 相比，主要優勢如下：

高性能：性能好、速度快。
支持跨平臺運行：基於 MsaFx 開發出的 Web Services 既能夠運行在 Windows 環境中，又能夠運行在支持 Mono 的 Linux 環境中。
支持多協議：如 JSON 格式的也支持 XSD。
更加 Web 化：RESTful。
服務端實現與客戶端實現的完全解耦：MSA 基於消息的設計，使得服務端的 API 改變並不會破壞現有的客戶端，達到服務端實現與客戶端實現完全解耦的目的。
MSA API 可視化說明文檔便於你調試。
易學：使用 MSA 進行開發和維護服務所需的技術和時間投入要小很多。
易用：簡化了 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的類里（參考例子請見 MSA Demo 的 OrderValidator.cs），然後在宿主環境中進行開啟驗證的配置：

Plugins.Add(new ValidationFeature()); 
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、需要在宿主環境中進行如下配置：

                    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);

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

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 主要實現以下功能：

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

4.5、API Gateway 的使用

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