微服务：从设计到部署 (oopsguy.com) (z-library.sk, 1lib.sk, z-lib.sk)

📄 File Format: PDF

💾 File Size: 2.6 MB

📖 Read Online ⬇️ Download

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

📄 Page 1

0 作者：Chris Richardson Floyd Smith 译者：Oopsguy

📄 Page 2

微服务：从设计到部署 1 目录 关于本书 ............................................... 4 前言 ................................................... 5 1 微服务简介 ........................................... 7 1.1 构建单体应用 ....................................................... 7 1.2 走向单体地狱 ....................................................... 9 1.3 微服务 — 解决复杂问题 ............................................ 10 1.4 微服务的优点 ...................................................... 14 1.5 微服务的缺点 ...................................................... 15 1.6 总结 .............................................................. 16 微服务实战：NGINX Plus 作为反向代理服务器 .............................. 16 2 使用 API 网关 ....................................... 18 2.1 简介 .............................................................. 18 2.2 客户端与微服务直接通信 ............................................ 20 2.3 使用 API 网关 ..................................................... 21 2.4 API 网关的优点与缺点 .............................................. 23 2.5 实施 API 网关 ..................................................... 23 2.5.1 性能与可扩展性 ................................................ 23 2.5.2 使用响应式编程模型 ............................................ 24 2.5.3 服务调用 ...................................................... 24 2.5.4 服务发现 ...................................................... 24 2.5.5 处理局部故障 .................................................. 25 2.6 总结 .............................................................. 25 微服务实战：NGINX Plus 作为 API 网关 ................................... 25 3 进程间通信 .......................................... 27

📄 Page 3

微服务：从设计到部署 2 3.1 简介 .............................................................. 27 3.2 交互方式 .......................................................... 28 3.3 定义 API .......................................................... 30 3.4 演化 API .......................................................... 30 3.5 处理局部故障 ...................................................... 31 3.6 IPC 技术 .......................................................... 32 3.7 异步、基于消息的通信 .............................................. 32 3.8 同步的请求/响应 IPC ............................................... 34 3.8.1 REST .......................................................... 34 3.8.2 Thrift ........................................................ 36 3.9 消息格式 .......................................................... 37 3.10 总结 ............................................................. 37 微服务实战：NGINX 与应用程序架构 ....................................... 38 4 服务发现 ............................................ 39 4.1 为何使用服务发现 .................................................. 39 4.2 客户端发现模式 .................................................... 40 4.3 服务端发现模式 .................................................... 42 4.4 服务注册中心 ...................................................... 43 4.5 服务注册方式 ...................................................... 44 4.6 自注册模式 ........................................................ 44 4.7 第三方注册模式 .................................................... 45 4.8 总结 .............................................................. 46 微服务实战：NGINX 的灵活性 ............................................. 47 5 事件驱动数据管理 .................................... 48 5.1 微服务和分布式数据管理问题 ........................................ 48 5.2 事件驱动架构 ...................................................... 50 5.3 实现原子性 ........................................................ 52 5.4 使用本地事务发布事件 .............................................. 53 5.5 挖掘数据库事务日志 ................................................ 54 5.6 使用事件溯源 ...................................................... 55 5.7 总结 .............................................................. 56

📄 Page 4

微服务：从设计到部署 3 微服务实战：NGINX 与存储优化 ........................................... 56 6 选择部署策略 ........................................ 57 6.1 动机 .............................................................. 57 6.2 单主机多服务实例模式 .............................................. 57 6.3 每个主机一个服务实例模式 .......................................... 59 6.3.1 每个虚拟机一个服务实例模式 .................................... 59 6.3.2 每个容器一个服务实例模式 ...................................... 61 6.4 Serverless 部署 ................................................... 63 6.5 总结 .............................................................. 64 微服务实战：使用 NGINX 在不同主机上部署微服务 .......................... 64 7 重构单体为微服务 .................................... 65 7.1 微服务重构概述 .................................................... 65 7.2 策略一：停止挖掘 .................................................. 66 7.3 策略二：前后端分离 ................................................ 68 7.4 策略三：提取服务 .................................................. 69 7.4.1 优先将哪些模块转换为微服务 .................................... 69 7.4.2 如何提取模块 .................................................. 69 7.5 总结 .............................................................. 71 微服务实战：用 NGINX 征服单体 .......................................... 71

