88bifa必发 11

中小型研发团队架构实践:微服务架构88bifa必发(MSA)

二、MSA 框架的使用

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

     4、服务

    
创建 MSA 服务时,必须继承来自 MSA 的 Service
类。

     1.3、MSA 框架实现架构

     MSA
服务端的架构请见下图的第一张图,MSA 的 HTTP
客户端架构请见下图的第二张图。MSA 的内部是建立在原生的 ASP.NET
IHttpHandler 之上实现的,支持 JSON、XML、JSV、HTML、Message
Pack、ProtoBuf、CSV 等消息格式。

    
88bifa必发 1

                                                  MSA
服务端的架构

    
88bifa必发 2

                                             MSA
HTTP Client 的架构

三、微服务治理

    
在我们自主开发的框架管理系统中,进行接口注册,请见下图。其中,规定内部服务访问名的命名规范是:/{***Service}/
方法名,如 /OrderService/CreateOrder;规定外部服务访问名 OpenApiName
的命名规范是:{各产品线的缩写英文名}方法名,如 FltCreateOrder,其中 Flt
表示国内机票业务的缩写英文名。

    
88bifa必发 3

    
    
    
    
    
    
    
    
    
    
MSA 接口注册页

     2、 路由

         
A、MSA 自身提供的默认路由是:

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

         
B、创建自定义路由,其创建方法是:使用
RouteAttribute 或在宿主环境中配置。提供的 MSA Demo
采用的是在宿主环境中配置路由这种方式来创建自定义路由。

     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
自动生成的说明文档进行调试,十分方便。

    
88bifa必发 4

    
    
    
    
    
    
    
    
    
Metadata 页

    
88bifa必发 5

    
    
    
    
    
    
  
MSA API 可视化说明文档界面

     4.2、API Gateway 的优点

    
88bifa必发 6

  • 网络隔离:微服务部署在了内网,通过
    API Gateway 开放给 PartnerAPI、WebAPI 或 MobileAPI。
  • 在网关层面的轻量级消息路由和转换。
  • 在网关层面对存在的微服务提供必要的抽象。例如,网关可以选择对不同的用户暴露不同的
    API。
  • 一个中心的地方提供非功能性的能力,这些能力可复用,
    比如超时、限流、熔断、监控、日志记录等。
  • 通过适用
    API
    网关模式,微服务可以变得更加轻量,因为非功能性需求都在网关上实现了。
  • 统一安全管控。

     4.4、API Gateway 的功能

    
API Gateway 主要实现以下功能:

  1. *路由映射:外部服务访问名映射到对应的内部服务访问名。*
  2. *权限验证:包括针对客户角色的访问授权验证、针对客户的访问授权验证、IP
    黑名单验证。*
  3. *超时处理:当
    API 网关调用的内部服务响应时间超过了在自主开发的 API
    网关后台管理子系统中所设置的允许最长的超时时间时,API
    网关会立即停止调用,并返回相关消息给你。*
  4. *限流控制:当你通过
    API 网关调用内部服务的频率达到在某个阈值时,API
    网关会立即做断开链路处理。过了时间后,链路会自动闭合回去。*
  5. *熔断处理:熔断处理对避免无谓的资源消耗特别有用,当通过
    API 网关调用的内部服务出现异常的频率达到某个阈值时,那么 API
    网关会做临时熔断处理即临时断开链路,暂时停止你对那个内部服务的调用。临时熔断后,过了一段时间后,链路会自动闭合回去。*
  6. *日志信息记录:会记录客户
    IP、客户请求参数、返回结果、异常信息等信息。*

     3、如何验证请求参数的合法性

    
如果你需要在提交请求参数前,验证请求参数是否必填或是否合法,那么验证逻辑必须写在继承自
MSA 的 AbstractValidator的类里(参考例子请见 MSA Demo 的
OrderValidator.cs),然后在宿主环境中进行开启验证的配置:

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

四、微服务网关 API Gateway

     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 } 

    
运行结果如下图所示:

    
88bifa必发 7

    
    
    
在 MSA API
可视化说明文档中显示各请求参数、响应的含义说明

     1.1、MSA 是什么

    
微服务架构 MSA 是 Microservice Architect
的简称,它是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相通讯、互相配合,为用户提供最终价值。它与
SOA 之间的区别如下:

    
88bifa必发 8

     4.5、API Gateway 的使用

    
在使用 API Gateway
之前,需要先配置网关参数。网关参数的配置是在自主开发的 API
网关后台管理子系统中进行:

    
88bifa必发 9

    
    
    
    
    
在自主开发的 API
网关后台管理子系统中配置网关参数

一、MSA 简介

     1、服务托管

    
服务端的服务对外提供服务前,必须先要把服务端给托管起来。MSA
提供了通过 IIS、Self-Host
等多种形式把服务端给托管起来,宿主环境可以是控制台应用或 Windows Service
或 ASP.NET Web 应用或 ASP.NET MVC 应用。提供的 MSA Demo 的宿主环境用的是
ASP.NET Web 应用。

     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 的开发过程。

五、Demo 下载及更多资料

 

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

     4.3、API Gateway 的架构

    
88bifa必发 10

     4.1、API Gateway 的简介

    
API Gateway
风格的核心理念是使用一个轻量级的消息网关作为所有客户端的主入口,并且在
API Gateway 层面上实现通用的非功能性需求。如下图所示:所有的服务通过 API
网关来暴露,这是所有客户端访问的唯一入口;如果一个服务要访问另一个服务,也要通过这个网关。

    
88bifa必发 11

    
    
    
    
    
    
    
    
所有服务通过一个 API
网关来暴露

    
一旦 API
网关允许客户端消费一个受管理的 API,那么我们就可以以受管理的 API
形式使用它来暴露这个微服务所实现的业务逻辑。API 网关以 NIO、IOCP
来连接内部受管理的 API,以实现 API 网关的高并发。