概述
重构一般是由技术驱动对已有项目或者业务的改造，因为本身业务已存在，站在产品和老板的视角并不太受重视，甚至因为从短期的利益来看，重构对原业务迭代计划的影响，以及重构中或者重构后系统的稳定性也未知，有时候是持“反对”态度的。
那么到底我们的项目，是否需要重构了呢？我们怎么对项目重构进行一个合理的评估，如何说服产品或者老板认可我们的重构方案。
动机
- 存在性能瓶颈，老的架构无法满足，不得不重构；
- 业务发展考虑，基于稳定性、性能、扩展性、成本等方面的考量；
- 语言栈迁移或者统一；
评估
- 收益
- 直观收益
- CPU：硬件成本
- 内存：硬件成本
- QPS/TPS：业务承载量级
- 响应时间：用户体验
- 稳定性：用户体验
- 带宽：资源成本
- 隐性收益
- 扩展性
- 业务解耦的改善
- 后期开发效率
- 后期维护
- 直观收益
- 成本
- 开发成本
- 运维成本
- 时间成本
- 风险
- 业务迭代
- 系统稳定性
收益量化。比如性能数据提升多少？耗时的减少是直接改善用户体验的。带宽是否减少百分多少？带宽的成本往往是技术成本大头。还有如CPU、内存，对于大的业务集群也是可观的收益。
成本和风险往往是相关的。这里主要指技改的额外开发成本对业务迭代的风险影响，以及过程中的对系统稳定性的风险影响。
组织重构
- 明确重构动机
- 收益、成本与风险评估
- 项目规模
- 小项目，全量重构
- 中大项目，服务拆分（优先级）
- 性能瓶颈
- 高流量
- 核心业务
- 业务梳理
- 业务同学参与
- 区分读写接口
- 覆盖输入输出
- 逻辑细节渗透
- 业务改造
- 代码规范
- 扩展性
- 业务解耦
- 利用新语言的特性性优化
- 业务逻辑验证
- 单元测试保证
- 开发者验证
- 新老服务输入输出对比验证
- QA 验证
- 业务上线
- 灰度放量
- SLB灰度
- 老服务灰度转发到新服务，同时做异常backup方案处理和记录
- 关注指标
- 监控质量指标
- 错误日志
- 调用链路追踪日志
- 全量切换
- 老服务下线
- 灰度放量
重构实践
知乎问答服务
从Python迁移到Go
https://zhuanlan.zhihu.com/p/48039838
通过构架优化使响应时间 P95 从 1.6s 降低到 700ms，稳定性由 99.9% 提升到 99.99%。2018 年开始负责社区业务架构组，与团队一起用 Go 重写了知乎主要的业务模块，完成节省机器资源 75%。