📄 Page 5

微服务：从设计到部署 4 关于本书 Oopsguy 本书为 Chris Richardson 和 Floyd Smith 联合编写的微服务电子书 Designing and Deploying Microservices 中文版，其从不同角度全面介绍了微服务：微服务的优点 与缺点、API 网关、进程间通信（IPC）、服务发现、事件驱动数据管理、微服务部署 策略、重构单体。  github 仓 库 ： https://github.com/oopsguy/microservices-from-design-to- deployment-chinese  在线阅读：http://oopsguy.com/books/microservices 本书对 Nginx 的描述不是很多，主要针对微服务领域。如果您想了解更多关于 Nginx 的内容，请参阅正在更新的 Nginx 中文文档。 本书为开源电子书，采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协 议进行许可。 这是本人第一次尝试书籍翻译，由于个人外文基础不太好，中文文笔功底尚欠火候， 书中难免存在错误与遗漏，欢迎大家批评指正，互相学习进步。如果本书存在错误之 处或者您在书中发现有侵犯您权益的内容，请联系我进行处理。  昵 称：向阳  邮 箱：oopsguy@foxmail.com  微 信：oopsguy  博 客：http://oopsguy.com  Github：http://github.com/oopsguy 写于 2017 年 10月 07 日

📄 Page 6

微服务：从设计到部署 5 前言 Floyd Smith 近年来，微服务在应用开发和部署方面取得了显著的进步。将应用开发或者重构成微 服务以分离服务，通过 API 以明确的方式来相互“对话”。例如，每个微服务都是自 包含（self-contained），各自维护自己的数据存储（这非常有意义），可以独立更新 其他服务。 使用基于微服务的方式使得应用程序开发变得更快更容易管理，它只需要较少的人力 就能实现更多的功能，可以更快更容易地部署。把应用程序设计成一套微服务，更加 容易在多台具有负载均衡的服务器上运行，使其能够轻松应对需求高峰、由于时间推 移而平稳增长的需求和由于硬件或者软件问题导致的宕机事故。 微服务的最大进步在于改变了我们的工作方式。敏捷软件开发技术、应用迁移云端、 DevOps 文化、持续集成与持续部署（CI/CD）和容器应用都使用了微服务来革新应用 开发与交付。 无论是作为反向代理还是高性能的 web 服务器，NGINX 软件都与微服务和上述列出的 所有技术有着紧密联系。NGINX 使得基于微服务的应用更加易于开发，确保了微服务 解决方案能顺利运行。 随着 NGINX 与微服务之间的关系日渐紧密，我们已经在 NGINX 网站上运行了一个由 Chris Richardson 所写的七部分系列微服务。他很早就参与了设计与实现，他的博文 主要涵盖了微服务应用设计与开发方面的内容，包括了如何从单体应用迁移至微服务。 博文提供了关于微服务问题的全面概述，非常受欢迎。 在本书中，我们已经将全篇博文转换成章节，并在每一章节添加了尾栏以展示 NGINX 实现微服务的相关内容。如果您认真听取建议，您将解决许多潜在的开发时甚至是在 编写代码之前可能遇到的问题。此书在关于 NGINX 微服务参考架构 方面也是一本非常不错的书籍，其实现了以下提出的大部分理 论。

📄 Page 7

微服务：从设计到部署 6 本书章节：  微服务简介 从被夸大的微服务概念到如何在创建和维护应用时部署微服务进行简单介绍。  使用 API 网关 API 网关是整个微服务应用的单入口，它为每一个微服务提供了 API。NGINX Plus 可以很好地应用于 API 网关，提供了负载均衡和静态文件缓存等功能。  微服务架构中的进程间通信 当把一个单体应用分解成几部分（微服务），他们就需要相互通信。事实上有许多 进程间通信的方案可供您选择，包括表述性状态转义（REST）。本章将给出详细介 绍。  微服务架构中的服务发现 当服务运行在一个动态环境中，想要找到他们并不是一件简单的事情。  微服务事件驱动数据管理 每个微服务维护着自己特有的数据展示与存储，而不是共享一个统一、跨越一个 （或两个）单体应用的数据存储。虽然这能给予您很大的灵活性，但也可能导致 变得复杂。本章可以帮助您理清这些问题。  选择微服务部署策略 在 DevOps 世界中，您怎样做与您最初要做的事一样重要。Chris 讲解了微服务部 署的主要模式，以便您可以为您的应用作出合理的选择，  重构单体应用为微服务 在理想世界里，我们不会缺少时间与金钱，因此可以将核心软件转化为最新最好 的技术、工具和方法。而您可能会发现自己正在将一个单体应用转化为微服务， 而且进展非常缓慢……。Chris 在本章将为您讲解明智的做法。 我们认为您将会发现本书的每一章都是值得阅读的，我们希望当您在开发自己的微服 务应用时，能应用到本书的内容。 Floyd Smith，NGINX 公司

