微服务模式系列之三：API网关

Posted 2021-04-21 EAWorld

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了微服务模式系列之三：API网关相关的知识，希望对你有一定的参考价值。

译者自序：

熟悉我的朋友都知道，我很不喜欢翻译东西，因为在两种语言的思维方式之间做频繁切换对我来说是件很痛苦的事情。但是这次不一样，公司和同事的大力支持降低了我的痛苦指数，让我能够坚持把Chris Richardson的微服务模式系列文章翻译完，今天发布第三篇，《API网关》。

背景

利用微服务模式构建一套在线商店，并要包含产品细节页面，需要为产品信息用户界面开发出多个版本：

另外，在线商店必须通过REST API发布产品细节，以供第三方应用程序使用。

产品细节UI可以显示出大量产品信息。举例来说，Amazon.com的POJOs in Action 图书详情页面中会显示：

在使用微服务模式的在线商店中，产品详情数据会分布在多项服务之间，例如：

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

问题

微服务架构的应用客户端如何访问各项服务？

需求

微服务提供的API粒度通常与客户端需要的有所不同。微服务通常提供的是细粒度API，这意味着客户端需要同多项服务进行交互。举例来说，如之前所提到的，客户端需要从多项服务处获取数据方可获得产品详情。
不同客户端需要不同的数据。举例来说，有产品详情页面的桌面浏览器版本通常较移动版复杂。
不同客户端的网络性能亦有所区别。举例来说，移动网络通常较非移动网络速度更慢且更延迟。当然，广域网速度也必然低于局域网。这意味着原生移动客户端所使用的网络在性能上与服务器端Web应用采用的局域网完全不同。服务器端Web应用能够向后端服务发送多条请求，而且不会影响到用户体验，但移动客户端则只能发送少量请求。
服务实例数量与其位置（主机与端口）会发生动态变化。
服务的划分方式会随时间的推移而改变，且不应被客户端所感知。

方案

使用API网关作为全部客户端的单一入口点。该API网关通过以下两种方式之一处理请求。部分请求会被直接代理/路由至对应的服务，另一部分请求则需要接入多项服务。

相比提供满足所有需求的API，API网关可以针对不同客户端提供出不同的API。举例来说，Netflix API网关运行的是客户端特定适配代码，这种代码能够为各客户端提供最符合其需求的API。

API网关还能够实现安全防护，例如验证当前客户端是否有权执行该请求。

示例

结果

API网关有以下优势：

确保客户端无法察觉应用程序是如何被拆分为多项微服务的。
确保客户端不受服务实例的位置的影响。
为每套客户端提供最优API。
降低请求/往返次数。举例来说，API网关能够确保客户端在单次往返中就从多项服务中检索出数据。请求数量更少意味着运行负担更低且用户体验更好。API网关对于移动应用而言是必不可少的。
将从客户端调用多项服务的逻辑转换为从API网关处调用，从而简化整个客户端。

API网关模式也有一些弊端：

问题：

如何实现API网关？如果需要不断扩展以处理高负载量，那么事件驱动型/响应型方案是最理想的选择。在JVM上，Netty、Spring Reactor等基于NIO的库大有用处。Node.JS也是一个可行的选项。