重构这件小事

imnx · · 1244 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

服务端的技术重构,对于很多开发人员来说并不陌生。这里,我们称大的技改叫做重构。自加入我站以来,也是主导或经历过比较大的技术重构,简单说有两类:

  1. 从php到golang的重构
  2. 两年累积的golang代码的重构

其实重构的动机无非就这么两类

  • 语言栈的迁移或统一 算是重写了
  • 因业务发展,老的架构不满足了,包括稳定性、性能上的、扩展性上的等等

那么,到底我们的项目,是否需要重构了呢?
重构本身属于技改,一般情况下产品和老板不一定是非常关心的,甚至有时候是“反对”的。短期来看,重构对业务迭代速度的影响、重构中或者重构后系统的稳定性也未知。那么,我们要不要重构呢?

我们要会算账!重构的收益是什么?成本是什么?风险是什么?想清楚这3个问题再决定!
* 收益能否量化!比如性能数据提升多少?耗时的减少是直接改善用户体验的。带宽是否减少百分多少?带宽的成本往往是技术成本大头。还有如CPU的优化,对于大的业务集群也是可观的收益。
* 成本和风险 成本和风险往往是相关的。这里主要指技改的额外开发成本对业务迭代的风险影响,以及过程中的对系统稳定性的风险影响。

其实,还有很多隐形收益是特别需要开发人员关注的,如代码规范和质量的优化对后期开发效率和易维护性的影响,平台化改造使得整个系统的扩展性、业务解耦的改善,等等。那么我简单举例下近期推进的go业务系统改造。

两个月前我开始制定评论等社区系统的重构roadmap。这些系统在两年前是从我站的大杂烩系统拆分出来的,经历了非常多的功能堆积、多业务方接入,存在非常多的系统性问题。方案包括核心几点:

  • 服务拆分 比如单体拆成网关和service服务。网关逻辑包括对外接口、埋点上报、防刷限流、数据聚合、业务配置等,无状态。service服务侧重基础功能逻辑、DB和缓存操作,基本上做到和功能迭代、业务方解耦。这样网关的频繁发版带来的心智负担就很少了。
  • 平台化改造 比如系统不断接入了很多业务方,那么我们要支持平台功能的配置化。同时,要尽量和业务方逻辑解耦。
  • 性能优化 这点不细说了,基本上做核心接口性能分析就好了,见golang下的并发、并行优化
  • 稳定性 稳定性的影响因素很多,架构的合理、容灾容错方案、依赖方系统的稳定性等等。
  • 通用逻辑规范写法 基础库越强大,业务代码越简单。还有比如job常用的内存merge、并行调用框架等等......
  • 编码质量和UT覆盖 高内聚、低耦合,比如api协议和interface的设计啊、类的设计啊、函数的设计啊、命名啊、状态属性的写收敛、太多地方了

重构也许很累,但是本身是思考的过程和提升的过程,重构的方案也特别重要。敢于重构,勇于突破。
最后抛一个我们重构过程中的小技巧,新老系统怎么切换?我们会同时并行请求新老接口,并做结果diff。当结果完全一致才考虑返回新接口数据。


有疑问加站长微信联系(非本文作者)

本文来自:简书

感谢作者:imnx

查看原文:重构这件小事

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

1244 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传