📄 Page 8

微服务：从设计到部署 7 1 微服务简介 如今微服务倍受关注：文章、博客、社交媒体讨论和会议演讲。微服务正在迅速朝着 加德纳技术成熟度曲线（Gartner Hype cycle）的高峰前进。与此同时，也有持怀疑 态度的软件社区人员认为微服务没什么新鲜可言。反对者声称它的思想只是面向服务 架构（SOA）的重塑。然而，无论是炒作还是怀疑，不可否认，微服务架构模式具有非 常明显的优势 — 特别是在实施敏捷开发和复杂的企业应用交付方面。 本书的七个章节主要介绍如何设计、构建和部署微服务，这是本书的第一章。在此章 节中，您将了解到微服务的由来和与传统单体应用模式的对比。这本电子书描述了许 多关于微服务架构方面的内容。无论是在项目意义还是实施方面，您都能了解到微服 务架构模式的优点与缺点。 我们先来看看为什么要考虑使用微服务。 1.1 构建单体应用 我们假设，您开始开发一个打车应用，打算与 Uber 和 Hailo 竞争。经过初步交流和 需求收集，您开始手动或者使用类似 Rails、Spring Boot、Play 或者 Maven 等平台 来生成一个新项目。 该新应用是一个模块化的六边形架构，如图 1-1 所示：

📄 Page 9

微服务：从设计到部署 8 图 1-1、一个简单的打车应用 该应用的核心是由模块实现的业务逻辑，它定义了服务、领域对象和事件。围绕核心 的是与外部世界接口对接的适配器。适配器示例包括数据库访问组件、生产和消费消 息的消息组件和暴露了 API 或实现了一个 UI 的 web 组件。 尽管有一个逻辑模块化架构，但应用程序被作为一个单体进行打包和部署。实际格式 取决于应用程序的语言和框架。例如，许多 Java 应用程序被打包成 WAR 文件部署在 如 Tomcat 或者 Jetty 之类的应用服务器上。其他 Java 应用程序被打包成自包含 （self-contained）的可执行 JAR。类似地，Rails 和 Node.js 应用程序被打包为有 目录层次的结构。 以这种风格编写的应用是很常见的。他们很容易开发，因为我们的 IDE 和其他工具就 是专注于构建单体应用。这些应用程序也很容易测试，您可以通过简单地启动并使用 如 Selenium 测试包来测试 UI 以轻松地实现端到端（end-to-end）测试。单体应用

📄 Page 10

