中小型研发团队架构实践：微服务架构

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，代码参考以下：

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 可视化说明文档中显示各请求参数、响应的含义说明

七、运行结果

先运行托管应用（如 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/

本系列文章涉及内容清单以下，其中有感兴趣的，欢迎关注：

• 开篇：中小型研发团队架构实践三要点
• 缓存 Redis：Redis快速入门及应用
• 消息队列 RabbitMQ：如何用好消息队列RabbitMQ？
• 集中式日志 ELK：中小型研发团队架构实践之集中式日志ELK
• 任务调度 Job：中小型研发团队架构实践之任务调度Job
• 应用监控 Metrics：应用监控怎么作？
• 微服务框架 MSA
• 搜索利器 Solr
• 分布式协调器 ZooKeeper
• 小工具：
• Dapper.NET/EmitMapper/AutoMapper/Autofac/NuGet
• 发布工具 Jenkins
• 整体架构设计：电商如何作企业整体架构？
• 单个项目架构设计
• 统一应用分层：如何规范公司全部应用分层？
• 调试工具 WinDbg
• 单点登陆
• 企业支付网关
• 结篇

做者介绍

杨丽，拥有多年互联网应用系统研发经验，曾就任于古大集团，现任职中青易游的系统架构师，主要负责公司研发中心业务系统的架构设计以及新技术积累和培训。现阶段主要关注开源软件、软件架构、微服务以及大数据。

张辉清，10 多年的 IT 老兵，前后担任携程架构师、古大集团首席架构、中青易游 CTO 等职务，主导过两家公司的技术架构升级改造工做。现关注架构与工程效率，技术与业务的匹配与融合，技术价值与创新。

转载:http://www.infoq.com/cn/articles/architecture-practice-06-microservice-architect