重构:是时候展示真正的技术了、、
面对重构做出的反应
一、为什么要重构
- 多年遗留系统,维护困难
- 系统运应技术太旧,维护成本太高
- 旧架构无法满足现有的流量
- 架构层次不明确,新需求迭代成本高
- 接口定义不规范,相似功能接口多乱
二、技术选型
- 根据我们目前业务场景选择合适的方便的,不要脱离业务不要盲目跟新
- 根据团队技术实际情况,如果都不熟培训成本,初次使用成本
- 技术流行度,不然过不了多久又不行了
三、初步重构
- 可先拿出一小块功能进行试水
- 用新选型搭建一整套标准,形成规范
- 验证可行度,可行推广,不可行改进
四、工作量评估制定计划,分工合作
- 标准出来之后可逐步展开
- 明确现有架构,重构最终架构,演进状态
- 评估工作量难点,定出目标,模块化重构
- 设定指标qps,需求迭代速度,bug 量及发现速度等,重构要见效果,拿数据说话
- 按照交付,试用,反馈,调整,小步快跑
五、验收
- 验收重构后的各项指标
- 做出总结
六、依赖
- 持续集成,重构是一个持续的操作,必须要有一整套编译,打包,部署的系统
- 搭建一整套联调测试环境
- 监控要做好,流量切入新系统后保证问题及时发现
- 自动化测试覆盖率,包括单元测试,压测
七、注意
- 控制范围,切忌贪多
- 抵住技术诱惑,不要盲目引入
- 一切以业务需求为基础
- 版本管理,数据库,依赖接口,代码等所有改动点要有版本概念,以便出问题及时回滚
- 数据库表结构修改,一定要重新建库表,可做一次性全量迁移,迁移后写入可双写,部分读操作可路由到新的,流量逐渐放开
- 外部接入系统联调,及时根据业务检查架构是否满足
公众号主要记录各种源码、面试题、微服务技术栈,帮忙关注一波,非常感谢