订单中心项目分析与总结

需求背景：随着业务的发展，公司逐步上线了多种产品和业务线，每个业务线除了一些基础的服务(比如支付，资产交割等)使用公共服务外，剩余的部分都是业务线自行处理，这样就形成了各个业务线自己的订单。在业务发展的初期，这样的方式是很方便快捷的，可以使得产品快速上线，但同时也埋下了一些问题:

1，用户如果需要查自己的订单，需要到不同的业务线(网站上不同的tab)进行查询，用户体验差(比如无法按照订单金额排序等)

2，订单数据没有统一整合，不利于订单的统计与分析

3，如果出现一个业务，需要跨业务线使用订单，这就坑了

为解决上面的几个问题，我们引入了订单中心的概念，订单中心主要提供以下功能：根据用户id罗列出订单列表，根据订单id查询详情,以及其他查询条件。订单中心接收各个业务线的订单变更消息，用于订单状态展示以及相应的订单提醒等。作为订单操作的统一入口，分发订单处理：比如撤销订单，订单中心提供统一入口，由订单中心负责分发调用各个业务线的接口。

1，数据收集

如下图所示，各个业务线原有的逻辑不变(最大限度的避免改动原有代码)，在个业务线订单状态变更时，发送mq到订单中心，订单中心的数据收集模块作为消费者负责收集数据:

2,数据存储

(1)，数据库我们使用的是mysql，业务线订单量的情况如下：

业务线每天产生的订单总数量在百万级，未来三年左右，单日最大的增长量应该不会超过500w，所以分库分表是必须的。

(2)，dba有明确规定，分库分表，最大可分10库10表，超过不行(可能是资源有限)

(3)，只给用户展示近三年的数据

根据上面的需求和限制，我们分库分表的方式为10库10表，按照userId进行取模,每张表的数据容量为1亿条数据，所以总共能存100亿条数据。100亿/365/100w约等于27年左右，意思是按100w的量算这样的方式可以存储大约27年的数据，但实际使用中我们只需要展示三年内的数据，超过三年的统统进行归档，所以这样的分库分表方式大约能够撑到我们的日订单量在900w的量级（当前订单量的9倍左右），完全可以满足目前的需求,以及架构提出的要求：约10倍数据量的预估。既然有了分库分表，那数据库中间件就必不可少了，公司选择的是 tddl(这玩意儿几年前就推出，后续没有看到有相关的维护，不如mycat的社区活跃，不过就目前来说足以满足我们的需求了).

3，数据查询

第一期需求中我们主要的查询条件是根据userid和orderid进行查询，辅以根据用户手机号，身份证号等进行查询，查询时用户一定要在登陆态，而我们的分库分表规则是按照userid维度，所以，是能够满足需求的，唯一比较别扭的是每次的查询条件中必须要有用户id。

4，后续优化

必须要用户登陆才能查询订单这个要求有一定的局限性，有时运营人员可能需要根据订单号或者手机号或者身份证进行查询，他并不知道用户id，解决这个问题大致有两种方式:

(1)，进行冗余的分库分表，比如根据身份证号或者手机号再进行一次分库分表

(2)，保持原有的分库分表方式不变，引入elasticsearch，当运营人员进行查询时，全部走elasticsearch进行查询

首先我们资源有限，进行冗余的分库分表不大现实，其次，如果后续的查询条件再增加，不可能再根据新增的查询条件进行冗余的分库分表，再者，绝大多数请求都是根据订单id或者userid进行查询，所以我们采取的方式为:

保持按照userid维度进行分库分表的方式不变，但是在订单id的生成方式上，我们要改变下，具体可看之前总结的分布式系统唯一id的生成，这里我们只需要保证订单id的最后两位与用户id的左右两位一致即可，这样可以直接对订单id进行取模定位到具体的数据库，至于其他查询条件如按手机号查询等则还是走elasticsearch！