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