中小型研发团队架构实践三：微服务架构（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 相比，主要优势如下：

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的类里（参考例子请见 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，代码参考如下：

public class OrderRequest : IReturn<OrderResponse>
{
   [ApiMember(Name = "Id", Description = "订单 ID 号", IsRequired = false)]
   public int Id { get; set; }
   [ApiMember(Name = "CustomerName", Description = "客户名", IsRequired = false)]
   public string CustomerName { get; set; }
   //......
   [ApiMember(Name = "OrderItemList", Description = "订购的产品列表", IsRequired = false)]
   public List<OrderItem> OrderItemList { get; set; }
} 

     运行结果如下图所示：

    

               在 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/

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