重构当当网交易系统！

作者：王胜军，当当网交易系统开发经理！
来自：数人云

近年来电商巨头定义的购物节变得越来越多，双十一、双十二已然成为举国同庆的大日子。然而，当我们把一件件磨人的“小妖精”放进购物车等着那个美丽日子的时候，电商们则怀揣着兴奋又焦虑的心情备战自己的年度大考。

为了迎接去年的双十一，当当网对固有交易系统进行了重构。当当网在 2015 年双十一前完成新老交易系统的切换，从微软.NET 技术框架全部变为 Java 开源技术架构。我们知道，交易系统是客户购物流程中最重要的环节，主要任务是完成购物车中商品信息获取、拆单、促销计算、配货计算、运费计算、非现金支付的使用以及生成订单等操作。交易系统聚合各方面业务逻辑，计算非常复杂，响应速度直接影响购买转化率，是电商最为敏感的核心系统。对如此重要的系统进行重构，当当网出何考虑，又总结出哪些可以给人启示的经验呢？

当当网订单支付及结算部负责人王胜军指出，重构系统的原因和选型路径并没有一个固定的套路，“到底选用哪一种技术完全是由公司的业务驱动，而不能为了技术而技术。”

具体到当当网来说，将交易系统从微软技术框架转移至 Java 开源技术架构主要有四个原因：第一，运行 5 年多，维护成本水涨船高；第二，业务日趋复杂，老架构力不从心，功能扩展艰难；第三，微软技术体系每年要花费大量成本购买服务；第四，公司技术转型全面拥抱 Java。

当当网交易系统此次重构的内容包括五部分：PC 结算、移动端 & 数字阅读结算、小版本结算、对外服务和作业。

王胜军指出，电商在重构系统时有几点需要特别注意，首先就是代码的正确性，也就是说，必须保证重构的代码是正确的。第二，在重构系统时一定要最小程度的影响上下游关联系统； 第三，新系统上线的过程必须时平滑的，不能影响用户下单。 出于对以上几点的考虑，当当网把系统进行了拆分，分批重构。同时，使用线上并行比对方案，根据老交易系统比对新交易，保证逻辑正确。比对之后，当当网开发了分流功能，按照用户id分流，正式分流前，先使用测试白名单中的用户进行预验证。预验证通过后，再按比例由低至高逐步切换。

当新系统开发完成之后，直接上线让用户去试错肯定是不行的，电商需要将新老交易计算结果进行比对，根据老交易系统比对新交易，保证其逻辑正确。据王胜军介绍，当当网的新交易系统在 2015 年 6 月底就开发完了，之后进行了两个多月的比对，“最开始比对的成功率非常低，当比对成功率达到 100% 时，我们才敢谈上线的事情。” 用户请求到达老交易系统；根据条件将部分请求数据复制，发送至调用服务的新交易系统；新老交易同时计算，结果存入各自的数据库，但只有老交易结果对用户公开；对新老计算结果进行比对。这样，既实现了比对目的，又不会影响线上环境。 比对完之后能不能将新系统开放给用户呢？仍然不能，因为比对毕竟是模拟下单，真实下单能不能 100% 正确并不能保证。 因此，在比对之后还要进行分流，分流完毕后，老交易才可以停止使用。 整个分流从 9 月份一直进行到 11 月，通过比对系统和分流系统当当网实现了新交易系统的上线。 在新交易系统上线之后，分流系统会承担流量。也就是说，终端用户发出的请求首先会进入流控系统，流控系统有选择地把一些东西发到老交易系统和新交易系统中（很少）。这样，新老交易系统就可以同时对外提供服务。最开始，只有内部白名单系统才会分流到新交易系统，而通过内部测试之后，就可以对外分流了，当当网是以万分之五的比例来进行验证的。再往后，新系统处理的请求比例就会逐渐增大，直至最后，所有的系统分流到新系统。 从上图可以看到，当当网将流控系统放在了老的交易系统里面，这是为了不影响上层系统的运作，而这也呼应了前面提到的开发原则，那就是在重构系统时尽量少的影响上下游系统 新交易系统借助了 Nginx 在运行状态下可以 reload 配置，基本不影响对外提供服务的能力。每个 Nginx 负载两台应用服务器，灰度发布时，将 Nginx 配置更改为只负载一台应用服务器，即可对另一台进行部署。用户请求不会导向正在部署中的服务器，从而不影响用户下单。 集中化配置方式，一点配置，所有实例可见，更易于管理，而且配置修改后，通过热加载方式，立刻生效，快速便捷。而原有交易系统修改配置后，必须重启系统才能生效。 新系统其它特色如下： • Log 集中搜索 • 交易运营工具 • 诊断系统 • 高可用交易 (建设中…) • 通用流量控制系统 (建设中…) 王胜军总结道，当当网此次交易系统重构代码 17 万行全部切换至 Java 开源技术架构，几十个后台作业，对外提供数个 API。此次重构为公司节约了大量的成本，并进行了架构的优化，使整体性能平均提升了 25%。

长按订阅更多精彩▼

如有收获，点个在看，诚挚感谢