微服务理论与实践(五)-微服务之间的交互

Microservice架构模式中的“开”是各个服务的内部实现，而其中的“闭”则是各个服务之间相互沟通的方式

 

微服务必须使用进程间通信机制来交互。微服务架构有两类IPC机制可选，异步消息机制和同步请求/响应机制。当设计服务的通信模式时，需要考虑几个问题：服务如何交互，每个服务如何标识API，如何升级API，以及如何处理部分失败。

1. API GateWay 模式

1.1 背景

 当决定将应用当作成一组微服务时，需要决定应用客户端如何与服务端交互。方式有两种：

（1）客户端与服务端直接通讯

（2）采用API Gateway，客户端与API Gateway交互，API Gateway封装具体的服务细节，并提供API给各个客户端。

1.2客户端与服务端直接通讯

   一个客户端可以直接给多个微服务中的任何一个发起请求。每一个微服务都会有一个对外服务端。这个URL可能会映射到微服务的负载均衡上，它再转发请求道具体的节点上。

 

  缺点：

l  客户端的需求量与微服务暴露的细粒度的API数量不匹配，客户端需要发起多个请求才能获取需与的完整数据。

l  客户端请求的微服务的协议可能不是web友好型的，例如微服务是RPC或AMQP协议的，他们都不是web友好型的

l  很难重构微服务

2APIGateway.API GatewayAPIGateway

1.3 API Gateway  

APIGateway是一个服务器，也是进入系统的唯一节点。API Gateway封装系统内部的架构，对每个客户端提供API。

1.3.1 API Gateway的目标

 支持API接口动态发布及运营，包括但不限于：

（1）安全认证

a. 应用申请审核通过后生成公钥，开放平台需提供支持分布式系统的密钥管理

服务可设置为两个安全等级：需授权访问和无需授权访问（后者即任意客户端都可以发起调用），默认所有API都需授权访问。

 

b. 非正常状态（禁用、停用、黑名单等）的应用直接抛异常不允许访问——熔断机制

 

c. 调用次数、调用频率、并发数可运行时控制，避免某请求量过大影响其他应用的调用。

 

d. 可对某个应用某个API设置强制熔断，所有请求无视阀值直接抛出异常。

（2）API管理

所有API可后台查询管理，包括动态发布、参数映射配置、后端服务接口配置、API禁用、启用，多版本、分组、分级别等。

（3）应用管理

 

后台管理开放平台接入的应用（第三方应用），包括查询、禁用、启用、审核。

（4）计费收费

a. API的调用统计，每笔请求时间，响应时间，响应状态。

b. API的计费计算，按照请求量和请求资源计费，实现多种计费模型。（预付费，后收费。按量，按时间周期。）

（5）       熔断

（6）       流量统计及限流

l  支持现有子系统RPC协议的API动态发布及运营，外部请求透传。

l  支持json、xml响应报文，可以请求时选取所需报文格式。

l  支持动态直接将后端SOA服务暴露为API。

l  支持动态将普通Web接口暴露为API。

l  支持动态将MQ服务暴露为API。

l  支持多个服务组合编排后暴露为API。

l  请求的转发、合成和协议转换

l  给客户端提供一个定制化的API

1.3.2 API Gateway模式的优缺点

（1）优点：

 

l  特定的API。使客户端只需跟Gateway打交道，减少客户端与服务端的通讯次数，也简化了客户端的代码。

l  去报客户端不需要受服实例位置的影响

l  为每套客户端提供最优的API

l  降低请求/往返次数

 

（2）缺点

l  API Gateway是一个高可用的组件，必须要开发、部署和管理。开发者必须要更新API Gateway来提供新服务提供点来支持新暴露的微服务。

l  API Gateway会造成多余的网络跳转

2.3 API 版本管理