微服务设计模式—API Gateway

2020-07-02 00:00:00 微服 客户端 服务 提供 接口

要解决的问题

在认识API Gateway模式之前,我们先看两个大家都熟悉的页面。下面两张图片分别是天猫的PC浏览器端的首页和Android手机APP的首页。

我们通过上面的两个页面来说明一下为什么需要API Gateway。为了简化问题,我们假设在天猫的首页中仅用到了以下几项服务(以下的服务划分、服务提供的功能、接口形式仅仅是假设):

  • 推荐服务:根据之前的购买和浏览记录,为买家推荐商品。此服务提供REST形式的API接口。
  • 广告服务:根据商家购买的广告向买家推送广告。此服务提供REST形式的API接口。
  • 消息服务:提供商家发送给买家的消息信息。此服务提供RocketMQ形式的接口。
  • 购物车服务:提供买家的购物车信息。此服务提供REST形式的API接口。


天猫要在PC浏览器和APP上显示首页,需要在客户端通过JS代码或Android代码,向以上服务获取信息,并显示在界面上。但这里存在几个问题:

  • 消息服务提供的接口不是REST形式,而是RocketMQ形式,不便于客户端使用
  • 每个微服务基于普适性的要求,提供了大量的细粒度接口,客户端需要通过调用大量接口才能够获取到足够的信息
  • 因为APP是基于移动网络的,大量的前后端交互导致页面响应缓慢,严重影响客户体验
  • 随着业务的发展,后端的服务会发生变更,比如提供多个服务实例并由客户端进行负载均衡,或是次一个服务进一步拆分,需要所有类型的客户端都适配修改


通过引入API Gateway,可以很好的解决上面的问题。


API网关的设计

API Gateway


在客户端和各微服务之间,引入API Gateway为客户端提供友好易用的接口,并将根据业务逻辑向各微服务实例请求。

比如我们前面的例子中,可以由API Gateway为Android APP和PC浏览器分别提供/android/mainpage和/pc/mainpage接口,然后通过REST和RocketMQ与推荐服务、广告服务、消息服务、购物车服务交互以获取需要的信息,并组织成合适的格式后返回给客户端。

API Gateway可以是一个或多个;比如可以为Android和PC分别提供不同的API Gateway。同时,API Gateway自己本身也需要考虑扩缩容和负载均衡。API Gateway与各服务间可以采用融断等机制提高可靠性。


API网关的缺点

  • 引入了API Gateway,需要考虑API Gateway本身的部署、运维、负载均衡等场景,增加了后端服务的复杂度
  • API Gateway中承载了大量的接口适配,导致难以维护
  • 对于部分场景,增加了一跳可能导致性能的降低


参考

  • Pattern: API Gateway / Backend for Front-End
  • Building Microservices: Using an API Gateway
  • 微服务架构模式系列文章之三:API网关
  • 微服务实战(二):使用API Gateway

系列主题

微服务的定义和优缺点

微服务设计模式—API Gateway

微服务设计模式—服务注册与发现

微服务设计模式—微服务通信

微服务设计—微服务可靠性

微服务设计—微服务部署

微服务设计—将Monolithic重构为微服务

微服务设计—事件驱动架构

相关文章