微服务：从设计到部署 9 同样易于部署。您只需拷贝打包好的应用程序到服务器上。您还可以通过运行多个副 本和结合负载均衡器来扩展应用。在项目的早期阶段，它可以良好运作。 1.2 走向单体地狱 不幸的是，这种简单的方法有很大的局限性。成功的应用有一个趋势，随着时间推移 而变得越来越臃肿。您的开发团队在每个冲刺阶段都要实现更多的用户需求，这意味 着需要添加了许多行代码。几年之后，小而简单的应用将会逐渐成长成一个庞大的单 体。为了给出一个极端示例，我最近和一位开发者做了交谈，他正在编写一个工具， 该工具用于从他们的数百万行代码（lines of code，LOC）应用中分析出数千个 JAR 之间的依赖。我相信这是大量开发者在多年齐心协力下创造出了这样的野兽。 一旦您的应用程序成为了一个庞大、复杂的单体，您的开发组织可能会陷入了一个痛 苦的境地，敏捷开发和交付的任何一次尝试都将原地徘徊。一个主要问题是应用程序 实在非常复杂。对于任何一个开发人员来说显得过于庞大，这是可以理解的。最终， 正确修复 bug 和实现新功能变得非常困难而耗时。此外，这种趋势就像是往下的螺旋。 如果基本代码都令人难以理解，那么改变也不会变得正确，您最终得到的将是一个巨 大且不可思议的大泥球。 应用程序的规模也将减缓发展。应用程序越大，启动时间越长。我调查过开发者们的 单体应用的大小和性能，一些报告的启动时间为 12 分钟。我也听说过应用程序启动 需要 40 分钟以上的怪事。如果开发人员经常要重启应用服务器，那么很大一部分时 间都是在等待中度过，他们的生产力将受到限制。 另一个大问题是，复杂的单体应用本身就是持续部署的障碍。如今，SaaS 应用发展到 了可以每天多次将变更推送到生产环境中。这对于复杂的单体来说非常困难，因为您 需要重新部署整个应用程序才能更新其中任何一部分。联想到我之前提到的漫长启动 时间，这也不会是什么好事。此外，因变更所产生的影响通常不是很明确，您很可能 需要做大量的手工测试。因此，持续部署是不可能做到的。 当不同模块存在资源需求冲突时，单体应用可能难以扩展。例如，一个模块可能会执 行 CPU 密集型图像处理逻辑，理想情况下是部署在 Amazon EC2 Compute Optimized 实例中。另一个模块可能是一个内存数据库，最适合部署到 EC2 Memory-optimized 实 例。然而，由于这些模块被部署在一起，您必须在硬件选择上做出妥协。 单体应用的另一个问题是可靠性。因为所有模块都运行在同一进程中。任何模块的一 个 bug，比如内存泄漏，可能会拖垮整个进程。此外，由于应用程序的所有实例都是 相同的，该错误将影响到整个应用的可用性。 最后但同样重要，单体应用使得采用新框架和语言变得非常困难。例如，我们假设您 有 200 万行代码使用了 XYZ 框架编写。如果使用较新的 ABC 框架来重写整个应用，

📄 Page 11

微服务：从设计到部署 10 这将非常昂贵（在时间和成本方面），即使框架非常好。因此，这对于采用新技术是一 个非常大的障碍。在项目开始时，您无论选择何种新技术都会感到困扰。 总结一下：您有一个成功的关键业务应用程序，它已经发展成为一个只有少数开发人 员（如果有的话）能够理解的巨大单体。它使用了过时、非生产性技术编写，这使得 招聘优秀开发人员变得非常困难。应用程序变得难以扩展，不可靠。因此敏捷开发和 应用交付是不可能的。 那么您能做些什么呢？ 1.3 微服务 — 解决复杂问题 许多如 Amazon、eBay 和 Netflix 这样的组织，已经采用现在所谓的微服务架构模式 解决了这个问题，而不是构建一个臃肿的单体应用。它的思路是将应用程序分解成一 套较小的互连服务。一个服务通常实现了一组不同的特性或功能，例如订单管理、客 户管理等。每一个微服务都是一个迷你应用，它自己的六边形架构包括了业务逻辑以 及多个适配器。 一些微服务会暴露一个供其他微服务或应用客户端消费的 API。其他微服务可能实现 了一个 web UI。在运行时，每个实例通常是一个云虚拟机（virtual machine，VM） 或者一个 Docker 容器。 例如，前面描述的系统可能分解成如图 1-2 所示：

📄 Page 12

微服务：从设计到部署 11 图 1-2、一个单体应用分解成微服务 应用程序的每个功能区域现在都由自己的微服务实现。此外，Web 应用程序被划分为 一组更简单的 Web 应用程序。例如，以我们的出租车为例，一个是乘客的应用，一个 是司机的应用。这使得它更容易地为特定的用户、司机、设备或者专门的用例部署不 同的场景。每个后端服务暴露一个 REST API，大部分服务消费的 API 由其他服务提供。 例如，Driver Management 使用了 Notification 服务器来通知一个可用司机一个可 选路程。UI 服务调用了其他服务来渲染页面。服务也可以使用异步、基于消息的通信。 本电子书后面将会更加详细介绍服务间通信。 一些 REST API 也暴露给移动端应用以供司机和乘客使用。然而，应用不能直接访问 后端服务。相反，他们之间的通信是由一个称为 API 网关（API Gateway）的中介负 责。API 网关负责负载均衡、缓存、访问控制、API 计量和监控，可以通过使用 NGINX 来实现。第二章将详细讨论 API 网关。

📄 Page 13

