要解决的问题
在认识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
系列主题
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/818/viewspace-3142254/ ，如需转载，请注明出处，否则将追究法律责任。
