重构项目

最近一段时间做了好几个项目的重构,包括线上获取机构配置服务、离线对账脚本等。线上服务每天 4000W+ 访问,对账脚本又涉及到大量资金。重构这些项目困难重重。


重构原因

既然服务这么重要,出错容忍性这么低,为什么要进行重构?

以获取机构配置服务为例,之前存储使用 MySQL, 保存了 5K+ 机构、1W+ 个性化配置信息。在业务高峰期 CPU 接近满载。为了满足后续业务增长,需要将配置信息迁移到 KV 服务。KV 相比 MySQL 性能更好,同时支持多地容灾。重构之后收益较高。

历史对账脚本使用了 Python、Shell,代码中硬编码了 MySQL 的 IP 端口。从安全和质量的角度来看存在很大问题。在部门的推进下,对这部分代码也需要做改造。

一般项目重构有这些原因:

1、系统容量无法满足业务增长,需要优化服务性能

2、系统架构满足不了新产品需求,需要重新设计增强扩展性

3、安全和质量原因,需要使用更规范的实现

4、旧组件下线和迁移


重构原则

一、可验证性

a. 变动逻辑的关键日志、监控,执行流应符合预期

b. 新旧逻辑的结果对比,结果应完全一致

二、重构上线 check 事项

a. 机器负载(CPU、内存、IO)性能变化

b. 现网服务监控曲线变化

c. 热更新 or 冷更新,能否直接替换(执行中的脚本不能直接替换)

d. 脚本文件替换后,是否有执行权限

三、最小改动原则

a. 另起炉灶,使用新的函数、文件重构

四、可回退原则

a. 重构服务上线后出现异常,应能较快切换到之前的版本。这种机制由变更工具/框架/业务逻辑等保证

b. 异常期间的脏数据修复



Previous     Next
tuzhi /
Published under (CC) BY-NC-SA in categories tagged with