微服务：从设计到部署 12 图 1-3、开发和交付中的伸缩立方（Scale Cube） 微服务架构模式相当于此伸缩立方的 Y 轴坐标，此立方是一个来自《架构即未来》的 三维伸缩模型。另外两个坐标轴是由运行多个相同应用程序副本的负载均衡器组成的 X 轴坐标和 Z 轴坐标（或数据分区），其中请求的属性（例如，一行记录的主键或者 客户标识）用于将请求路由到特定的服务器。 应用程序通常将这三种类型的坐标方式结合一起使用。Y 轴坐标将应用分解成微服务， 如图 1-2 所示。

📄 Page 14

微服务：从设计到部署 13 在运行时，X 坐标轴上运行着服务的多个实例，每个服务配合负载均衡器以满足吞吐 量和可用性。某些应用程序也有可能使用 Z 坐标轴来进行分区服务。图 1-4 展示了 如何用 Docker 将 Trip Management 服务部署到 Amazon EC2 上运行。 图 1-4、使用 Docker 部署 Trip Management 服务 在运行时，Trip Management 服务由多个服务实例组成，每个服务实例是一个 Docker 容器。为了实现高可用，容器是在多个云虚拟机上运行的。服务实例的之前是一个类 似 NGINX 的负载均衡器，用于跨实例分发请求。负载均衡器也可以处理其他问题，如 缓存、访问控制、API 度量和监控。 微服务架构模式明显影响到了应用程序与数据库之间的关系。与其他共享单个数据库 模式（schema）服务有所不同，其每一个服务都有自己的数据库模式。一方面，这种 做法与企业级数据库数据模型的想法相背，此外，它经常导致部分数据冗余。然而， 如果您想从微服务中受益，每一个服务都应该有自己的数据库模式。因为它能实现松 耦合。图 1-5 展示了数据库架构示例应用程序。 每个服务都拥有各自的数据库。而且，服务可以使用一种最适合其需求、号称多语言 持久架构（ polyglot persistence architecture）的数据库。例如， Driver Management，要找到与潜在乘客接近的司机，就必须使用支持高效地理查询的数据库。

📄 Page 15

微服务：从设计到部署 14 图 1-5、打车应用的数据库架构 从表面上看，微服务架构模式类似于 SOA。微服务是由一组服务组成。然而，换另一 种方式去思考微服务架构模式，它是没有商业化的 SOA，没有集成 Web 服务规范（WS- *）和企业服务总线（Enterprise Service Bus，ESB）。基于微服务的应用支持更简单、 轻量级的协议，例如，REST，而不是 WS-*。他们也尽量避免使用 ESB，而是实现微服 务本身具有类似 ESB 的功能。微服务架构也拒绝了 SOA 的其他部分，例如，数据访 问规范模式概念。 1.4 微服务的优点 微服务架构模式有许多非常好的地方。第一，它解决了复杂问题。它把可能会变得庞 大的单体应用程序分解成一套服务。虽然功能数量不变，但是应用程序已经被分解成 可管理的块或者服务。每个服务都有一个明确定义边界的方式，如远程过程调用（RPC） 驱动或者消息驱动的 API。微服务架构模式强制一定程度的模块化，实际上，使用单 体代码来实现是极其困难的。因此，使用微服务架构模式，个体服务能被更快地开发， 并更容易理解与维护。 第二，这种架构使得每个服务都可以由一个团队独立专注开发。开发者可以自由选择 任何符合服务 API 契约的技术。当然，更多的组织是希望通过技术选型限制来避免完 全混乱的状态。然而，这种自由意味着开发人员不再有可能在这种自由的新项目开始 时使用过时的技术。当编写一个新服务时，他们可以选择当前的技术。此外，由于服 务较小，使用当前技术重写旧服务将变得更加可行。

📄 Page 16

