update content

2-using-an-api-gateway.md

@@ -31,7 +31,7 @@ GET api.company.com/productdetails/productId
 负载均衡器将请求路由到几个相同应用程序实例中的其中一个。之后，应用程序查询各个数据库表并返回响应给客户端。相比之下，当使用微服务架构时，产品详细页面上展示的数据由多个微服务拥有。以下是一些可能拥有特定商品页面展示的数据的微服务：
 
 - **订单服务** - 订单历史
-- **目录（catalog）服务** - 基本的产品洗脑洗，如产品名称、图片和价格
+- **目录（catalog）服务** - 基本的产品信息，如产品名称、图片和价格
 - **评价服务** - 客户评价
 - **库存服务** - 低库存警告
 - **配送服务** - 配送选项、期限和费用，由配送方的 API 单独提供  
@@ -51,10 +51,45 @@ https://serviceName.api.company.name
 
 不幸的是，这种方式存在着挑战和限制。一个问题是客户端的需求与每个微服务暴露的细粒度的 API 不匹配。此示例中，客户端需要进行七次单独的请求。如果在更加复杂的应用中，它可能需要做更多的工作。例如，Amazon 展示了在产品页面渲染中如何牵涉到数百个微服务。虽然客户端可以通过 LAN 发送许多请求，但在公共互联网下效率低下，在移动网络肯定是不切实际的。
 
-客户端直接调用微服务的另一个问题是有些可能使用了不是 web 友好的协议。一个服务可能使用 Thrift 二进制 RPC，而另一个则可能使用 AMQP 消息协议。这两个协议无论是对于浏览器或者防火墙都是不友好的，最好是在内部使用。应用程序应该在防火墙之外使用 HTTP 或这 WebSocket 之类的协议。
+客户端直接调用微服务的另一个问题是有些可能使用了不是 web 友好的协议。一个服务可能使用 Thrift 二进制 RPC，而另一个则可能使用 AMQP 消息协议。这两个协议无论是对于浏览器还是防火墙都是不友好的，最好是在内部使用。应用程序应该在防火墙之外使用 HTTP 或者 WebSocket 之类的协议。
 
 这种方法的另一个缺点是它难以重构微服务。随着时间推移，我们可能会想改变系统怎样划分为服务。例如，我们可能会合并两个服务或者将服务拆分为两个或者更多。然而，如果客户端直接与服务进行通信，实施这类的重构将变得非常困难。
 
