api gateway java_何为API Gateway

前言

API Gateway的概念到底源自哪里？

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的关系死拽着不放。。