旧系统升级微服务的一点心得体会

微服务是目前比较流行的应用架构,经过多年的发展,已经比较成熟稳定,是适合中小企业实施的技术架构。微服务架构可以帮助我们解决业务发展过快导致的产品迭代压力,能让系统快速承载大量用户的访问。近些年在社区和用户等各方努力推动下,微服务相关的理论和产品都日趋成熟,从搭建微服务到快速实战都非常简单快捷。
微服务架构可以给企业和开发者带来很多便利,但是想要完成企业IT系统的微服务切换,还是存在一些难度和挑战,比如网关、注册中心、熔断、限流、调用链追踪等,想要掌握这套新技术也需要一定时间。除此之外,企业还应用着大量的单体式应用(旧系统),需要继续维护和升级。这些单体式应用还担负着公司的核心业务,全部推倒重来、休克式重构是不可取的,投入大周期长,风险完全不可控。
我们须逐步从单体架构衍化成微服务架构,在不影响现有业务的前提下推动微服务改造,让老系统焕发新生命力,继续支持业务可持续发展,下面就不同的业务现状制定不同实施方案。

(一) 业务现状分析及实施路径

1、 现状一:旧系统功能还算稳定,技术相对较老旧
在这里插入图片描述

这些单体式应用都存在很长时间了,经过长期的维护、迭代,规模都比较大,功能也比较稳定,但业务逻辑非常复杂,代码分层,逻辑聚合等都不规范,糅杂在一起,牵一发而动全身,程序员都不敢在此基础上做新功能,风险太大,又没技术含量,抵触情绪高,工作不好推动。同时,它们都在线对外提供服务,全部推倒重建的可能性微乎其微,休克式重构投入大周期长,风险也不好控制,还会影响业务对外服务的连续性。从现实情况出发,最可行的架构优化方案就是渐进式的微服务改造。
 实施策略
A. 优先重构基础数据放缓存,为提供给微服务做准备
B. 改造权限数据和实现sso与网关对接,同时处理好web端跨域调用
C. 逐步绞杀对应的业务模块,迁移相应的数据表,业务聚合性较强的整合在一起
D. 最后把基础数据,权限数据全部微服务化
2、 现状二:旧系统一直在不停的需求迭代
在这里插入图片描述

通常旧系统采用的技术相对较老旧,维护这些系统的同事缺少积极性,都不敢改,都有着能不动就不动的心理,久而久之限制了业务发展。随着系统规模越来越庞大,更新升级和运营维护的难度越来越大。因为系统还在不停升级,在不停的提供业务服务,改造难度比上一种情况直线上升,既要考虑业务连续性,又要考虑系统的稳定性。
 实施策略
最合理的策略是先停止往单体式应用里面添加新的特性,所有新特性都构建成微服务,从而遏制单体式应用继续生长。同时要建立旧系统和微服务之间的防腐层,避免旧系统在升级过程中功能维护对微服务产生腐化。借助这个过程让团队逐渐熟悉掌握微服务技术栈,从小规模练兵再到全面铺开。

(二) 微服务如何划分

这个话题很难定性,各有优缺点,我这里只是阐述一下曾经遇到的一些问题而引发的关于如何划分的思考,总结出以下方法,仅供参考。
1、 根据业务和功能拆分(传统模式)
在这里插入图片描述

传统模式一般都是基于领域模型进行划分,将业务聚合,互相依赖比较紧密的划分在一起,SQL语句中的关联表汇聚在一起,改造起来难度稍微小一点,确保了系统的稳定。按照不同的业务域进行拆分,例如订单、客户、库存等,形成独立的业务领域微服务集群。横向拆分就是把一个业务功能里的不同模块或者组件进行拆分。例如把公共组件拆分成独立的原子服务,下沉到底层,形成相对独立的原子服务层。这样一纵一横,就可以实现业务的服务化拆分。
2、 根据性能要求拆分
在这里插入图片描述

将系统中的业务模块按照对性能的要求进行归类。把对性能要求较高的模块独立成一个服务,对性能要求不高的放在一起。比如后台管理、基础数据等进行分类,秒杀、首页就属于高性能的核心模块,可以进行独立服务划分,方便快速扩容,或者说服务的优化模式和其它服务都不一样,这样可以有针对性处理单个服务,降低架构复杂度。也可以按发布频率进行划分,比如把经常变动的部分进行抽离,不经常变动的单独部署和管理。这个拆分的好处很明显,可以尽可能的减少发布产生的后遗症,比如用户体验、服务相互干扰等。

3、 根据业务流程拆分
在这里插入图片描述

有些系统的改造并不适合按领域模型或者业务聚合的方式来划分,更多流程业务为主,如果要进行微服务重构,更加适合按业务流程来划分微服务,根据流程来聚合业务数据更容易重构成功,注:此例子只是为了说明按流程划分的模式,并不能进行套用。
总结:以上不同拆分方法各有优缺点,要根究实际的业务情况来区别对待,不能只采用一种方案来实施。对业务聚合,按业务领域划分优先考虑。对业务模块的稳定性和可靠性,对功能的独立性、可扩展性都有相似的看法强调拆分应该是多选,而不是单选。具体情况具体分析,可以自由灵活排列组合。

(三) 数据库需要切换

旧系统改造的过程中经常遇到需要将数据进行切换,例如由原来的oracle转换成mysql,或者由sqlserver转换成mysql等,这种改造首先要进行分析,如果有存储过程,函数等,优先实施完成后再进行切换。优先模式是逐步切换和迁移,不能进行一刀切。

(四) 服务间调用的一些问题

拆分微服务前就要充分考虑服务调用问题,尽量避免多个服务调用,避免分布式事务,尽量不做调用链很长的模式,如果一定要存在多服务调用,建议用事件机制解耦,或者通过mq,redis等中间件处理,不要存在长调用链或者强一致性业务多服务调用的情况出现。

(五) 报表数据如何处理

在这里插入图片描述

简单报表服务间做数据冗余,再结合redis的基础数据来实施,复杂报表需要跨多个服务的建议将数据聚合并清理成具体的报表模型,由es来提供服务是比较稳妥的方式。

(六) 结束语

微服务架构不是绝对的好,它有一定的使用场景,也有一定的落地难度。结合我们目前的情景和未来的发展来说,微服务架构是适合我们的,并且能够解决很多现有系统的诟病,但是落地的难度也是比较大的,特别是要结合已有的各个系统进行使用。
Spring Cloud作为稳定的微服务的一站式解决方案,能快速高效地搭建微服务架构,但微服务的改造不是一蹴而就的事情,是个长期衍化过程,甚至单体架构和微服务架构会长期共存,一定要根据业务现状做好长期规划。

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 游动-白 设计师:白松林 返回首页