外部API：API网关 / Backend for Front-End

假设你正在采用微服务架构构建一个在线商城，你正在实现一个产品详情页面。你需要开发不同版本的产品详情的用户界面：

此外，这个在线商场必须通过 REST API 暴露产品详情接口，给第三方应用程序使用。

产品性行情UI可以展示关于产品的许多信息。比如，Amazon.com 上 POJOs in Action 的详情页展示了：

由于在线商城采用了微服务架构，产品详情数据散步在多个服务。例如，

因此，展示产品详情的代码需要从这些服务获取信息。

微服务为基础的应用客户端怎么访问分散的服务？

微服务提供的API粒度，通常与客户端需要的不一样。微服务通常提供细粒度的API，意味着客户端需要与多个服务交互。例如，如上描述的，需要产品详情的客户端需要从很多服务获取数据。
不同的客户端需要不同的数据。比如，桌面浏览器版本的产品详情页通常比移动端版本的更详尽。
不同类型的客户端，网络性能不一样。比如，移动端网络通常比非移动端网络更慢，延迟更高。而且，当然的，任何WAN都比LAN更慢。这意味着原生移动端客户端和使用LAN的服务端网站程序有着完全不同的性能特点。服务端的网络可以对后端服务发起多次请求，不会影响用户体验，但移动端客户端仅仅能发起更少的请求。
服务实例的数量和他们的地址（主机和端口）动态变化
服务的划分可以随着时间而改变，而且应该对客户端隐藏
服务应该可以采用多种协议，其中一些可能不是web友好

实现一个API网关，作为所有客户端的单一入口。API网关以两种方式之一处理请求。一部分请求简单的代理 / 路由到对应的服务。其他请求分散给多个服务。

image.png

相比起提供一刀切风格的API，API网关可以对不同的客户端暴露不同的接口。比如，Netflix API网关运行了对特定客户端的适配代码，为不同客户端提供了最适应它们需求的接口。

API网关业务通常实现了安全性，比如验证客户端发起请求时是否经过授权。

这个模式的一个变异是 Backend for Front-End 模式。它为不同类型的客户端定义了不同的API网关。

image

在这个例子中，有三种类型的客户端：网站应用程序，移动端应用程序和第三方应用程序。也有三种不同的网关。每个网关为它的客户端提供接口。

使用API网关有如下优势：

将客户端从应用怎样拆分为微服务中隔离
将客户端从定位服务实例的问题中隔离
为每个客户端提供最优的接口
减少了请求 / 往返的数量。比如，API网关允许客户端从单次往返中获取多个服务的数据。更少的请求，意味着更小的开销，并提升了用户体验。API网关对移动端应用程序是必需的。
简化了客户端，将调用多个服务的逻辑从客户端迁移到了API网关
将标准，公开，web友好的API协议翻译成内部使用的无论什么协议

API网关有如下弊端：

问题：

如何实现API网关？如果必须扩展为处理高负载，最好的方式事件驱动 / 响应式。在JVM，以NIO为基础的库，比如Netty，Spring Reactor等等是有意义的。NodeJS是另外一个选择。

参考作者的微服务示例应用里的API网关。它采用了Spring Cloud Gateway实现。