遗留系统改造微服务

谁践踏了优雅 2023-07-07 08:14 20阅读 0赞

随着企业规模的扩大以及微服务技术的逐渐成熟，更多企业开始尝试使用微服务的方式进行系统开发。但是技术的转型并不能一蹴而就，因为一般技术部门要保持需求的开发进度，所以研发并不能停下需求研发，而单单做技术的转型。这就造成遗留系统改造微服务比新系统直接使用微服务方式开发更复杂，在这个复杂的过程，要寻求业务与技术上的平衡。

**系统改造原由**

1、新开发人员维护系统存在大量知识盲区，一些业务规则只有特定人员才知道，缺少文档记录，系统随着开发人员变动而越发不可控

2、在现有系统上实现新功能或修改现有功能非常困难，最后演变成不敢修改而不得以不断打补丁支撑，测试回归成本过高

3、不利于维护，沟通，协作，某个服务部署或者宕机，会影响整个业务链

4、随着规模扩大，海量用户以及高并发，不能快速水平与垂直扩展

**遗留系统改造微服务——关注要点**

1、目的性 所有改造的过程基本上都是为了系统的高性能，高可用，可扩展，可伸缩，支撑未来业务的飞速发展。

2、在遗留系统中优先寻找核心，关键功能，发挥改造的最大价值。

3、注重业务模块拆分和重建，粒度上保证功能的独立性和完整性，减少链路调用，并且拆分服务能为其他模块复用，实现1+1>2的效果

4、改造过程要分清两个基本概念，重构≠重写，虽然重写好处诸多，但是现有系统生产环境稳定运行，贸然重写会引发很多问题，而没有明显收益

**面向服务设计**

1、通用功能下沉，成为独立子模块

用户系统，权限系统，文件存储，即时通信，消息推送，支付系统，短信平台，社交服务，上述列举都是较为通用的功能，根据遗留系统的复杂度以及具体业务拆分，一个原则保证功能独立性以及完整性，减少链路调用

2、最大限度的复用，分布式中间件对服务的整合

服务网关（用户鉴权，路由，灰度发布）

分布式调度系统，分布式缓存机制，分布式消息中间件，搜索引擎，日志系统，分布式发号器等

**循序渐进的改造过程**

1、代码重构，减少冗余代码，提高可读性

2、使用适配器模式（在不同子系统适配，确保应用不受外部子系统的影响），门面模式（拦截路由）实现新旧平滑迁移

3、共享数据库，新服务复用旧服务的数据库，减低使用风险，提高改造速度（减少新旧系统开发成本）

**测试驱动开发**

重构过程难免无意中影响现有逻辑行为，导致系统引入缺陷。

1、在重构前测试用例和之前逻辑一样，单元测试要尽可能覆盖核心逻辑，不盲目追求覆盖率，追寻二八原则，以提高项目后期的单元测试的收益率

2、自动化测试等手段减少回归测试成本

**面向失败设计**

在微服务设计中，存在各种风险造成程序异常。在改造初期就要考虑服务降级，流量控制，接口熔断，分布式事务等方式去拥抱失败

**灰度发布**

为了减少改造对线上的影响，引入灰度发布机制，可以保证系统稳定，控制影响范围，及早发现并解决问题

**日志聚合和全链路监控**

服务的拆分，日志被每个模块独立拆分，为了减少后期解决问题的耗时以及复杂性，规范的日志体系，便于后续的日志聚合检索

全链路追踪监控，在微服务中加上"服务名称"便于定位异常发生具体模块，根据全句的TraceID，串联整个调用链，以便详细分析。

**几句心里话**

自从入职公司一直希望做全新的系统，希望使用新的技术，面对以前的老系统想用现在的技术重构。但是做了新的系统，慢慢的新系统自己都不乐意维护了，新系统也做成老系统的模样。一心倡导把现在有系统改造成微服务的方式，却忽略与微服务配套的相关内容。自身的技术不硬，做什么最后都做成了那般模样。当我开始认真考虑系统改造的时候，第一个问题如何粒度上保证功能的独立性和完整性，减少链路调用，就把自己困住了怎样都没有更好的方案。然后跳出自己的困境，整体思考公司的架构，确实存在系统过于庞大的问题，但是其他已经做了拆分，只不过是相比其他服务目前正在做的服务，过于庞大了，其原因也是在后续的开发过程服务的独立性没有把握好。我在反思与其将现有服务拆分，不如想想怎么做好服务的支撑工作，当我们有成套的解决方案，遗留系统改造，一切问题都会迎刃而解。

