服务端的技术重构，对于很多开发人员来说并不陌生。这里，我们称大的技改叫做重构。自加入我站以来，也是主导或经历过比较大的技术重构，简单说有两类：
- 从php到golang的重构
- 两年累积的golang代码的重构
其实重构的动机无非就这么两类
- 语言栈的迁移或统一 算是重写了
- 因业务发展，老的架构不满足了，包括稳定性、性能上的、扩展性上的等等
那么，到底我们的项目，是否需要重构了呢？
重构本身属于技改，一般情况下产品和老板不一定是非常关心的，甚至有时候是“反对”的。短期来看，重构对业务迭代速度的影响、重构中或者重构后系统的稳定性也未知。那么，我们要不要重构呢？
我们要会算账！重构的收益是什么？成本是什么？风险是什么？想清楚这3个问题再决定！
* 收益能否量化！比如性能数据提升多少？耗时的减少是直接改善用户体验的。带宽是否减少百分多少？带宽的成本往往是技术成本大头。还有如CPU的优化，对于大的业务集群也是可观的收益。
* 成本和风险 成本和风险往往是相关的。这里主要指技改的额外开发成本对业务迭代的风险影响，以及过程中的对系统稳定性的风险影响。
其实，还有很多隐形收益是特别需要开发人员关注的，如代码规范和质量的优化对后期开发效率和易维护性的影响，平台化改造使得整个系统的扩展性、业务解耦的改善，等等。那么我简单举例下近期推进的go业务系统改造。
两个月前我开始制定评论等社区系统的重构roadmap。这些系统在两年前是从我站的大杂烩系统拆分出来的，经历了非常多的功能堆积、多业务方接入，存在非常多的系统性问题。方案包括核心几点：
- 服务拆分 比如单体拆成网关和service服务。网关逻辑包括对外接口、埋点上报、防刷限流、数据聚合、业务配置等，无状态。service服务侧重基础功能逻辑、DB和缓存操作，基本上做到和功能迭代、业务方解耦。这样网关的频繁发版带来的心智负担就很少了。
- 配置化改造 比如系统不断接入了很多业务方，那么我们要支持平台功能的配置化。同时，要尽量和业务方逻辑解耦。
- 性能优化 这点不细说了，基本上做核心接口性能分析就好了，见golang下的并发、并行优化
- 稳定性 稳定性的影响因素很多，架构的合理、容灾容错方案、依赖方系统的稳定性等等。
- 通用逻辑规范写法 基础库越强大，业务代码越简单。还有比如job常用的内存merge、并行调用框架等等......
- 编码质量和UT覆盖 高内聚、低耦合，比如api协议和interface的设计啊、类的设计啊、函数的设计啊、命名啊、状态属性的写收敛、太多地方了
重构也许很累，但是本身是思考的过程和提升的过程，重构的方案也特别重要。敢于重构，勇于突破。
最后提一个我们重构过程中的小技巧，新老系统怎么切换？我们会同时并行请求新老接口，并做结果diff。当结果完全一致才考虑返回新接口数据。
