189 8069 5689

系统重构的那些事-创新互联

目录
  • 做了哪些事
    • 1、服务拆分
    • 2、电商二代架构
    • 3、广告投放系统重构

成都创新互联公司,专注为中小企业提供官网建设、营销型网站制作、成都响应式网站建设、展示型成都做网站、成都网站建设等服务,帮助中小企业通过网站体现价值、有效益。帮助企业快速建站、解决网站建设与网站营销推广问题。做了哪些事 1、服务拆分

电商刚开始发展的时候,由于组织人员比较少,追求短平快的开发方式,所以大家都集中在几个GIT工程里开发。大部分核心代码包括商品、交易、营销等业务逻辑都写到kuaishou-ad-merchant-component里。随着人员规模的膨胀,开发维护效率都比较低。我做的第一个事就是拆服务,总体思路是不修改业务逻辑,把秒杀活动的代码从component里迁移到单独的GIT工程。这里主要需要注意的点就是,尽量不要动业务逻辑,有些直接调其他领域的service的地方改成调rpc,这样方便两边代码做DIFF。灰度策略是新增一个XX_V2版本的rpc,入参和出参跟原来的rpc保持一致,在SDK预埋灰度开关,进行新老服务的切换,业务方只需要重新打包上线即可。

难度:🌟

不足:业务需求比较多,测试资源不足等原因,导致整体开发周期比较长。拆分的粒度可以更小一点,分批上线,这样能保证整体交付周期更短。

2、电商二代架构

电商营销域系统重构,包含优惠券、优惠活动等子系统。重构的背景和原因这里不展开说了。面临的主要挑战是领域模型和系统架构都是推到重来,这里就涉及到异构数据迁移,数据双写、校验、比对,接口迁移等。

整体上线流程如下:
在这里插入图片描述
需要注意的点:

1、双写过程中,写新服务可能会失败,需要做好补偿机制。这里我们补偿策略有两种,第一种是调用新服务失败,会用MQ重试。第二种是监听老DB的binlog,如果发现老库有,新库没有就会insert。PS:新老数据服务使用同一个ID生成器,所以可以重试。

2、读接口迁移过程中,由于QA无法覆盖所有的业务场景,所以需要做接口的DIFF。实现思路比较简单,就是在读老接口的时候,异步调下新接口,做新老接口返回的DIFF打点。实际上的确很多隐藏的BUG都是DIFF发现的。

3、配套工具不能少,比如数据订正,当开始上线的时候,代码难免有问题,需要批量订正数据。

4、对外提供的接口,接口协议就好不要改,否则很难推动业务方去迁移。

难度:🌟 🌟 🌟 🌟 🌟

不足:历史包袱比较重,整体迁移节奏不可控,战线拉的比较长。重构每一个迭代的范围可以再缩小一些,小步快跑,这样团队的目标感会更明确。(PS:这种大规模的系统重构,项目管理难度的确很大)

3、广告投放系统重构

背景是三条业务线,电商、粉条、信息流都在一个项目里开发,里面耦合的逻辑比较多。并且相互之间影响比较大,总体来说开发、上线节奏都比较慢,而且上线容易翻车。目标是服务拆分,实现自治。解决方案是通用逻辑沉淀到中台,以jar包的形式提供给业务方,同时沉淀了ADF框架,包含自研的ORM框架和业务流程编排。重构完成以后,业务方独立部署上线,不会相互影响。主要难点是广告业务比较复杂,字段比较多,还有一些意想不到的特殊逻辑。所以这里核心难点在于QA。我们的方案是搭建两个环境一个是开发环境(打到新服务),另外一个是基准环境(老服务),通过流量回放,做接口返回DIFF、DB数据DIFF、以及查询接口DIFF,保证数据的一致性。

难点: 🌟 🌟 🌟

做得好的:为了尽量减少双开发的时间,灰度粒度控制的比较细(字段维度),等同于项目迭代拆得比较细,这样能尽可能做到小步快跑,对业务的影响最小。

总结
1、为什么需要重构?

重构之前需要充分的论证,重构的意义在哪里?有没有做竞品调研?业务未来方向是什么样的? 重构是一项非常费时费力,而且不那么容易在短期就看到收益的事。新系统需要能cover老的功能,同时能满足未来几年的扩展。

2、需要推到重来吗?

从上面例子可以看到,修改底层数据模型的case,重构难度大。在我们开发新系统的时候,需要多花点时间在模型设计和接口协议上。

3、上下游会配合吗?

上下游配合一方面需要leader给资源支持,另外一方面需要尽量减少别人的迁移成本,所以尽量保证接口定义不变。老接口需要兼容,新的更合理的接口可以提供的业务方选择,慢慢迁移。

你是否还在寻找稳定的海外服务器提供商?创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源,准确流量调度确保服务器高可用性,企业级服务器适合批量采购,新人活动首月15元起,快前往官网查看详情吧


网站名称:系统重构的那些事-创新互联
网页地址:http://jkwzsj.com/article/ehppo.html

其他资讯