遗留系统改造微服务

遗留系统改造微服务

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

系统改造原由

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

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

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

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

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

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

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

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

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

面向服务设计

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

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

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

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

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

循序渐进的改造过程

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

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

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

测试驱动开发

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

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

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

面向失败设计

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

灰度发布

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

日志聚合和全链路监控

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

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

几句心里话

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

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

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。