微服务理论与实践(五)-微服务之间的交互
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 版本管理