finished chapter 1

1-introduction-to-microservices.md

@@ -92,4 +92,22 @@
 
 微服务架构模式的另一个主要的挑战是实现了跨越多服务变更。例如，我们假设您正在实现一个变更服务 A、B 和 C 的需求，其中 A 依赖于 B，并且 B 依赖于 C。在单体应用程序中，您可以简单地修改相应的模块、整合变更并一次性部署他们。相反，在微服务中您需要仔细规划和协调出现的变更到每一个服务。例如，您需要更新服务 C，然后更新服务 B，最后更新服务 A。幸运的是，大多数变更只会影响一个服务；需要协调的多服务变更相对较少。
 
-**待续……**
+部署基于微服务的应用程序也是非常地复杂。一个单体应用可以很容易地部署到基于传统负载均衡器的一组相同的服务器上。每个应用程序实例都配置有基础设施服务的位置（主机和端口），比如数据库和消息代理。相比之下，微服务应用程序通常由大量的服务组成。例如，据 [Adrian Cockcroft](https://twitter.com/adrianco)，Hailo 拥有 160 个不同的服务，Netflix 拥有超过 600 个服务。
+
+每个服务都有多个运行时实例。还有更多的移动部件需要配置、部署、扩展和监控。此外，您还需要实现服务发现机制，使得服务能够发现需要与之通信的任何其他服务的位置（主机和端口）。传统比较麻烦的基于票据（ticket-based）和手动操作方式无法扩展到如此复杂程度。因此，成功部署微服务应用程序要求开发人员能高度控制部署方式和高度自动化。
+
+一种自动化的方式是使用现成的平台即服务（PaaS），如 [Cloud Foundry](https://www.cloudfoundry.org/)。PaaS 为开发人员提供了一种简单的方式来部署和管理他们的微服务。它让开发人员避开了诸如采购和配置 IT 资源等烦恼。同时，配置 PaaS 的系统与网络专业人员可以确保最佳实践和落实公司策略。
+
+自动化微服务部署的另一个方式是开发自己的 PaaS。一个普遍的起点是使用集群方案，如 [Kubernetes](https://kubernetes.io/)，与 Docker 等容器技术相结合。在本书最后我们将看到[基于软件的应用交付](http://www.nginx.com/products/)方式如 NGINX 是如何在微服务级别处理缓存、访问控制、API 计量和监控，可以帮助解决这个问题。
+
+## 1.6、总结
+构建复杂的微服务应用程序本质上是困难的。单体架构模式只适用于简单、轻量级的应用程序，如果您使用它来构建复杂应用，您最终会陷入一个痛苦的世界。微服务架构模式是复杂、持续发展应用的一个更好的选择。尽管它存在着缺点和实现挑战。
+
+在后面的章节中，我将介绍微服务架构的方方面面并探讨诸如服务发现、服务部署方案以及将单体应用重构为服务的策略。
+
+## 微服务实战：NGINX Plus 作为反向代理服务器
+10000 个网站中有超过 50% 使用 NGINX，这主要是因为它具有作为反向代理服务器的能力。您可以 NGINX 放在当前应用程序前面甚至是数据库服务器以获取各种功能 —— 更高的性能、更高的安全性、可扩展性、灵活性等。你现有的应用程序只需要配置代码和作出很少或无需改变。对于存在性能压力的站点，或者预计未来存在高负荷，效果看起来似乎没那么神奇。
+
+那么这与微服务有什么关系呢？实现一个反向代理服务器，并使用 NGINX 的其他功能来为您提供架构灵活性。反向代理服务器、静态和应用文件缓存、SSL/TLS 和 HTTP/2 都会从您的应用程序剔除。让应用程序只做它该做的事，NGINX 还可作为负载均衡器，微服务实施过程中的一个关键角色。先进的 NGINX Plus 的功能包含了复杂的负载均衡算法、多种方式的会话持久和管理监控，这些对微服务尤其有用（NGINX 最近还增加了使用 DNS SRV 记录的服务发现支持，这是一个顶尖的功能）。而且，如本章所述，NGINX 可以自动化部署微服务。
+
+此外，NGINX 还提供了必要的功能来支撑 NGINX 微服务参考架构中的三大模型。代理模型使用 NGINX 作为 API 网关；网格路由模型使用了一个额外的 NGINX 作为进程间通信中枢；Fabric 模型中每个微服务使用一个 NGINX 来控制 HTTP 流量，在微服务之间实现 SSL/TLS，这非常具有突破性。