前言
API Gateway的概念到底源自哪里？
先引用一下技术雷达上，与其有一定渊源的技术介绍：
https://www.thoughtworks.com/cn/radar/tools/api-management-services
https://www.thoughtworks.com/cn/radar/platforms/overambitious-api-gateways
https://www.thoughtworks.com/radar/techniques/bff-backend-for-frontends
API-management-services
个人觉得，“API Gateway”这个字面名称，应该包含在API-management-services的概念中，如apigee、kong。
与后端是否是微服务架构无关，不使用微服务，只要是分布式多服务的，亦可使用。现在先聊一下无关是否是微服务的API gateway。
角色
API外部调用端
API gateway（apigee/kong）
后端服务（具体API的提供者）
主要作用:
- facade。
API外部调用端的直接交互方为API gateway，不关心API具体指向后端哪一个服务。
可达到的效果：
- API解耦。将提供给外部调用端的API协议，与后端服务提供的API进行隔离。有益于后端重构，如微服务合并、拆分等。
- 一致性。统一后端不同服务中各自提供暴露出来的API协议格式，便于外部调用端消费。
-
Security。
给具体的外部调用端颁发app apiKey, 以便于调用来源、或者说服务使用方合法。 -
附加服务。
如apigee、kong还提供了monitoring & analytics、Rate limit、Monetization其他附加服务。
因此，说到API Gateway最根本的作用就是Facade，对应到最基本的功能就是路由route。
在技术雷达上就对overambitious-api-gateways持最外围的保留态度。
从微服务考虑API-Gateway
这里引用一下Chris Richardson的一篇文章中关于为什么需要API-Gateway的三个痛点描述：
- 各微服务API协议不一致。
- 客户端与后端调用耦合，让后端重构困难（如合并微服务、拆分微服务等）。
- 客户的需求与每个后端微服务公开的API粒度之间的不匹配。同时公网上单独请求多次，效率低下。
前两点在上面_API-Gateway_的门面模式中可以解决，而第三点需要的是API聚合。而关于这个独立的聚合概念，就是BFF。至于为什么说它是独立的呢？因为与前两点不同，它与具体的业务场景、或者说前端UI场景有关。
BFF
这里想要吐槽一下Chris Richardson，在他的很多文章中，带入了一个很让人模糊不清的API-Gateway的概念。见Pattern: API Gateway / Backend for Front-End。
在本人看来，BFF其实跟API-Gateway毫无关系，并不是多个API-Gateway的搭建就叫BFF。 这里推荐Sam Newman对BFF的诠释，文章链接。
同时，在这篇文章的留言中，Chris Richardson进行了留言，仍然将API-Gateway与BFF的关系死拽着不放。。
附：
Netflix API
Embracing the Differences : Inside the Netflix API Redesign