在使用单体应用架构的情况下，移动客户端通过对应用进行单个 REST 调用来检索此数据
例如：GET api.company.co/productdetails/productId
负载均衡器将请求路由到几个相同应用实例中的其中一个。之后，应用查询各个数据库表并返回响应给客户端。
相比之下，当使用微服务架构时，产品详细页面上展示的数据来自多个微服务
客户端与微服务直接通信:
- 第一个问题是客户端的需求与每个微服务暴露的细粒度的 API 不匹配
- 另一个问题是有些服务可能使用了非 web 友好协议
- 另一个缺点是它难以重构微服务
使用 API 网关:
- API 网关是一个服务器，是系统的单入口点。它类似于面向对象设计模式中的门面（Facade）模式。API 网关封装了内部系统架构，并针对每个客户端提供一个定制 API。它还可用于认证、监控、负载均衡、缓存和静态响应处理
- API 网关负责请求路由、组合和协议转换
- API 网关还可以为每个客户端提供一个定制 API
实现 API 网关:
- 性能与可扩展性
对于大多数应用来说，API 网关的性能和可扩展性是相当重要的。因此，在一个支持异步、非阻塞 I/O 平台上构建 API 网关是很有必要的。NGINX Plus 提供了一个成熟、可扩展和高性能的 Web 服务器和反向代理，它易于部署、配置和编程。NGINX Plus 可以管理身份验证、访问控制、负载均衡请求、缓存响应，并且提供了应用健康检查和监控功能。
2. 使用响应式编程模型
有时候，请求是相互依赖的。API 网关可能需要在将请求路由到后端服务之前，通过调用验证服务来验证该请求，使用传统的异步回调方式来编写 API 组合代码会很快使你陷入回调地狱。响应式可让你能够编写出简单而高效的 API 网关代码。
3. 服务调用
基于微服务的应用是一个分布式系统，必须使用进程间（inter-process）通信机制。有两种进程间通信方案。一是使用基于消息的异步机制。某些实现采用了消息代理，如 JMS 和 AMQP。其他采用无代理的方式直接与服务通信，如 Zeromq。 另一种类型的进程间通信采用了同步机制，如 HTTP 和 Thrift。系统通常会同时使用异步和同步方式。甚至可以为每种方式应用多个实现。因此，API 网关需要支持各种通信机制。
4. 服务发现
API 网关与系统中的任何其他服务客户端一样，需要使用系统的服务发现机制：服务端发现或客户端发现,现在需要注意的是，如果系统使用客户端发现，API 网关必须能够查询服务注册中心，注册中心是所有微服务实例及其位置的数据库。
5. 处理局部故障
实现 API 网关时必须解决的另一个问题是局部故障问题。当一个服务调用另一个响应缓慢或者不可用的服务时，所有分布式系统都会出现此问题。API 网关不应该无期限地等待下游服务。但是，如何处理故障取决于特定的方案和哪些服务发生故障。(Hystrix )
微服务实战：NGINX Plus 作为 API 网关
使用 NGINX Plus 作为 API 网关的理由包括：
- 访问管理
上至 Web 应用级别，下至每个个体微服务级别，你都可以使用各种访问控制列表（ACL）方法，并且可以轻松实现 SSL/TLS - 可管理性与伸缩性
你可以使用 NGINX 的动态重新配置 API、Lua 模块、Perl 来更新基于 NGINX Plus 的 API 服务器，也可以通过 Chef、Puppet、ZooKeeper 或 DNS 来改变 - 与第三方工具集成
NGINX Plus 已经可以与部分先进的工具集成在一起，如 3scale，Kong 和 MuleSoft 集成平台（仅列举在 NGINX 网站上提及的工具）
