中小研发团队架构实践之微服务MSA

1、MSA简介

1.一、MSA是什么

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

SOA实现 微服务架构实现  
企业级,自顶向下开展实施 团队级,自底向上开展实施  
粒度大:服务由多个子系统组成 粒度细:一个系统被拆分红多个服务,且服务的定义更加清晰  
重ESB:企业服务总线,集中式的服务架构 轻网关:无集中式总线,松散的服务架构  
开发过程复杂 易开发:减小了企业ESB开发的复杂性,与敏捷开发的思想高度结合在一块儿  
单块架构系统,相互依赖,部署复杂 服务能被独立部署  
     

1.二、咱们的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.三、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<TRequest>的类里(参考例子请见MSA Demo的OrderValidator.cs),而后在宿主环境中进行开启验证的配置:
1 Plugins.Add(new ValidationFeature()); 
2 container.RegisterValidator(typeof(OrderValidator));

四、服务

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

五、MSA内置的客户端

5.一、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。html

 
5.二、MSA内置的客户端提供Get、Send、Post、Put、Delete等方法。查询数据通常用Get方法,新增操做通常用Post方法,更新操做通常用Put方法,删除操做通常用Delete方法。
这些方法都有重载。
如下是Get方法的其中一个签名: 
1 TResponse Get<TResponse>(IReturn<TResponse> requestDto);

六、MSA API可视化说明文档自动生成的实现

在宿主环境中加以下配置:
1 Plugins.Add(new SwaggerFeature());

若是须要在MSA API可视化说明文档中可以看到各请求参数、响应的含义说明,那么须要为Request DTO、Response DTO对象的各属性标上ApiMember,代码参考以下:git

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

七、运行结果       

先运行托管应用(如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主要实现如下功能:
一、路由映射:外部服务访问名映射到对应的内部服务访问名。
二、权限验证:包括针对客户角色的访问受权验证、针对客户的访问受权验证、IP黑名单验证。
三、超时处理:当API网关调用的内部服务响应时间超过了在自主开发的API网关后台管理子系统中所设置的容许最长的超时时间时,API网关会当即中止调用,并返回相关消息给你。
四、限流控制:当你经过API网关调用内部服务的频率达到在某个阈值时,API网关会当即作断开链路处理。过了时间后,链路会自动闭合回去。
五、熔断处理:熔断处理对避免无谓的资源消耗特别有用,当经过API网关调用的内部服务出现异常的频率达到某个阈值时,那么API网关会作临时熔断处理即临时断开链路,暂时中止你对那个内部服务的调用。临时熔断后,过了一段时间后,链路会自动闭合回去。
六、日志信息记录:会记录客户IP、客户请求参数、返回结果、异常信息等信息。

4.五、API Gateway的使用

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

5、Demo下载及更多资料 

相关文章
相关标签/搜索