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