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

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 版本管理


阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页