客户端与微服务的通信
在单体应用中，通常只有一组冗余的或负载均衡的服务提供点，在微服务架构中，每一个微服务暴露了一组细粒度的服务提供点。
比如，一个电商页面的展示若是采用微服务架构，最终页上的数据会分布在不同的微服务上。下面列举了可能与产品最终页数据有关的一些微服务：
- 购物车服务 -- 购物车中的物品数
- 下单服务 -- 下单历史
- 分类服务 -- 基本产品信息，如名字、图片和价格
- 评论服务 -- 用户评论
- 库存服务 -- 低库存警告
- 快递服务 -- 快递选项、截止时间、来自不同快递API的成本计算
- 推荐服务 -- 推荐产品
要解决移动客户端如何访问这些服务，请看下面这几种方式
客户端到微服务直接通信
Direct Client‑to‑Microservice Communication
这种方式是指页面上每一个请求点都是页面自己与各个微服务进行请求的。如上例子，它将有对 7 个服务分别进行请求。这种方式有三个问题：
- 请求数量多，复杂，微服务越多越复杂，且没有效率
- 并非 Web 友好的，各微服务访问协议可能不同，而且没有防火墙
- 客户端直连微服务，微服务在做变动的话将很难实施
采用 API Gateway
通常来说一个好的解决办法是用 API Gateway，API Gateway 是一个服务器，也可以说是进入系统的唯一节点。它与设计模式中的 门面模式 非常像。
API Gateway 封装内部系统架构，并且提供 API 给客户端，它还可以有其他功能，如授权、监控、缓存、请求分片、管理、静态响应等等。
API Gateway
API Gateway 负责 请求转发 、合成 和 协议转换，所有客户端请求先经过 API Gateway，然后路由这些请求到对应的微服务。
它可以将一个请求去调用多个微服务，并且聚合多个服务的结果。还可以对 Web 协议进行转换。
比如商品详情页面，API Gateway 对外只提供一个路由（/products/{id}），而对内会调用多个服务来处理这一个请求，并返回结果。
API Gateway 的优缺点
其最大的好处就是封装了应用的内部结构，让其对外提供异常简单。
它的缺点也很明显，它是一个高可用的组件，必须要开发、部署和管理。这就增加了成本。比如每增加一个微服务功能点都需要修改一下 Gateway。
实现 API Gateway 设计上的考虑点
性能和可扩展性
API Gateway 的性能和可扩展性非常重要，创建一个支持同步、非阻塞I/O的API Gateway是有意义的。比如使用 Nginx Plus，它提供了一个成熟的、可扩展的、高性能的 Web 服务器和反向代理，还提供管理授权、权限控制、负载均衡、缓存、以及健康检查和监控等丰富的功能。
采用反应性编程模型（Reactive）
类似 Js 的 Promise，即异步回调。
服务调用
即进程间通信。可以有同步异步两种方式（通常是两种方式的结合），分别对应如 HTTP 和 MQ 等方式。
服务注册与发现
API Gateway 需要知道每一个服务的 IP 和端口。为了这个要求，就需要有一套服务注册与发现机制。
处理部分失败
API Gateway 在多次调用微服务时，要考虑部分微服务调用超时甚至失败的情况。
总结
本文了解了 API Gateway 解决的问题，它向客户端提供了一个自定义的 API，而它负责了请求的转发、合成与协议的转换。
网友评论