重构系统的套路-明确重构目的

重构系统的套路系列：

• 重构系统的套路-写有组织的代码
• 重构系统的套路-提升并发能力
• 重构系统的套路-微服务化

本篇说下重构系统的套路中的，明确重构的目的。

咱们进行系统重构会抱着不一样的目的，好比为了系统稳定性，为了系统中某些功能负载能力更强，为了系统更便于维护，或是为了系统更便于持续集成提高RD和QA的人效。

不一样的重构目的会有不一样的重构方式和不一样的执行标准。

好比为了系统稳定性的重构，咱们更须要关心的是系统稳定性指标，咱们须要在整个服务链路上进行梳理，梳理出核心链路，核心链路的耗时控制及QPS，若是不能在整个链路上下游达成统一，每每会形成一些未知且不可控的问题。

好比若是某个服务进行稳定性重构，专断专行的设置了对下游服务的耗时，上线后，整个服务虽然稳定性提高，可是下游服务因为不合理的超时时间形成数据落库失败，在整个链路上看其实这个请求也是失败的，形成的结果就是一个服务的可用性和稳定性上来了，可是整个链路的可用性却下降了，贸然全量这样一个重构，必然产生一个很是大的事故。 若是直接把一个500ms设置成100ms，结果没有在乎到这个500ms是一个数据上报功能，其实对核心业务不影响，可是由于下降了400ms形成上报数据系统超时，最终统计数据有误，形成金融结算金额错误，因此一个小小的修改超时时间形成了一个如此大的问题。

若是重构的目的是为了负载能力，好比为了半年整个订单量翻一倍，QPS提高三倍，咱们首先须要对现有系统进行压测，发现系统瓶颈，经过完善的监控系统进行耗时稳定代码和逻辑评估，针对性优化。 同时须要对整个重构服务所依赖的缓存，持久化存储，redis，mq等系统容量进行评估，系统中线程池进行评估，而全部的评估都是创建在对对应中间件所服务目的来实现的。

好比咱们用redis集群作幂等服务，由于多服务同步之间经过定时任务触发，定时任务触发后可能由于大数据量形成请求挤压，高峰期挤压处理在2～5h不等，因此这个redis的key的超时时间须要覆盖到5h，梳理了程序代码逻辑就ok了吗？

结果服务上线后，整个代码逻辑跑起来没问题，能够高峰期间发现异常日志和错误数据统计不停上升，结果发现是没有正确评估系统QPS，同时没有梳理好redis的key大小，5h的超时时间使得整个key的存储瞬间达到20G+，而某个集群容量可能已经满了，而DBA来不及进行集群扩容，集群自身触发缓存清除策略，大量的key删除形成集群数据的rebalance，形成网络抖动，结果形成高峰期间集群可用性下降，当redis集群可用性下降到必定阈值以后，系统逻辑降级读db，形成了雪崩，整个数据库集群也被压倒，形成了一个重大事故。

上面这个虽然是我本身在系统梳理过程当中意淫出来的场景，但我不得再也不我进行相似系统重构以前，在代码逻辑角度，功能业务角度，缓存集群，mq集群，DB集群等角度考虑，我此次重构可能形成的问题，只有咱们在系统重构之间可以想的比黑天鹅来的更快咱们才能对系统作更多的保护，固然这一切不能交给QA同窗，须要有经验的架构师有全局的视野和掌控。

若是系统重构的目的在于可维护性，和上面两点的区别在于，周期不可操之过急。 咱们须要在整个业务角度去理解系统，同时对将来系统所承接的业务有所评估，这样咱们才能设计出一个面向将来的系统。 编写可维护的代码和可维护的系统其实很是的难，微服务的流行和DDD的流行其实也很难根本上解决这个问题，终极的解决方案仍是在将RD培养成领域专家，在领域角度去抽象和理解业务，编写领域驱动的代码，而不是简单的认为分层和多模块的搞就能够了。

若是系统重构的目标在于持续集成和发布，提高RD和QA的人效，则须要在工程和流程及文化三个角度去作。 工程上提供便于管理的git系统，全链路压测系统，集成测试环境，多泳道支撑，一键资源申请，完善的上线发版流程及快速回滚方案，QA同窗具有正常的http抓包分析能力，测试代码编写能力，基本linux的shell编写能力。 RD编写测试用例，完善技术文档，覆盖功能修改点，配合qa同窗观察耗时，链接创建，磁盘IO，机器load，cpu等多指标。 控制发版时间和发版粒度，指定安全发版策略等。

基于以上四点不一样的重构需求，咱们采起的方案和执行的角度彻底不一样，系统变大了以后，稳定第一。