13518219792
电商刚开始发展的时候，由于组织人员比较少，追求短平快的开发方式，所以大家都集中在几个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元起，快前往官网查看详情吧