微服务：从设计到部署 15 第三，微服务架构模式可以实现每一个微服务独立部署。开发人员根本不需要去协调 部署本地变更到服务。这些变更一经测试即可立即部署。比如，UI 团队可以执行 A|B 测试，并快速迭代 UI 变更。微服务架构模式使得持续部署成为可能。最后，微服务 架构模式使得每个服务能够独立扩展。您可以仅部署满足每个服务的容量和可用性约 束的实例数目。此外，您可以使用与服务资源要求最匹配的硬件。例如，您可以在 EC2 Compute Optimized 实例上部署一个 CPU 密集型图像处理服务，并且在 EC2 Memory-optimized 实例上部署一个内存数据库服务。 1.5 微服务的缺点 就像 Fred Brooks 大约在 30 年前写的《人月神话》中说的，没有银弹。与其他技术 一样，微服务架构模式也存在着缺点。其中一个缺点就是名称本身。微服务这个术语 的重点过多偏向于服务的规模。事实上，有些开发者主张构建极细粒度的 10 至 100 LOC（代码行） 服务，虽然对于小型服务可能比较好，但重要的是要记住，小型服务 只是一种手段，而不是主要目标。微服务的目标在于充分分解应用程序以方便应用敏 捷开发和部署。 微服务另一个主要的缺点是由于微服务是一个分布式系统，其使得整体变得复杂。开 发者需要选择和实现基于消息或者 RPC 的进程间通信机制。此外，由于目标请求可能 很慢或者不可用，他们必须要编写代码来处理局部故障。虽然这些都不是很复杂、高 深，但模块间通过语言级方法/过程调用相互调用，这比单体应用要复杂得多。 微服务的另一个挑战是分区数据库架构。更新多个业务实体的业务事务是相当普遍的。 这些事务在单体应用中的实现显得微不足道，因为单体只存在一个单独的数据库。在 基于微服务的应用程序中，您需要更新不同服务所用的数据库。通常不会选择分布式 事务，不仅仅是因为 CAP 定理。他们根本不支持如今高度可扩展的 NoSQL 数据库和消 息代理。您最后不得不使用基于最终一致性的方法，这对于开发人员来说更具挑战性。 测试微服务应用程序也很复杂。例如，使用现代框架如 Spring Boot，只需要编写一 个测试类来启动一个单体 web 应用程序并测试其 REST API。相比之下，一个类似的 测试类对于微服务来说需要启动该服务及其所依赖的所有服务，或者至少为这些服务 配置存根。再次声明，虽然这不是一件高深的事情，但不要低估了这样做的复杂性。 微服务架构模式的另一个主要挑战是实现了跨越多服务变更。例如，我们假设您正在 实现一个变更服务 A、服务 B 和 服务 C 的需求，其中 A 依赖于 B，且 B 依赖于 C。 在单体应用程序中，您可以简单地修改相应的模块、整合变更并一次性部署他们。相 反，在微服务中您需要仔细规划和协调出现的变更至每个服务。例如，您需要更新服 务 C，然后更新服务 B，最后更新服务 A。幸运的是，大多数变更只会影响一个服务； 需要协调的多服务变更相对较少。 部署基于微服务的应用程序也是非常复杂的。一个单体应用可以很容易地部署到基于 传统负载均衡器的一组相同服务器上。每个应用程序实例都配置有基础设施服务的位

📄 Page 17

微服务：从设计到部署 16 置（主机和端口），比如数据库和消息代理。相比之下，微服务应用程序通常由大量的 服务组成。例如，据 Adrian Cockcroft 了解到，Hailo 拥有 160 个不同的服务， Netflix 拥有的服务超过 600 个。 每个服务都有多个运行时实例。还有更多的移动部件需要配置、部署、扩展和监控。 此外，您还需要实现服务发现机制，使得服务能够发现需要与之通信的任何其他服务 的位置（主机和端口）。比较传统麻烦的基于票据（ticket-based）和手动的操作方式 无法扩展到如此复杂程度。因此，要成功部署微服务应用程序，需要求开发人员能高 度控制部署方式和高度自动化。 一种自动化方式是使用现成的平台即服务（PaaS），如 Cloud Foundry。PaaS 为开发 人员提供了一种简单的方式来部署和管理他们的微服务。它让开发人员避开了诸如采 购和配置 IT 资源等烦恼。同时，配置 PaaS 的系统人员与网络专业人员可以确保达到 最佳实践以落实公司策略。自动化微服务部署的另一个方式是开发自己的 PaaS。一个 普遍的起点是使用集群方案，如 Kubernetes，与 Docker 等容器技术相结合。在本书 最后我们将看到如 NGINX 的基于软件的应用交付方式是如何在微服务级别处理缓存、 访问控制、API 计量和监控，这些可以帮助解决此问题。 1.6 总结 构建复杂的微服务应用程序本质上是困难的。单体架构模式只适用于简单、轻量级的 应用程序，如果您使用它来构建复杂应用，您最终会陷入痛苦的境地。微服务架构模 式是复杂、持续发展应用的一个更好的选择。尽管它存在着缺点和实现挑战。 在后面的章节中，我将介绍微服务架构的方方面面并探讨诸如服务发现、服务部署方 案以及将单体应用重构为服务的策略。 微服务实战：NGINX Plus 作为反向代理服务器 By Floyd Smith 10000 个网站中有超过 50% 使用 NGINX，这主要是因为它具有作为反向代理服务器的 能力。您可以把 NGINX 放在当前应用程序甚至是数据库服务器之前以获取各种功能 — 更高的性能、 更高的安全性、可扩展性、灵活性等。您现有的应用程序只需要配置代码和作出很少 或无需改变。然而，对于存在性能压力的站点，或者预计未来存在高负荷，使用 NGINX 的效果看起来似乎没那么神奇。 那么这与微服务有什么关系呢？实现一个反向代理服务器，并使用 NGINX 的其他功能 来为您提供架构灵活性。反向代理服务器、静态和应用文件缓存、SSL/TLS 和 HTTP/2

