本书主要介绍如何使用微服务构建应用程序，这是本书的第七章，也是最后一章。第一章介绍了微服务架构模式，讨论了使用微服务的优点与缺点。随后的章节讨论了微服务架构的方方面面：使用 API 网关、进程间通信、服务发现、事件驱动数据管理和部署微服务。在本章中，我们将介绍单体应用迁移到微服务的策略。 我希望这本电子书能够让您对微服务架构、其优点和缺点以及何时使用它有很好的了解。微服务架构也许很适合您的组织。 您正工作于大型复杂的单体应用程序上，这是相当不错的机会。然而，您开发和部署应用程序的日常经历是缓慢而痛苦的。微服务似乎是一个遥不可及的天堂。幸运的是，有一些策略可以用来逃离单体应用的地狱。在本文中，我将描述如何将单体应用程序逐渐重构为一组微服务。 7.1、微服务重构概述 单体应用程序转换为微服务的过程是应用程序现代化的一种形式。这是几十年来开发人员一直在做的事情。因此，在将应用程序重构为微服务时，有一些想法是可以重用的。 一个不要使用的策略是“大爆炸”重写。就是您将所有的开发工作都集中在从头开始构建新的基于微服务的应用程序。虽然这听起来很吸引人，但非常危险，有可能会失败。据 Martin Fowler 讲到：“大爆炸重写的唯一保证就是大爆炸！”（"the only thing a Big Bang rewrite guarantees is a Big Bang!"）。 您应该逐步重构单体应用程序，而不是通过大爆炸重写。您可以逐渐添加新功能，并以微服务的形式创建现有功能的扩展 — 以互补的形式修改单体应用，并且一同运行微服务和修改后的单体应用。随着时间推移，单体应用程序实现的功能量会缩小，直到它完全消失或变成另一个微服务。这种策略类似于在 70公里/小时的高速公路上驾驶一辆汽车，很具挑战性，但比尝试大爆炸改写的风险要小得多。 Martin Fowler 将这种应用现代化策略称为杀手应用（Strangler Application）。这个名字来自发现于热带雨林中的葡萄树（也称为绞杀榕）。一棵葡萄树生长在一棵树上，以获取森林冠层之上的阳光。有时，树死了，留下一个树形的腾。应用现代化也遵循相同的模式。我们将构建一个新的应用程序，包括了围绕遗留应用的微服务（它将会慢慢缩小或者最终消亡）。 让我们来看看能做到这点的不同策略。 7.2、策略一：停止挖掘 洞穴定律说到，每当您身处在一个洞穴中，您应该停止挖掘。当您的单体应用变得难以管理时，这是一个很好的建议。换句话说，您应该停止扩张，避免使单体变得更大。这意味着当您要实现新功能时，您不应该向单体添加更多的代码。相反，这一策略的主要思想是将新代码放在独立的微服务中。 应用此方法后，系统架构如图 7-1 所示。 除了新服务和遗留的单体应用，还有另外两个组件。第一个是请求路由，它处理传入的（HTTP）请求，类似于第二章中描述的 API 网关。路由向新服务发送与新功能相对应的请求。它将遗留的请求路由到单体应用。 另一个组件是粘合代码，它将微服务与单体应用集成。一个服务很少孤立存在，通常需要访问单体应用的数据。位于单体应用、微服务或两者中的粘合代码负责数据集成。该微服务使用粘合代码来读取和写入单体应用数据。 服务可以使用三种策略来访问单体应用的数据： 调用由单体应用提供的远程 API 直接访问单体应用的数据库 维护自己的数据副本，与单体应用的数据库同步 粘合代码有时被称为防护层（anti-corruption layer）。这是因为粘合代码阻止了服务被遗留的单体应用领域模型的概念所污染，这些服务拥有属于自己的新的领域模型。粘合代码在两种不同的模型之间转换。防护层一词首先出现于埃里克·埃文斯（Eric Evans）所著的必读图书《领域驱动设计》（Domain Driven Design）中，并在白皮书中进行了改进。开发一个防护层并不是一件简单的事情。但是，如果您想要从单体应用地狱中走出来，这是必不可少的步骤。 使用轻量级服务来实现新功能有几个好处。它防止单体变得更加难以管理。该服务可以独立于单体应用开发、部署和扩展。可让您创建的每个新服务体验到微服务架构的优势。 然而，这种方法没有解决单体应用的问题。要解决这些问题，您需要分解单体应用。让我们来看看这样做的策略。 7.3、策略二：前后端分离 缩小单体应用的一个策略是从业务逻辑层和数据访问层拆分出表现层。一个典型的企业应用由至少三种不同类型的组件组成： 表现层（Presentation Layer，PL） 处理 HTTP 请求并实现（REST）API 或基于 HTML 的 Web UI 组件。在具有复杂用户界面的应用中，表现层通常存在大量代码。 业务逻辑层（Business Logic Layer，BLL） 作为应用程序核心，实现业务规则的组件。 数据访问层（Data Access Layer，DAL） 访问基础架构组件的组件，如数据库和消息代理。 表现逻辑部分与业务和数据访问逻辑部分之间通常有一个清晰的界限。业务层具有由一个或多个门面组成的粗粒度 API，其封装了业务逻辑组件。这个 API 是一个天然的边界，您可以沿着该边界将单体应用拆分成两个较小的应用程序。一个应用程序包含表现层。另一个应用程序包含业务和数据访问逻辑。分割后，表现逻辑应用程序对业务逻辑应用程序进行远程调用。 重构之前和之后的架构如图 7-2 所示。 以这种方式拆分单体应用有两个主要优点。它使您能够独立于彼此开发、部署和扩展这两个应用。特别是它允许表现层开发人员在用户界面上快速迭代，并且可以轻松执行 A/B 测试。这种方法的另一个优点是它暴露了可以被微服务调用的远程 API。 然而，这一策略只是一个局部解决方案。两个应用程序中的一个或两个很可能在将来膨胀成一个无法管理的单体应用。您需要使用第三种策略来继续消减单体应用。 7.4、策略三：提取服务 第三个重构策略是将庞大的现有模块转变为独立的微服务。每次提取一个模块并将其转换成微服务时，单体就会缩小。一旦您转换了足够的模块，单体应用将不再是一个问题。或者它完全消失，或者变得小到可以被当做一个服务看待。 7.4.1、优先将哪些模块转换为微服务 […]
View Details本书主要介绍关于如何使用微服务构建应用程序，这是本书的第六章。第一章介绍了微服务架构模式，讨论了使用微服务的优点与缺点。之后的章节讨论了微服务架构的方方面面：使用 API 网关、进程间通信、服务发现和事件驱动数据管理。在本章中，我们将介绍部署微服务的策略。 6.1、动机 部署单体应用程序意味着运行一个或多个相同副本的单个较大的应用程序。您通常会配置 N 个服务器（物理或虚拟），每台服务器上会运行 M 个应用程序实例。单体应用程序的部署并不总是非常简单，但它比部署微服务应用程序要简单得多。 微服务应用程序由数十甚至上百个服务组成。服务以不同的语言和框架编写。每个都是一个迷你的应用程序，具有自己特定的部署、资源、扩展和监视要求。例如，您需要根据该服务的需求运行每个服务的一定数量的实例。此外，必须为每个服务实例提供相应的 CPU、内存和 I/O 资源。更具挑战性的是尽管如此复杂，部署服务也必须快速、可靠和具有成本效益。 有几种不同的微服务部署模式。我们首先看看单主机多服务实例模式。 6.2、单主机多服务实例模式 部署微服务的一种方式是使用单主机多服务实例（Multiple Service Instances per Host）模式。当使用此模式时，您可以提供一个或多个物理主机或虚拟主机，并在每个上运行多个服务实例。从多方面来讲，这是应用程序部署的传统方式。每个服务实例在一个或多个主机的标准端口上运行。主机通常被当作宠物对待。 图 6-1 展示了该模式的结构： 这种模式有几个变体。一个变体是每个服务实例都是一个进程或进程组。例如，您可以在 Apache Tomcat 服务器上将 Java 服务实例部署为 Web 应用程序。一个 Node.js 服务实例可能包含一个父进程和一个或多个子进程。 此模式的另一个变体是在同一进程或进程组中运行多个服务实例。例如，您可以在同一个 Apache Tomcat 服务器上部署多个 Java Web 应用程序，或在同一 OSGI 容器中运行多个 OSGI 软件包。 单主机多服务实例模式有优点也有缺点。主要优点是其资源使用率相对较高。多个服务实例共享服务器及其操作系统。如果进程或进程组运行了多个服务实例（例如，共享相同的 Apache Tomcat 服务器和 JVM 的多个 Web 应用程序），则效率更高。 这种模式的另一个优点是部署服务实例相对较快。您只需将服务复制到主机并启动它。如果服务是使用 Java 编写的，则可以复制 JAR 或 WAR 文件。对于其他语言，例如 Node.js 或 Ruby，您可以直接复制源代码。在任一情况下，通过网络复制的字节数都是相对较小的。 另外，由于缺乏开销，通常启动一个服务是非常快的。如果该服务是自己的进程，你只需要启动它即可。如果服务是在同一容器进程或进程组中运行的几个实例之一，则可以将其动态部署到容器中或者重新启动容器。 尽管这很有吸引力，但单主机多服务实例模式有一些明显的缺点。一个主要的缺点是服务实例很少或者没有隔离，除非每个服务实例是一个单独的进程。虽然您可以准确地监视每个服务实例的资源利用率，但是您不能限制每个实例使用的资源。一个行为不当的服务实例可能会占用掉主机的所有内存或 CPU。 如果多个服务实例在同一进程中运行，那么将毫无隔离可言。例如，所有实例可能共享相同的 JVM 堆。行为不当的服务实例可能会轻易地破坏在同一进程中运行的其他服务。此外，您无法监控每个服务实例使用的资源。 这种方式的另一个重要问题是部署服务的运维团队必须了解部署的具体细节。服务可以用多种语言和框架编写，因此开发团队必须与运维交代许多细节。这种复杂性无疑加大了部署过程中的错误风险。 正如您所见，尽管这种方式简单，但单主机多服务实例模式确实存在一些明显的缺点。现在让我们来看看可以绕过这些问题部署微服务的其他方式。 6.3、每个主机一个服务实例模式 部署微服务的另一种方式是使用每个主机一个服务实例（Service Instance per Host）模式。当使用此模式时，您可以在主机上单独运行每个服务实例。这种模式有两种不同形式：每个虚拟机一个服务实例模式和每个容器一个服务实例模式。 6.3.1、每个虚拟机一个服务实例模式 当您使用每个虚拟机一个服务实例模式时，将每个服务打包成一个虚拟机（VM）镜像（如 Amazon EC2 AMI）。每个服务实例都是一个使用该 VM 镜像启动的 VM（例如，一个 EC2 实例）。 图 6-2 展示了该模式的结构： 这是 Netflix 部署其视频流服务的主要方式。Netflix 使用 Aminator 将每个服务打包为 EC2 […]
View Details本书主要介绍如何使用微服务构建应用程序，这是本书的第五章。第一章介绍了微服务架构模式，讨论了使用微服务的优点与缺点。第二和第三章描述了微服务架构内通信方式的对比。第四章探讨了与服务发现相关的内容。在本章中，我们稍微做了点调整，研究微服务架构中出现的分布式数据管理问题。 5.1、微服务和分布式数据管理问题 单体应用程序通常具有一个单一的关系型数据库。使用关系型数据库的一个主要优点是您的应用程序可以使用 ACID 事务，这些事务提供了以下重要保障： 原子性（Atomicity） — 所作出的更改是原子操作，不可分割 一致性（Consistency） — 数据库的状态始终保持一致 隔离性（Isolation） — 即使事务并发执行，但他们看起来更像是串行执行 永久性（Durable） — 一旦事务提交，它将不可撤销 因此，您的应用程序可以很容易地开始事务、更改（插入、更新和删除）多行记录，并提交事务。 使用关系型数据库的另一大好处是它提供了 SQL，这是一种丰富、声明式和标准化的查询语言。您可以轻松地编写一个查询，组合来自多个表的数据，之后，RDBMS 查询计划程序将确定执行查询的最佳方式。您不必担心如何访问数据库等底层细节。因为您所有的应用程序数据都存放在同个数据库中，因此很容易查询。 很不幸的是，当我们转向微服务架构时，数据访问将变得非常复杂。因为每个微服务所拥有的数据对当前微服务来说是私有的，只能通过其提供的 API 进行访问。封装数据可确保微服务松耦合、独立演进。如果多个服务访问相同的数据，模式（schema）更新需要对所有服务进行耗时、协调的更新。 更糟糕的是，不同的微服务经常使用不同类型的数据库。现代应用程序存储和处理着各种数据，而关系型数据库并不总是最佳选择。在某些场景，特定的 NoSQL 数据库可能具有更方便的数据模型，提供了更好的性能和可扩展性。例如，存储和查询文本的服务使用文本搜索引擎（如 Elasticsearch）是合理的。类似地，存储社交图数据的服务应该可以使用图数据库，例如 Neo4j。因此，基于微服务的应用程序通常混合使用 SQL 和 NoSQL 数据库，即所谓的混合持久化（polyglot persistence）方式。 分区的数据存储混合持久化架构具有许多优点，包括了松耦合的服务以及更好的性能与可扩展性。然而，它也引入了一些分布式数据管理方面的挑战。 第一个挑战是如何实现业务的事务在多个服务之间保持一致性。要了解此问题，让我们先来看一个在线 B2B 商店的示例。Customer Service （顾客服务）维护客户相关的信息，包括信用额度。Order Service （订单）负责管理订单，并且必须验证新订单，不得超过客户的信用额度。在此应用程序的单体版本中，Order Service 可以简单地使用 ACID 事务来检查可用信用额度并创建订单。 相比之下，在微服务架构中，ORDER （订单）和 CUSTOMER （顾客）表对其各自的服务都是私有的，如图 5-1 所示： Order Service 无法直接访问 CUSTOMER 表。它只能使用客户服务提供的 API。订单服务可能使用了分布式事务，也称为两阶段提交（2PC）。然而，2PC 在现代应用中通常是不可行的。CAP 定理要求您在可用性与 ACID 式一致性之间做出选择，可用性通常是更好的选择。此外，许多现代技术，如大多数 NoSQL 数据库，都不支持 2PC。维护服务和数据库之间的数据一致性至关重要，因此我们需要另一套解决方案。 第二个挑战是如何实现从多个服务中检索数据。例如，我们假设应用程序需要显示一个顾客和他最近的订单。如果 Order Service 提供了用于检索客户订单的 API，那么您可以使用应用程序端连接以检索数据。应用程序从 Customer Service 中检索客户，并从 Order Service 中检索客户的订单。但是，假设 Order Service 仅支持通过主键查找订单（也许它使用了仅支持基于主键检索的 NoSQL 数据库）。在这种情况下，没有有效的方法来检索所需的数据。 5.2、事件驱动架构 许多应用使用了事件驱动架构作为解决方案。在此架构中，微服务在发生某些重要事件时发布一个事件，例如更新业务实体时。其他微服务订阅了这些事件，当微服务接收到一个事件时，它可以更新自己的业务实体，这可能导致更多的事件被发布。 您可以使用事件实现跨多服务的业务的事务。一个事务由一系列的步骤组成。每个步骤包括了微服务更新业务实体和发布一个事件来触发下一步骤。下图依次展示了如何在创建订单时使用事件驱动方法来检查可用信用额度。 微服务通过 Message Broker （消息代理）进行交换事件： Order Service （订单服务）创建一个状态为 NEW 的订单，并发布一个 […]
View Details