下单接口剥离秒杀和拼团逻辑

最新推荐文章于 2024-08-08 15:53:53 发布

Sam_Deep_Thinking

最新推荐文章于 2024-08-08 15:53:53 发布

阅读量3k

点赞数 3

分类专栏：技术

本文链接：https://blog.csdn.net/linsongbin1/article/details/84726202

版权

技术专栏收录该内容

65 篇文章 1 订阅

订阅专栏

概述

之前在一次判断失误的反思一文提到,从下单接口中，一次性剥离所有营销逻辑，难度和风险都是非常大的。更好的方式是先剥离其中一到两个，慢慢击破。但是这种方式实施起来，难度还仍然还是很大的，下面将剥离的整个过程，描述一下。

剥离哪些营销工具

下单接口耦合的营销逻辑有如下几种:

秒杀
拼团
砍价
满减
优惠券
新人特价

那么第一件要考虑的事情就是，先剥离哪些营销工具。当时主要从下面两个维度来考虑：

变动不频繁的
就算有变动，也是变动比较小的
业务逻辑不复杂的

像满减和优惠券，都跟订单的优惠金额分摊有关系，实在太复杂，而新人特价和砍价又经常有改动，因此都排除掉。优先搞秒杀和拼团。

确定灰度方案

一般这种重构的项目，必须得灰度，降低风险。灰度策略必须尽早确定，因为不同的灰度方案，可能代码实现都不一样了。当时基于公司的实际情况，想到的灰度方案有下面两种：

1、按照userId灰度，白名单里的userId，走新流程,非白名单的userId走旧流程；
2、直接在原来的代码里进行重构，并使用nginx，调整权重，慢慢将流量打到部署有新代码的一台机器上，验证OK后，才全量。

之前采用的是第一种灰度方案，因为比较保险，也无需借助nginx，直接在代码里写个灰度工具，判断userId是走新代码还是旧代码即可。当然你需要基于原来的代码文件，拷贝出一个新的文件，用于实现新流程的代码。这种方案表面上看起来相当不错，但是如果业务代码里，有下面这几种情况，则真心不建议用这种方案。

原代码非常混乱，基本没什么代码收拢的概念，相似的逻辑满天飞；
原模块改动比较频繁,很不稳定。

像我们公司，下单模块的改动非常频繁，有些是因为需求改动，有些是解决线上bug，一天之内发布几次代码，属于正常情况。好了，这个时候就会出现一个代码合并的问题，具体如下：

1、新代码已经上线且已经灰度部分用户走新流程了，这个时候，如果有线上bug，那么两份代码都得改动好后，才能上线；
2、还未灰度，那么每次解决线上bug或者完成需求后，都得合并到拥有新代码的分支；

基于上面两点，可以得出一个结论：

代码极度容易因为合并有问题，导致bug

当时使用第一种灰度方案后，测试人员测试一天后，就说不想测试了，因为由于代码合并问题，已经出现了多个bug。测试人员觉得这块风险实在太大。因此，后面我们更换成使用第二种方案，直接改原来的代码，不拷贝一份了，这样的话，代码有改动的时候，合并起来轻松了很多。至于风险，则采用机器灰度调整权重的方式，逐渐放量来降低风险。后来，我们使用这种方式，灰度了三天，成功全量上线。

代码设计若干细节

使用本地的结算服务与微服务营销系统交互

一个正常商品参与了营销活动后，就会有一个营销价格。比如说，一个商品原来的价格是100元，参与了秒杀活动后，价格就变成了50元。因此，可以定义一个叫结算的模块service，例如：CheckoutServiceImpl，由这个类专门与营销系统交互，获取营销价格，然后传递给下单接口，这样，下单接口就可以直接拿到价格后下单，无需耦合复杂的营销逻辑了。