当当.：促销系统与交易系统的重构实践.docxVIP

当当11.11：促销系统与买卖系统的重构实践 买卖系统是客户购物流程中最重要的环节，次要任务是完成购物车中商品信息猎取、拆单、促销计算、配货计算、运费计算、非现金领取的使用以及生成订单等操作，聚合各方面业务规律，计算格外简单，而且响应速度影响购买转化率，一旦消灭毛病，直接影响营业收入，可谓电商最为敏感的核心系统，打算对其进行重构需要极大的魄力。 当当原有买卖系统接受.NET技术框架，运转多年，很好的支撑了购买流程，但是弊端渐渐显露。首先是技术体系属于微软系，每年要花费大量成本购买服务；其次是随着业务需求的不断叠加，其结构及可维护性逐年下降，尤其是众多小版本结算的存在，使得功能扩展特别困难。 基于以上因素，买卖系统团队在2021年底启动重构项目，2021年10月底新老版本完成切换。此次重构耗费约1500人天，重构代码17万行，全部切换至Java开源技术架构，为公司节省大量成本，并进行了架构优化，全体功能平均提升25%。 买卖系统业务主流程图如下： 买卖系统重构引入了很多业界成熟的技术实现方案，次要有以下几点： 1. 集中化配置 集中化配置方式，一点配置，全部实例可见，更易于管理，而且配置修改后，通过热加载方式，马上生效，快速便捷。而原有买卖系统修改配置后，必需重启系统才能生效。 2. 页面缓存技术 用户恳求一次买卖结算页面，会调用各种后端服务，而由于规律的简单性，每次服务调用都会调用订单计算大流程，导致页面刷新缓慢。新买卖系统将大流程计算结果进行缓存，在一次页面恳求范围内，后续调用直接用缓存结果，极大提高了页面的刷新速度。 3. 小版本合并 由于历史缘由，买卖系统存在很多版本的结算规律。最常用的是统一结算，还有一些特殊类型的结算，如秒宰、一键下单、补发货等等，规律与统一结算稍有不同，统称为小版本结算。因小版本结算与统一结算大部分规律相同，因而新买卖系统将二者合到了一起，共享基础规律，而不同的规律则单独处理，极大提高了可维护性。 4. 灰度发布、无缝切换 借助了Nginx在运转形态下可以reload配置，而基本不影响对外供应服务的力量。每个Nginx负载两台应用服务器，灰度发布时，将Nginx配置更改为只负载一台应用服务器，即可对另一台进行部署。用户恳求不会导向正在部署中的服务器，从而不影响用户下单。 (点击放大图像) 5. 并行比对 买卖系统重构后，虽然进行了大量的测试，仍不能放心部署上线。由于买卖系统的计算都和金钱有关，必需慎之又慎，我们提出了线上并行比对方案，依据老买卖系统比对新买卖，保证其规律正确。原理如下： 1） 用户恳求到达老买卖系统 2） 依据条件将部分恳求数据复制，发送至调用mock服务的新买卖系统 3） 新老买卖同时计算，结果存入各自的数据库，但只要老买卖结果对用户公开 4） 对新老计算结果进行比对 这样，既实现了比对目的，又不会影响线上环境。 6. 分流 比对之后，新买卖系统也不能马上全面上线，那样可能有巨大风险。我们开发了分流功能，依据用户id来分流，正式分流前，先使用测试白名单中的用户进行预验证。预验证通过后，再按比例由低至高逐渐切换。 7. Web服务器按需伸缩 基于前面所讲的灰度发布技术，新买卖系统很简约做到按需伸缩。正常情况下，每个Nginx负载两台应用服务器。双十一需要扩容时，将待扩服务器ip地址加入Nginx配置，重新reload，该Nginx就可负载更多台应用服务器了。 买卖系统上线后为备战双十一，确保万无一失，利用老买卖系统还未下线的条件进行了线上压测。为达到最精确?????的测试效果，且不影响正常系统运转，进行了以下的预备： 1. 测试环境、数据与生产环境全都 在预备测试环境方面，为了保证测试结果更接近真实结果，本次测试使用线上环境，通过大量测试账号对线上的真实促销商品进行测试，这样也对新买卖系统所依靠的各系统服务做了检验。 2. 线上业务运转保障 测试阶段线上的恳求切到老买卖系统，压测恳求发送到新买卖系统，使测试和生产业务进行分别，保证了各自服务器资源的独立性。在应用服务器层面使测试过程不会影响到线上正常买卖。 3. 拦截订单回收库存 由于使用线上环境测试，需要对测试订单进行拦截，避开进入生产流程，并回收占用的库存，使商品不会耗尽库存，接受的方法是在自动审单系统中将测试账户加入黑名单，测试订单提交后会被拦截，然后取消订单释放库存。为防止测试过程占用了商品的全部库存而影响线上销售，测试商品池基数很大，并且过滤掉了库存数量较少的商品，在执行测试过程中把握每个商品的使用次数，保证可销售库存占用在平安范围内。 4. 恶意用户策略把握 由于在买卖下单过程中包含恶意用户判定的策略，会对用户进行隔离，禁止连续大量下单，线上压测时依据实际情况短时间内调整了平安级别，保证订单成功率。 经过多轮线上压测，新买