希望类似处境朋友们，结合上边的方法认真思考是，是意愿问题，还是确实刚需。无论哪种原因，都好好考虑除了业务模块还有因为服务引发的系列问题，虽然一开始可能没办法做不了大而全，但是也不能忽略。

发表评论取消回复

表情：

评论列表（有 0 条评论，20人围观）

还没有评论，来说两句吧...

相关阅读

相关遗留系统改造：Java旧版本兼容性问题实例

遗留系统改造中，Java旧版本的兼容性问题是常见的挑战。下面是一个具体的实例： 1. **环境背景**：公司有一套使用Java 1.5的老系统，由于新需求和升级成本，决定对其

痛定思痛。/ 2024年10月09日 05:15/ 0 赞/ 54 阅读

相关如何实现遗留系统现代化

如何实现遗留系统现代化本文译自：[How To Approach Legacy System Modernization][] 原文截图 ![在这里插入图片描述

谁借莪１个温暖的怀抱￠/ 2024年03月29日 14:44/ 0 赞/ 55 阅读

相关遗留系统改造微服务

随着企业规模的扩大以及微服务技术的逐渐成熟，更多企业开始尝试使用微服务的方式进行系统开发。但是技术的转型并不能一蹴而就，因为一般技术部门要保持需求的开发进度，所以

谁践踏了优雅/ 2023年07月07日 08:14/ 0 赞/ 21 阅读

相关微服务微应用的安全测试_单体应用微服务改造实践

![203af06d5f7af888ede8b9b84f13e71c.gif][] ![f1be507b97a511f696f9e3ceb9fe7723.png][] ![5

妖狐艹你老母/ 2023年01月02日 15:28/ 0 赞/ 206 阅读

相关微服务系统设计

几个组件的解释 cAdvisor 数据采集 Prometheus influxDB 时序数据库 grafana 图形化展示 altermanager

快来打我*/ 2022年12月15日 11:15/ 0 赞/ 121 阅读

相关如何将单体应用改造为微服务

如果你的工作围绕一个大型的，复杂的单体应用，可能你每天开发和部署应用的工作都是进展缓慢而痛苦的。微服务看起来像是一个遥不可及的天堂，幸运的是，有方法可以帮助你逃离单体架构的地狱

梦里梦外;/ 2022年09月29日 04:25/ 0 赞/ 267 阅读

相关虎牙直播在微服务改造方面的实践和总结

![图片描述][4018959093-5c6cf6ca57a73_articlex] 相比文字和图片，直播提供了人与人之间更丰富的沟通形式，其对平台稳定性的考验很大，那么倡

青旅半醒/ 2022年03月07日 07:40/ 0 赞/ 141 阅读

相关微服务改造之数据库连接瓶颈问题的思考

微服务改造之数据库连接瓶颈问题的思考 > 背景：在微服务改造过程中，很有可能出现多个服务公用一个数据库服务的过渡情况，如果客户端总的连接数如果超过数据库服务端的最大连接数

た入场券/ 2021年12月18日 23:31/ 0 赞/ 545 阅读

相关要不，微服务改造告一段落？

随着 5G 技术、云时代的来临，由于独立部署、选型灵活、易扩展等特点，微服务成为一个热门的技术词汇。而容器、轻量级协议，代码管理、新集成方法与工具等技术的成熟发展，更是促使互联

冷不防/ 2021年08月27日 12:28/ 0 赞/ 299 阅读

相关一场近乎完美基于 Dubbo 的微服务改造实践

作者：网易考拉陶杨微信公众号：阿里巴巴中间件（ID：Aliware\_2018）导读：网易考拉（以下简称考拉）是网易旗下以跨境业务为主的综合型电商，自2015年1

Myth丶恋晨/ 2021年08月19日 23:40/ 0 赞/ 379 阅读