-由于这些问题，很少有客户端直接与微服务进行通信。
+由于存在这些问题，很少有客户端直接与微服务进行通信。
+
+## 2.3、使用 API 网关
+通常更好的方法是使用 API 网关。一个 API 网关是一个服务器，是系统的单入口点。它类似于面向对象设计模式中的门面（Facade）模式。API 网关疯封装了内部系统架构，并针对每个客户端提供一个定制的 API。它还可用于认证、监控、负载均衡、缓存和静态响应处理。
+
+图 2-3 展示了 API 通常如何整合架构
+
+![使用 API 网关的微服务](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/resources/2-3.png)
+
+API 网关负责请求路由、组合和协议转换。所有的客户端请求首先通过 API 网关。之后请求被路由到适当的服务。API 网关通常会通过调用多个微服务和聚合结果来处理一个请求。它可以在 Web 协议（如 HTTP 和 WebSocket）和用于内部的非 Web 友好协议之间进行转换。
+
+API 还可以为每个客户端提供一个定制的 API。它通常会为移动客户端暴露一个粗粒度的 API。例如，考虑一下产品详细信息场景。API 网关可以i提供一个端点 `/productdetails?productid=xxx`，如图 2-3 所示，一个使用了 API 网关的微服务。允许移动客户端通过一个单独的请求来检索所有产品详细信息。API 网关通过调用各种服务（产品信息、推荐、评价等）并组合结果。
+
+API 网关的一个很好的示例是 [Netflix API 网关](http://techblog.netflix.com/2013/02/rxjava-netflix-api.html)。Netflix 流媒体服务可用于数百种不同类型的设备，包括电视机、机顶盒、智能手机、游戏机和平板电脑等。最初，Netflix 尝试提供为他们的流媒体服务提供一个[通用](http://www.programmableweb.com/news/why-rest-keeps-me-night/2012/05/15)的 API。但是，他们发现由于设备种类繁多，并且他们各自有着不同需求，所以并不是能很好地运作。如今，他们使用了 API 网关，通过运行特定设备适配代码来为每个设备提供一个定制 API。
+
+## 2.4、API 网关的优点和缺点
+正如您所料，使用 API 网关同样存在好处和坏处。使用 API 网关的主要好处是它封装了应用程序的内部结构。客户端只需要与网关通信，而不必调用特定的服务。API 网关为每种类型的客户端提供了特定的 API，减少了客户端与应用程序之间的往返次数。它还简化了客户端的代码。
+
+API 网关也有一些缺点，它是另一个高度可用的组件，需要开发、部署和管理。还有另一个风险是 API 网关可能会成为开发瓶颈。开发人员必须更新 API 网关以暴露每个微服务的端点。
+
+重要的是更新 API 网关的过程尽可能地轻一些。否则，开发人员将被迫排队等待网关更新。尽管存在这些缺点，但对于大多数的真实应用来说，使用 API 是合理的。
+
+## 2.5、实施 API 网关
+我们已经了解了使用 API 网关的动机和权衡。接下来让我们看看您需要考虑的各种设计问题。
+
+### 2.5.1、性能与可扩展性
+只有少数公司能达到 Netflix 的运营规模，每天需要处理数十亿的请求。然而，对于大多数应用来说，API 网关的性能和可扩展性是相当重要的。因此，在一个支持异步、非阻塞 I/O 平台上构建 API 网关是有必要的。可以使用不同的技术来实现一个扩展的 API 网关。在 JVM 上，您可以使用基于 NIO 的框架，如Netty、Vertx、Spring Reactor 或者 JBoss Undertow。一个流行的非 JVM 选择是使用 Node.js，它是一个建立在 Chrome 的 JavaScript 引擎的平台。另一个选择是使用 NGINX Plus。
+
+[NGINX Plus](https://www.nginx.com/solutions/api-gateway/) 提供了一个成熟、可扩展和高性能的 Web 服务器和反向代理，它易于部署、配置和编程。NGINX Plus 可以管理身份验证、访问控制、负载均衡请求、缓存响应，并且提供了应用程序健康检查和监控功能。
+
+### 2.5.2、使用响应式编程模型
+API 网关通过简单地他们路由到适当的后端服务来处理一些请求。它通过调用多个后端服务并聚合结果来处理其他请求。对于某些请求，如产品详细信息请求，对后端服务请求而言是彼此独立的。为了缩短响应时间到最小，API 网关应该并发执行独立请求。
+
+然而，有时候，请求是相互依赖的。首先，API 网关可能需要在将请求路由到后端服务之前，通过调用验证服务来验证请求。同理，为了从客户的愿望清单中获取关于产品的信息，API 网关首先必须检索包含该信息的客户资料，然后检索每个产品的信息。API 组合的另一个有趣的案例是 [Netflix 视频网格](http://techblog.netflix.com/2013/02/rxjava-netflix-api.html)。
+
+使用传统的异步回调方式来编写 API 组合代码会很快使你陷入回调地狱。代码将会变得杂乱，难以理解，并且容易出错。一个更好的方式是使用响应式方法以声明式编写 API 网关代码。响应式抽象的例子包括 Scala 的 Future、Java 8 中的 CompletableFuture 和 JavaScript 中的 Promise。还有Reactive Extensions（也称为 Rx 或 ReactiveX），最初由 Microsoft为 .NET 平台开发。Netflix为 JVM 创建了 RxJava，专门应用于其 API 网关。还有用于 JavaScript 的 RxJS，它可以在浏览器和 Node.js 中运行。使用响应式方式可让您能够编写出简单而高效的 API 网关代码。
 
 **待续……**

README.md

@@ -19,15 +19,15 @@
 ### [2、使用API网关](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/2-using-an-api-gateway.md)
 - [2.1、简介](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/2-using-an-api-gateway.md#21简介)
 - [2.2、客户端与微服务直接通信](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/2-using-an-api-gateway.md#22客户端与微服务直接通信)
-- 2.3、使用 API 网关
-- 2.4、API 网关的优点和缺点
-- 2.5、实现 API 网关
-- 2.6、性能与扩展
-- 2.7、使用响应式编程模型
-- 2.8、服务调用
-- 2.9、服务发现
-- 2.10、处理部分失败
-- 2.11、总结
+- [2.3、使用 API 网关](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/2-using-an-api-gateway.md#23使用API网关)
+- [2.4、API 网关的优点和缺点](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/2-using-an-api-gateway.md#24API网关的优点和缺点)
+- [2.5、实施 API 网关](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/2-using-an-api-gateway.md#25实施API网关)
+    - [2.5.1、性能与扩展](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/2-using-an-api-gateway.md#251性能与扩展)
+    - [2.5.2、使用响应式编程模型](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/2-using-an-api-gateway.md#252使用响应式编程模型)
+    - 2.5.3、服务调用
+    - 2.5.4、服务发现
+    - 2.4.5、处理部分失败
+- 2.6、总结
 - 微服务实战：NGINX 作为 API 网关
 
 ### 3、进程间通信