携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第1天，点击查看活动详情
概述
现在外卖平台是与我们生活息息相关的软件，大部分人每天都会通过外卖平台选择自己需要的食品进行然后下单，所以每个人对外卖的下单流程应该非常清楚，鉴于这种情况，因此选择基于外面订单业务的功能记录技术架构演进的过程，最终会呈现出从单库版本到实现分库分表的过程。
单库版本
先通过两张图分别先说明一下订单的具体业务流程和后台的技术架构情况。
- 业务架构图
- 技术架构图
系统架构升级
- SQL优化
平台拥有100万的用户，根据二八法则，平台的日活用户约20万，也就是平台每天的订单数据预计是在20万条左右。这个订单量的话，可以多部署几台业务应用服务，单实例的MySQL数据库可以支撑，但是可能系统会有些卡顿。这个时候首先可以考虑做SQL优化来提高系统的响应时间。业务数据流向如下图：
- 缓存方案
一般的数据库服务器（8c16g），并发量尽量保证在1500左右，不要超过2000。如果并发量增加，存在瞬时的高并发，比如当平台做活动的是，运行发起了一波派发消费券的活动，这个时候可以考虑增加缓存来保证服务的性能和稳定性。
- 读写分离方案
缓存不可能存储所有的订单数据，而且会存在缓存过期的情况，总会有一部分读的流量直接打到数据库，所有的写流量都会打到数据库，如果请求量增加，依然会造成系统性能的问题。这个时候我们可以搭建MySQL的主从复制架构，实现读写分离，让所有的写流量在主库执行，没有命中缓存的都流量走从库。
- 垂直分库
因为我们外卖平台的所有数据表都存放在一个数据库中，比如商品信息、订单信息、用户信息等等，对以上信息的所有操作的流量都会打到同一个数据库中，有的流量相对较大、有的流量相对较少，比如用户信息的流量比较少，但是订单信息的流量比较大，因为订单信息流量的原因导致用户信息的操作回变的缓慢，这个时候可以考虑进行数据库的拆分，如图：
分库分表版本
经过系统架构升级后，相应的系统架构相比较于单库版本就有所变化，演进后的系统架构如下图：
分库分表后需要通过选择路由key，然后根据路由key选择对应的数据库，通过改写SQL进行数据查询，这个过程选择使用ShardingSphere中间件完成。
用户订单时序图
- 用户下单时序图
- 用户查询订单时序图
总结
本篇主要是以外卖订单作为业务背景，从单库单表系统架构随着数据量的增加带来的问题出发，循序渐进的进行系统架构的演进分析。根据不同的需要可以进行SQL优化、加缓冲、读写分离、分库分表的架构演进。