翻译-微服务API Gateway
原文地址：http://microservices.io/patterns/apigateway.html，以下是使用google翻译对原文的翻译。
让我们想象一下你正在建立一个使用微服务模式的网上商店，你所用的产品详细信息页面。你需要开发多个版本的产品详情界面：
l 由服务器端Web应用程序生成的HTML - HTML5/ JavaScript的桌面和移动浏览器用户界面。
l 原生Android和iPhone客户端 - 这些客户端通过的REST API服务器交互。
此外，网上商店必须通过使用由第三方应用REST API公开的产品详细信息。一个产品的详细信息界面可以显示很多有关产品的信息。例如，Amazon.com的详细信息页面包括：
l 关于这本书，如标题，作者，价格等基本信息
l 这本书购买历史记录
l 可用性
l 购买选项
l 购买这本书的客户还买了那些
l 顾客评论
l 卖家排名
l ...
由于网上商店使用微服务模式的，产品详细信息数据分布在多个服务。 例如，
l 产品信息 - 有关产品，如标题，作者基本信息
l 定价服务 - 产品价格
l 订购服务 - 购买历史记录产品
l 库存服务 - 产品供应
l 评论服务 - 客户评论...
因此，显示产品细节的代码需要在所有这些服务中获取信息。
难题
微服务的客户端是如何访问个体服务的？
考虑因素
l 通过微服务提供的API的粒度往往和客户端需要的不同。微服务通常提供细粒度的API，这意味着客户端需要与多个服务进行交互。例如，如上所述，客户端需要的产品的细节需要从多种服务获取数据。
l 不同的客户端需要不同的数据。例如，产品详情页桌面浏览器的版本通常更复杂于移动版本。
l 网络性能因为不同类型的客户端而不同。例如，移动网络通常要慢得多，并具有高得多的延迟。当然，任何广域网是比一个局域网慢得多。这意味着手机本地客户端使用的网络与服务端web应用的LAN的性能特点区别很大。服务端web应用可以在不影响用户体验的情况下，向后端服务发送大量请求，但手机客户端只能发送少量的请求。
l 服务实例数量和它们的位置（主机+端口）动态改变。
l 服务可能随时间改变，所以要对客户端隐藏细节。
解决方案
可以实现一个API 网关，他是所有客户端的入口。 API网关有两种方式来处理请求。有些请求被简单地代理/路由到合适的服务上，其他的请求被转给到一组服务。
该API网关可以为每个客户端提供不同的API，而不是提供一个适合所有情况下的API。例如，Netflix的API网关运行客户端特定适配器代码，提供给每个客户端它们需要的API。
API网关还可以实现安全性，例如： 验证客户端被授权执行请求。
结论
使用API网关具有以下优点：
l 使服务和客户端解耦。
l 使客户端和服务部署环境解耦。
l 提供了最佳的API给每个客户端。
l 减少的请求/往返次数。例如，API网关可以一次性检索多个服务的数据。更少的请求也意味着更少的开销，提高了用户体验。一个API网关对于移动应用至关重要。
l 简化了客户端的调用，因为API网关可以组合服务，并提供组合后的façade接口。
API网关模式也有一些缺点：
l 增加的复杂性，API网关是必须开发、部署和管理的另一个应用。
l 增加的响应时间，因为通过API网关多了一层网络跳转。然而，对于大多数应用的额外往返的成本是微不足道的。
问题
如何实现API网关？API网关需要支持高并发、高负载，使用事件响应机制（IO两种机制：一种是阻塞式的，另一种是事件响应式的，还有最新的一种是GO语言微线程方式）是最好的方法。在JVM上，可以基于NIO的库如Netty，另外 NodeJS是另一个选择。