.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形式使用它来暴露这个微服务所实现的业务逻辑。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/

原文链接： https://www.cnblogs.com/dotnet-arch-system/p/8504602.html