从单体架构迁移到微服务架构：三种策略描述

迁移到微服务概述 将单体应用程序迁移到微服务架构意味着一系列现代化过程，有点像几代开发人员实时所做的事情，以便在迁移时我们可以重用一些想法。 一种策略是：不要一次性重写代码（仅当您负责重建新的基于微服务的应用程序时）。重写代码听起来不错，但实际上充满风险，最终可能会失败。正如马丁·福勒所说：“大爆炸重写唯一保证的就是大爆炸！” 相反，应该采取逐步迁移单体应用的策略，通过逐步生成新的微服务应用并将其与旧的单体应用集成。随着时间的推移，单体应用在整个架构中所占的比例逐渐减少，直至消失或成为微服务架构的一部分。这个策略有点像在高速公路上限速设置为 70 英里/小时时对汽车进行维护。虽然存在挑战，但比重写风险要小得多。 Martin Fowler 将这种现代策略称为“绞杀者”应用程序，以雨林中的绞杀者藤蔓命名，也称为“绞杀者无花果”。绞杀藤必须在叔叔周围生长才能爬到森林的顶端。过了一会儿，树就死了，留下树形的藤蔓。此类应用也使用相同的模型。新的微服务应用是围绕传统应用开发的，传统应用将逐渐退出舞台。 让我们看看其他可能的策略。 策略 1 – 停止挖掘 洞定律说，当你掉进洞里时，你应该停止挖掘。当单体应用程序难以管理时，这是最好的建议。换句话说，我们应该停止让单体应用程序继续增长，这意味着在开发新功能时，我们不应该向旧的单体应用程序添加新代码。最好的方法应该是将新功能开发成独立的微服务。如下所示： 完美叙述" src="http://www.sychzs.cn/large/pgc-image/06d58a621e994a15a94749ea4c66e058" _fcksavedurl="http://www.sychzs.cn/large/pgc-image/06d58a621e994a15a94749ea4c66e058" _f cksaved网址=“http ：//www.sychzs.cn/large/pgc-image/06d58a621e994a15a94749ea4c66e058“宽度=“640”高度=“541”> 除了新服务和传统应用之外，还有两个模块。一个是请求路由器，负责处理入口（http）请求，有点像之前提到的API网关。路由器向新开发的服务发送新功能请求，向整体应用程序发送旧请求。 另一种是胶水代码，它将微服务和单一应用程序集成在一起。微服务很少独立存在，并且经常访问来自单个应用程序的数据。粘合代码可能位于整体应用程序中，也可能位于服务中，或者两者兼而有之，负责数据集成。微服务通过粘合代码从整体应用程序读取和写入数据。 微服务可以通过三种方式访问​​单个应用程序数据： 通风装置应用程序提供的远程API 直接访问单个应用程序数据库 维护从单个应用程序同步的数据副本 胶水代码也被称为反腐败层，因为它保护微服务的新领域模型免受传统单体应用程序领域模型的污染。粘合代码提供了这两个模型之间的转换功能。反腐败层一词首次出现在埃里克·埃文斯 (Eric Evans) 的必读《领域驱动设计》中，随后被提炼成白皮书。开发灾难恢复层可能有些微不足道，但它是避免陷入单一泥潭的必要组成部分。 将新功能实现为轻量级微服务有很多优点，例如防止单体应用程序变得更加难以管理。微服务本身可以独立开发、部署和扩展。采用微服务架构将会给开发者带来不一样的体验。 然而，这种方法并没有解决整体结构本身的任何问题。为了解决单体应用本身的问题，必须对单体应用进行深入的改变。让我们看看执行此操作的策略。 策略2——前后端分离 降低整体应用程序复杂性的策略是将表示层与业务逻辑和数据访问层分离。典型的企业应用程序至少包含三个不同的元素： 表示层 - 处理 HTTP 请求，响应 RESTAPI 请求或提供基于 HTML 的图形界面。对于复杂的用户界面应用程序，表示层通常是代码的重要部分。 业务逻辑层——完成业务逻辑的应用核心。 数据访问层 - 访问数据库和消息代理等基本元素。 表示层和业务数据访问层之间有明显的分离。业务层有一个由几个方面组成的粗粒度API，其中包含业务逻辑元素。 API是一种天然的边界，可以将单个业务拆分为两个较小的应用程序，其中一个是表示层，另一个是业务和数据访问逻辑。拆分后，性能逻辑应用远程调用业务逻辑应用。下图展示了迁移前后的不同架构：​ 完美叙述” src="http://www.sychzs.cn/large/pgc-image/ce2dd2e1adaa4966b3ed87f1b07a15dd" _fcksavedurl="http://www.sychzs.cn/large/pgc-image/ce2dd2e1adaa4966b3ed87f1b07a15dd" _fcksavedurl="http: //www.sychzs.cn/large/pgc-image/ce2dd2e1adaa4966b3ed87f1b07a15dd“宽度=“640”高度=“388”> 以这种方式划分单个应用程序有两个优点。首先，它使应用程序两部分的开发、部署和扩展相互独立。特别是，它允许表现层开发人员在用户界面上快速选择并进行A/B测试；其次，它使得一些Remote API可以被微服务调用。 然而，这种策略只是部分解决方案。应用程序的一个或两个部分可能无法管理，因此需要第三种策略来消除剩余的整体。 策略 3 – 提取服务 第三种迁移策略是从单体应用中提取某些模块并成为独立的微服务。每当一个模块被提取出来并变成一个微服务时，单体应用程序就会变得更简单；一旦转换了足够多的模块，单体应用程序本身就不再成为问题，并且要么消失，要么变得简单到足以成为一项服务。 排序哪些模块应该转换为微服务 一个巨大的复杂的单一应用程序由数十或数百个模块组成，每个模块都是一个提取的对象。决定要提取的第一个模块通常是一个挑战，通常最好从最容易提取的模块开始。这将使开发人员积累足够的经验，而这些经验可以为后续的模块化工作带来巨大的好处。 将模块转换为微服务通常非常耗时。一般可以按照受益程度进行排序。一般来说，从频繁更改的模块开始将受益最多。一旦模块转换为微服务，就可以将其开发并部署为独立的模块，从而加快开发过程。 首先提取大资源消耗者也是排序标准之一。例如，将内存数据库提取到可以部署在大内存主机上的微服务中会很有用。同样，抽象计算密集型的算法应用程序也是有益的，这样这些服务就可以部署在具有许多 CPU 的主机上。通过将资源消耗模块转换为微服务，可以轻松扩展应用程序。 寻找现有的粗粒度边界来决定应该提取哪些模块也是有益的，从而使移植变得更加容易和简单。例如，仅与其他应用程序异步同步消息的模块是一个明显的边界，可以轻松转换为微服务。 如何提取模块 提取模块的第一步是定义模块和单个应用程序之间的粗粒度接口。由于单个应用程序需要微服务的数据，反之亦然，因此它更像是双向 API。开发这种 API 具有挑战性，因为您必须在处理依赖关系与细粒度接口模式之间取得平衡，特别是对于使用领域模型模式的业务逻辑层，并且通常需要更改代码来解决它。依赖问题，如图： 一旦粗粒度接口完成，这个模块就转变成一个独立的微服务。为了实现这一点，必须编写代码以允许使用进程间通信 (IPC) 机制通过 API 在整体应用程序和微服务之间交换信息。如图所示迁移前后对比： 完美叙述” src="http://www.sychzs.cn/large/pgc-image/154c174a35e0472a86e558deee9d9eee" _fcksavedurl="http://www.sychzs.cn/large/pgc-image/154c174a35e0472a86e558deee9d9eee" _fcksaved url="http ：//www.sychzs.cn/large/pgc-image/154c174a35e0472a86e558deee9d9eee“宽度=“640”高度=“859”> 在此示例中，使用 Y 模块的 Z 模块是替代提取模块，其元素正由 X 模块使用。迁移的第一步是定义一组粗粒度的 API。第一个接口应该是X模块使用的内部接口。 ，用于激活Z模块；第二个接口是Z模块使用的外部接口，用于激活Y模块。 迁移的第二步是将模块转换为独立的服务。内部和外部接口都使用基于IPC机制的代码。 Z模块一般会集成到微服务基础框架中，解决割接过程中的问题，比如服务发现等。 提取模块后，您可以开发、部署和扩展另一个服务，该服务独立于单个应用程序和其他服务。您可以编写代码从头开始实现服务；在这种情况下，集成服务和单个应用程序的 API 代码成为灾难恢复层，在两个域模型之间进行转换。每抽取一个服务，你就向微服务的方向前进了一步。随着时间的推移，单体应用程序将变得越来越简单，允许用户添加更多独立的微服务。将现有应用程序迁移到具有微服务架构的现代应用程序不应该通过从头开始重写代码来实现。相反，应该通过逐步迁移来完成。需要考虑三种策略： 将新功能实现为微服务；将表示层与业务数据访问层分离；将现有模块提取到微服务中。随着微服务数量的不断增加，开发团队的弹性和效率将大大提高。