翻译-微服务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是另一个选择。