一、重构到微服务需要考虑的问题
1、为什么重构
单体地狱造成的业务问题：
- 交付缓慢
- 充满故障的软件交付
- 可扩展性差
2、重构形式
1、一步到位
你企图从零开始开发一个全新的基于微服务的应用程序（彻底替换遗留的单体应用）。虽然从头开始并抛弃老代码库听起来很有吸引力，但它的风险极高，很可能以失败告终。你将花费数月甚至数年来复制现有功能，然后才能实现业务今天就需要的功能!此外，无论如何，你都需要开发和维护老的应用程序，这会打乱重写的工作，并意味着你有一个不断变化的目标。更重要的是，你可能会浪费时间重新实现不再需要的功能。正如Martin Fowler所说的那样，“推倒重写的唯一保证，就是彻底搞砸一切”。
2、逐步绞杀
逐步构建一个新的、被称为绞杀者应用程序的应用。绞杀者应用程序由与单体应用程序结合使用的微服务组成。随着时间的推移，单体应用程序实现的功能数量会缩小，直到完全消失或者变成另一个微服务。这种策略类似于以70mph（约110km/h）的速度在高速公路上行驶时为汽车更换轮胎。这很有挑战性，但相比“一步到位，推倒重来”的风险要小得多。
Martin Fowler把这项策略称为绞杀者应用模式。这个名字来自在热带雨林中发现的绞杀者藤蔓
特点：
- 尽早且频繁的体现出价值
- 尽可能少对单体做出修改
- 不需要考虑过多的基础设置，但是需要保证拥有自动化测试的部署流水线
文章来源地址https://www.toymoban.com/news/detail-586500.html
3、重构策略
有三种主要策略可以实现对单体的“绞杀”，并逐步用微服务替换之：
1、将新功能实现为服务
- API Gateway：将对新功能的请求路由到新服务，并将遗留请求路由到单体。
- 集成胶水代码：将服务与单体结合。它使服务能够访问单体所拥有的数据，并能够调用单体实现的功能。
2、隔离表现层和后端。
将表现层与业务逻辑和数据访问层分开。典型的企业应用程序包含以下各层:
- 表现逻辑层：它由处理HTTP请求的模块组成，并生成实现Web UI的HTML页面。在具有复杂用户界面的应用程序中，表现层通常包含大量代码。
- 业务逻辑层：由实现业务规则的模块组成，这些模块在企业应用程序中可能很复杂。
- 数据访问逻辑层：包含访问基础设施服务（如数据库和消息代理）的模块。
以这种方式拆分单体应用有两个主要好处。它使你能够彼此独立地开发、部署和扩展这两个应用程序。特别是，它允许表现层开发人员快速迭代用户界面并轻松执行A/B测试，而无须部署后端。这种方法的另一个好处是它公开了业务逻辑的一组远程API，可以被稍后开发的微服务调用。
但这种策略只是部分解决方案。很可能至少有一个或两个最终的应用程序仍然是一个难以管理的单体。你需要使用第三种策略将单体替换为服务。
3、通过将功能提取到服务中来分解单体。
你想要提取到服务中的功能是对单体应用自上而下的一个“垂直切片”。该切片包含以下内容：
- 领域逻辑。
- 出站适配器，例如数据库访问逻辑。
- 单体的数据库模式。
提取服务具有挑战性。你需要确定如何将单体的领域模型分成两个独立的领域模型，其中一个模型成为服务的领域模型。你需要打破对象引用等依赖。你甚至可能需要拆分类，以将功能移动到服务中。你还需要重构数据库。
第一种策略阻止了单体的发展。它通常是一种快速展示微服务价值的方法，有助于让迁移和重构的工作获得公司内部各个层面支持。另外两种策略打破了单体。在重构单体时，你有时可能会使用第二种策略，但你肯定会使用第三种策略，因为它能实现将功能从单体迁移到绞杀者应用程序中。
二、设计服务与单体的协作方式
1、设计集成胶水
2、数据一致性
借助Saga
3、处理身份验证和访问授权文章来源：https://www.toymoban.com/news/detail-586500.html
三、总结
- 在迁移到微服务架构之前，确保你的软件交付问题是由于业务需求超出单体架构承载能力而导致的。在架构重构之前，你可以通过改进软件开发过程来加速交付。
- 通过逐步开发一个绞杀者应用程序来迁移到微服务非常重要。绞杀者应用程序是一个新的应用程序，由围绕现有单体应用构建的微服务组成。你应该尽早并经常证明自己的价值,以确保业务团队支持迁移工作。
- 将微服务引入架构的一个好方法是将新功能作为服务实现。这样做可以使你使用现代技术和开发过程快速轻松地开发功能。这是快速展示迁移到微服务价值的好方法。打破单体结构的一种方法是将表现层与后端隔离，这会产生两个较小的单体结构。虽然这不是一个巨大的改进，但它确实意味着你可以独立部署每个单体。例如，这允许用户界面团队更轻松地在用户界面设计上进行迭代,而不会影响后端。
- 打破单体的主要方法是逐步将功能从单体转移到服务中。重点是提取提供最大利益的服务。例如，如果提取实现正在积极开发功能的服务，你将加快开发速度。
- 新开发的服务几乎总是必须与单体交互。服务通常需要访问单体的数据并调用其功能。单体有时需要访问服务的数据并调用其功能。要实现此协作，需要开发集成胶水，其中包含单体的入站和出站适配器。
- 为了防止单体的领域模型污染服务的领域模型，集成胶水应该使用反腐层，这是一个在领域模型之间进行转换的软件层。
最小化对提取服务的单体结构的影响的一种方法是将移动到服务的数据复制回单体的数据库。由于单体的数据库模式保持不变，因此无须对单体代码库进行潜在的大范围修改。 - 开发服务通常需要你实现涉及单体的Saga。但实现可补偿性事务可能具有挑战性，需要对单体进行大范围的修改。因此，有时你需要仔细设计服务的提取顺序，以避免在单体中实现可补偿事务。
- 在重构为微服务架构时，你需要同时支持单体应用的现有安全机制，该机制通常基于内存的会话，以及服务使用的基于令牌的安全机制。幸运的是，一个简单的解决方案是修改单体的登录处理程序以生成包含安全令牌的cookie，然后由API Gateway转发给服务。
到了这里，关于《微服务架构设计模式》第十三章 微服务架构的重构策略的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
