从300万行到50万行代码,遗留系统的微服务改造(4)

本文涉及的产品
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
简介: 从300万行到50万行代码,遗留系统的微服务改造(4)

这种方案的优点是可以通过API隔离数据变化,避免新业务服务与原遗留系统数据之间的直接耦合。可以在API中实现对数据的处理逻辑,满足新业务服务的数据需求。API只对外提供新业务服务允许访问的数据域,从而实现数据权限的控制,更适用于数据库直接访问受限制的场景。但其引入的额外成本是需要在原遗留系统上增加API实现的工作,有时因为遗留系统的技术陈旧、结构复杂等原因,会使得这部分工作比较难于执行。


方案B:新业务服务持有数据,通过数据同步解决数据依赖问题

不难看出,方案A中的方法多多少少都对原系统有一定的侵入性,或与原数据库直接耦合,或需要对原遗留系统进行修改。面向对象设计原则中的“开闭原则”,即“对扩展开放,对修改封闭”,可以帮助我们实现灵活可扩展的软件架构,在这里也同样适用。因此可以考虑在原有系统基础上进行扩展,而不是直接修改原遗留系统,于是诞生了另一个方案:新业务服务持有数据,通过数据同步解决数据依赖问题。


适用场景:不允许新业务访问遗留系统的共享数据,或者数据库分离成本不高。

实现方案:具体实现方法是建立独立的数据库供新业务服务所使用,而新数据库与遗留系统数据库之间通过一个专门的数据同步服务进行同步,将新数据库中的数据转化为与遗留系统数据可兼容的形式,并迁移过去。数据同步服务又称ETL(Extract、Transform、Load)服务,其主要职责是读取、转换和同步数据,如图6-9所示。


微信图片_20220123184643.jpg


图6-9改造场景2:通过ETL进行数据同步


该方案的优点在于使用了独立的数据库,对原遗留系统的侵入性较低,新业务服务持有新的数据库,与原遗留系统解除了直接耦合,新业务服务和新数据库的选型都可以比较灵活。所有新旧数据之间的转换逻辑都在ETL服务中实现,以后任何数据转换与同步的逻辑变化都只与ETL服务有关,无须再去修改原遗留系统和新业务服务。但该方案带来的成本是需要额外实现一个ETL服务。另外由于需要在独立的两个数据库之间进行同步,可能只能满足数据的最终一致性而无法做到强一致性。另外也要考虑ETL服务的可用性,避免引入新的单点故障。


如果进一步考虑到数据隔离问题,避免直接暴露新服务的数据库数据,还可以让ETL服务通过新业务服务的API来访问数据,如图6-10所示。这种方案进一步解除了ETL服务与新业务数据库之间的耦合,新增的API还可以进一步被复用,作为其他服务消费者访问数据库的接口。


微信图片_20220123184659.jpg


图6-10改造场景2:通过ELT访问新业务服务的API进行数据同步


改造场景3:对现有业务微服务化

大多数遗留系统在单体应用架构下已经承载了许多关键业务或持有核心数据,对其进行微服务化改造时,一次性的重构风险是比较大的。因此,更为提倡通过数次小的重构来逐步实现微服务化改造。


适用场景:对遗留系统承载的现有业务微服务化,实现渐进式的重构。

实现方案:以一个含有多模块的单体应用遗留系统改造为例,通过以下三个步骤拆分为业务数据分离的两个服务。


1.将内部代码调用修改为本地REST接口调用:将被调函数修改为REST接口暴露出来,调用者模块通过对本地REST接口调用完成与原有业务等价的功能。此时还未拆分服务,仍然是作为一个服务整体上线。

2.将本地REST接口调用改为服务间REST接口调用:拆分服务,将原有的调用者模块拆分为独立服务,REST接口调用地址改为目标接口所在的服务地址。这一步接口变动的成本相当小,重点在于让拆分后的服务能够独立部署与上线。同时,为避免一次引入过多变更,此阶段拆分后的服务仍然直接访问原数据库的共享数据。

3.业务数据分离:将拆分后的服务所需的数据分离出来,作为新服务的独享数据库所持有。两个数据库之间的数据依赖问题,可以借前文所述的数据同步方案(ETL服务)解决。


按照上述过程,根据需要不断迭代,将原遗留系统的业务逐步微服务化,总体过程的示意图,如图6-11所示。


微信图片_20220123184715.jpg


图6-11改造场景3:对现有业务微服务化


相关文章
|
5月前
|
监控 持续交付 API
深入理解微服务架构:构建高效、可扩展的系统
【10月更文挑战第14天】深入理解微服务架构:构建高效、可扩展的系统
136 0
|
4月前
|
监控 持续交付 API
深入理解微服务架构:构建高效、可扩展的系统
深入理解微服务架构:构建高效、可扩展的系统
82 4
|
4月前
|
Dubbo Cloud Native 应用服务中间件
阿里云的 Dubbo 和 Nacos 深度整合,提供了高效的服务注册与发现、配置管理等关键功能,简化了微服务治理,提升了系统的灵活性和可靠性。
在云原生时代,微服务架构成为主流。阿里云的 Dubbo 和 Nacos 深度整合,提供了高效的服务注册与发现、配置管理等关键功能,简化了微服务治理,提升了系统的灵活性和可靠性。示例代码展示了如何在项目中实现两者的整合,通过 Nacos 动态调整服务状态和配置,适应多变的业务需求。
136 2
|
3月前
|
监控 Java 数据中心
微服务架构系统稳定性的神器-Hystrix
Hystrix是由Netflix开源的库,主要用于微服务架构中的熔断器模式,防止服务调用失败引发级联故障。它通过监控服务调用的成功和失败率,在失败率达到阈值时触发熔断,阻止后续调用,保护系统稳定。Hystrix具备熔断器、资源隔离、降级机制和实时监控等功能,提升系统的容错性和稳定性。然而,Hystrix也存在性能开销、配置复杂等局限,并已于2018年进入维护模式。
49 0
|
4月前
|
监控 测试技术 持续交付
深入理解微服务架构:构建高效、可扩展的系统
深入理解微服务架构:构建高效、可扩展的系统
124 0
|
6月前
|
消息中间件 Dubbo Java
聊聊单体服务VS微服务系统
聊聊单体服务VS微服务系统
|
6月前
|
运维 Cloud Native Devops
云原生架构的崛起与实践云原生架构是一种通过容器化、微服务和DevOps等技术手段,帮助应用系统实现敏捷部署、弹性扩展和高效运维的技术理念。本文将探讨云原生的概念、核心技术以及其在企业中的应用实践,揭示云原生如何成为现代软件开发和运营的主流方式。##
云原生架构是现代IT领域的一场革命,它依托于容器化、微服务和DevOps等核心技术,旨在解决传统架构在应对复杂业务需求时的不足。通过采用云原生方法,企业可以实现敏捷部署、弹性扩展和高效运维,从而大幅提升开发效率和系统可靠性。本文详细阐述了云原生的核心概念、主要技术和实际应用案例,并探讨了企业在实施云原生过程中的挑战与解决方案。无论是正在转型的传统企业,还是寻求创新的互联网企业,云原生都提供了一条实现高效能、高灵活性和高可靠性的技术路径。 ##
297 3
|
4月前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
232 6
|
4月前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
96 1
|
3月前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
334 69
从单体到微服务:如何借助 Spring Cloud 实现架构转型