微服务设计模式—API Gateway

要解决的问题

在认识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为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重构为微服务

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