重构这件小事

作者: imnx | 来源:发表于2019-04-27 23:39 被阅读1次

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

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

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

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

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

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

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

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

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

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

相关文章

  • 重构这件小事

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

  • 生活

    1.灵魂深处闹过几次革命。 父母不和这件小事儿 弟弟进监狱这件小事儿 初恋这件小事儿 第二次恋爱这件小事儿 高考这...

  • 初恋这件小事,失恋这件小事。

    一个极度缺乏安全感患者的内心独白。 以及,她曾深埋在内心的过往。 <1> 开公众号这么久,写过周围很多人的爱情故事...

  • 初恋这件小事,失恋这件小事。

    一个极度缺乏安全感患者的内心独白。 ...

  • 擦黑板这件小事

    教育无小事:擦黑板这件小事

  • 这件小事

    今天有一件令开心过后有点烦恼的事儿,都是生活中的小事,烦杂甚至无所谓说与不说,但是我却想记录下来。 ...

  • 这件小事

    男孩喜欢女孩很久了。 喜欢像是易拉罐里的泡泡,咕噜咕噜地都快溢出来。 男孩有女朋友,不喜欢。玩乐可以,价值观的配合...

  • 这件小事

    今天不上班 这两天看了一部新日剧《今天不上班》,讲述一个30岁的处女OL与21岁的大学生一夜情并且谈恋爱的故事。当...

  • 这件小事

    "青春"这个词!别人用来回忆,而我们用来经历。没办法,我们就是那些挥霍青春的人! "青春"是这样吗?这个时候是...

  • 这件小事

    我不说工作这件小事 也不说感情这件小事 更加不想说家庭这件小事 这所有的小事都不值一提 只不过是万千章法的乱码而已...

网友评论

    本文标题:重构这件小事

    本文链接:https://www.haomeiwen.com/subject/fuslnqtx.html