前言最近负责订单重构项目。从技术方案设计，到人员安排，再到最终实施，项目圆满完成。重构项目虽然做了很多次，但每次都是挑战极限，时间紧任务重，有条不紊的进行着。最终测试质量高，顺利上线。本文记录一下。背景原有订单、数据库、表数据量大，已经达到性能瓶颈，无法横向扩展。订单增长迅速，重建迫在眉睫。目标订单分库分表，方便后期水平扩展订单流程的改造，平滑过渡到新流程。重构方案注意：所谓重构方案，必须是基于特定的场景。没有统一的解决方案，但核心思想是一致的。场景：网约车场景下，订单量大，但大部分订单不会被司机取消。解决方案：增加派遣前订单表，派遣前订单表分库和分表，司机派送后，订单进入派遣后表（旧表）。Process），压力集中在预调度表上，预调度表中的数据不需要长期保留（比如7天归档）。预派单表数据量极小，查询和写入效率高。分库分表方案：灰度方案根据流量灰度分为5个阶段，平滑过渡到新流程。第一阶段、第二阶段、第三阶段、第四阶段、第五阶段、第五阶段时间安排开发人力：4人，7个工作日测试人力：6人，3个工作日灰度时间：2周，并且在测试阶段的bug非常少，可以说是超出预期。1）在资源不变的情况下，下单接口性能提升N倍（N>4）。2）重构后下单接口RT<50ms，基础服务（dubbo服务）下单接口RT<5ms。3）顺序分为数据库和表。有256张表和8个数据库。目前在一个数据库集群中，最多支持8个数据库集群水平扩展。4）订单结构分层，分为业务层和数据层，订单内部通信改为RPC通信。温馨提示，欢迎关注“谈建筑”公众号，不定期分享原创文章。