📄 Page 18

微服务：从设计到部署 17 都会从您的应用程序剔除。让应用程序只做它该做的事，NGINX 还可作为负载均衡器， 这是微服务实施过程中的一个关键角色。先进的 NGINX Plus 的功能包含了复杂的负 载均衡算法、多种方式的会话持久和管理监控，这些对微服务尤其有用（NGINX 最近 还增加了使用 DNS SRV 记录的服务发现支持，这是一个顶尖的功能）。而且，如本章 所述，NGINX 可以自动化部署微服务。 此外，NGINX 还提供了必要的功能来支撑 NGINX 微服务参考架构中的三大模型。代理 模型使用 NGINX 作为 API 网关；网格路由模型使用一个额外的 NGINX 作为进程间通 信中枢；Fabric 模型中的每个微服务使用一个 NGINX 来控制 HTTP 流量，在微服务 之间实现 SSL/TLS，这非常具有突破性。

📄 Page 19

微服务：从设计到部署 18 2 使用 API 网关 本书的七个章节是关于如何设计、构建和部署微服务。第一章介绍了微服务架构模式。 它阐述了使用微服务的优点与缺点，以及尽管如此，微服务通常是复杂应用的理想选 择。该系列的第二章将探讨使用 API 网关构建微服务。 当您选择将应用程序构建成为一组微服务时，您需要决定应用程序客户端将如何与微 服务进行交互。单体应用程序只有一组端点（endpoint），通常使用复制（replicated） 结合负载均衡来分配流量。 然而，在微服务架构中，每个微服务都暴露一组通常比较细颗粒的端点。在本文中， 我们将研究如何改进客户端通信，并提出一个使用 API 网关的方案。 2.1 简介 我们假设您正在为一个购物应用开发一个原生移动客户端。您可能需要实现一个产品 详细信息页面，用于展示给定商品的信息。 例如，图 2-1 展示了在 Amazon 的 Android 移动应用中滚动产品信息时所看的内容。

📄 Page 20

微服务：从设计到部署 19 图 2-1、一个简单的购物应用 这是一个智能手机应用，产品详细信息页面展示了许多信息。不仅有基本的产品信息， 如名称、描述和价格，页面还展示了： 1. 购物车中的物品数量 2. 订单历史 3. 客户评价 4. 低库存警告 5. 配送选项 6. 各种推荐，包括了购买此产品的客户购买的其他产品 7. 选择性购买选项 在使用单体应用架构的情况下，移动客户端通过对应用程序进行单个 REST 调用来检 索此数据，例如： GET api.company.com/productdetails/productId 负载均衡器将请求路由到几个相同应用程序实例中的其中一个。之后，应用程序查询 各个数据库表并返回响应给客户端。相比之下，当使用微服务架构时，产品详细页面 上展示的数据来自多个微服务。以下是一些微服务，可能拥有特定产品页面展示的数 据：  订单服务 订单历史  目录（catalog）服务 基本的产品信息，如产品名称、图片和价格  评价服务 客户评价  库存服务 低库存警告  配送服务 配送选项、期限和费用，由配送方的 API 单独提供  推荐服务 推荐类目