从最早的互联网高速发展、到移动互联网的爆发式增长，再到今天的产业互联网、物联网的快速崛起，各种各样新应用、新系统产生了众多订单类型的需求，比如购物订单、交流流水，外卖订单、支付账单、设备信息等。数据范围不仅越来越广，而且数据量越来越大，原有的经典架构方案已经很难满足当前新的业务场景。在新的需求下，对存储规模、开发效率、查询功能、未来扩展性等众多方面提出了更高的要求，要设计一款可靠稳定且扩展性好的系统不再是一件简单的事情，而是变得更加复杂，需要考虑的因素也越来越多。
需求分析
首先，我们来分析一下设计一个完整的订单系统需要考虑的因素有哪些，我们会从不同角度来阐述各种需求的关键点和作用。为了阐述的更加清晰，我们将众多需求分成了三种类型，分别是：基础需求、隐含需求和高级需求。其中“基础需求”是指要实现订单系统必须要考虑到的因素，也是大家最容易想到的点；“隐含需求”是指为了让架构更加优秀，需要考虑的一些更深层次的因素；“高级需求”是指为了满足业务未来更多可能性或者架构更加开放等可以考虑的可选因素。
基础需求
在设计一个优秀的订单系统时候，基础需求是需要优先考虑的，主要包括了“规模”、“功能”和“性能”等，如果这些基础需求无法满足，那么业务最简单的功能可能都无法实现。
规模
规模：是指订单系统中需要保存的订单条数。当我们预测规模的时候，不能以当前的订单规模来预估，而应该以未来一年到三年的规模来预估。
如果规模预估偏少，那么后面可能很快就会发现当前系统不能承载，这个时候就需要重新选择数据库，这里要特别注意的是，当因为规模选择了新的数据库后，可能原有的整个订单系统都需要推翻重新设计，这个代价是非常大的，所以，“规模”是最最重要的考量因素，具有翻天覆地的能力，一定要慎重选择，能激进尽量激进，尽量不要保守。
功能
功能：是指在订单系统中需要存储系统或数据库需要具备的能力。这些能力主要分为两部分，一部分是“写入能力”，另一部分是“查询能力”。“写入能力”最主要的就是单行原子性，而“查询能力”的要求会更加丰富，比如：
- 通过订单号查询特定订单。
- 通过用户名和时间范围查询一批订单。
- 通过商品信息查询订单。
- 通过商品类目、买家地域统计订单数。
- 通过部分商品名查询相关商品的订单。
- 通过买家或卖家或某个商品统计月消费额度。
- ......
这些功能如果转换为数据库的功能，则是：
- 主键查询。
- 非主键列的自由组合查询。
- 排序。
- 模糊查询。
- 全文检索。
- 翻页或跳页。
- 统计聚合：count、max、sum、groupby等。
上述功能集合基本可以覆盖所有的查询需求，我们实现的订单系统的功能需求一般都在这些里面。
性能
性能：是指写入和查询时的耗时情况。性能要分“查询性能”和“写入性能”，这里我们分别进行讨论：
- 写入性能：大多数的订单系统规模较大是靠长时间的累积，因此写入一般不会有瓶颈。但是如果在较短时间内系统有大量订单写入，这时候就要优先考虑写入性能。比如双十一零点订单、中午12点左右外卖订单等场景。
- 查询性能：订单系统的请求可以分为两类：OLTP 和 OLAP，其中核心是OLTP类请求，这类请求查询结果需要在毫秒内返回。在订单存储量较小的时候，性能问题不会突显出来，但是随着规模的增长，查询性能可能会越来越差，最终影响客户使用，所以这里要特别注意的时候，在规模增大以后的查询性能是否可以保持稳定。其次，有时候会有些特别大的客户，这些大客户会导致数据存在倾斜或热点，这些大客户的请求就会成为慢请求，这些请求的耗时情况也需要特别注意，如果太慢会严重影响客户体验，甚至面临流失大客户的风险。
隐含需求
考虑完“基础需求”后，一个订单系统最主要的轮廓应该已经出来了，可能也能满足当前的业务需求了，但是这个系统上线后是否可以稳定运行？遇到大促是否可以快速扩展？这里面临的就是一个从“60分”到“80分”的架构质量提升问题。要让系统架构达到“80分”，主要是需要考虑以下一些“隐含需求”：可靠性、可用性、扩展能力、低成本等。
可靠性
可靠性是指数据的可靠性，也就是数据不丢失能力，一般通过百分比来表示，比如99.99%，简称为4个9。4个9一般是关系型数据库的可靠性能力，而基于分布式文件系统的分布式系统的可靠性最高可以达到11个9，也就是保证数据不丢的能力大幅增强。
订单系统中存储的海量订单很多时候是一个企业核心资产，这部分数据的可靠性很重要，选择存储系统或数据库的时候最好能考虑到这一点。
可用性
可用性是指系统服务的可用能力，比如多长时间系统稳定，一般也是用百分比来表示，比如99.9%，简称3个9的可用性。为了保障上层业务系统的稳定性，依赖的数据库的可用性越高越好。但是当前可用性的提高一般都是通过系统冗余的方式来实现，比如“一主多备”“双集群”等，这样可用性越高的同时，成本也会越高。所以，当选择可用性的时候，需要根据业务特征和成本一起来权衡考虑。
扩展能力
随着业务的发展和时间推移，业务数据会越来越多，业务请求量会继续增长，如果遇到业务大爆发，那么数据和请求量更会快速爆发式增长，这些增长再给业务带来喜悦的同时，会给系统带来更大的压力。
这里需要考虑的扩展能力主要有两类，一类是存储部分，一类是写入和查询的请求数。这两个扩展能力如果没处理好，可能一年，甚至几个月后就需要推翻现有架构，重新选型数据库，然后再重新设计系统。如果一开始就选择一款可以更容易扩展的系统，那么后续就不会被这个问题限制系统能力。所以，扩展能力也是一个很重要的因素，最好需要在设计的时候就考虑周全。
成本
成本有多个角度需要考虑，包括从其他系统迁移过来的迁移成本、运维成本、硬件成本等，包含了从系统开始建设到最后稳定运行的各个阶段。
- 迁移成本：系统迁移可能发生在云上与云下的相互迁移，也可能发生在系统A不满足要求需要迁移到系统B，因此我们选择的系统组件要提供丰富的迁移手段，方便大规模订单系统进行前期准备。
- 运维成本：高可靠、高可用、弹性等都可以节省运维成本，如果选用云上服务的话，Severless 全托管的云服务是一个不错的选择，避免处理CPU 打满、坏盘、网络故障等各种问题，同时按量付费，随时弹性扩容缩容，可以节省大量运维开销，这样就可以将资源全部投入研发。
- 硬件成本：如果使用了云服务，则为云服务的价格。我们期望价格要尽可能低，因为订单量会越来越大，不能导致最后价格太高而承受不起，导致频繁改变系统架构。
高级需求
订单系统满足基础需求和隐含需求后，已经能够构建出健壮高效的大规模订单系统。随着用户需求越来越丰富，对系统要求越来越高，订单系统可能会在原有的 OLTP 类请求之上增加 OLAP的分析需求，这时候就需要具有一定的计算能力并能够完成一些实时计算和批量计算需求。因此这里列出两个最常见的高级需求：同时支持TP/AP、丰富的计算生态。
同时支持TP/AP
订单系统在最开始的时候可能都是简单查询请求（TP请求），随着业务量发展，可能会出现一些偏分析类型的请求（AP请求），但是 AP 类型请求对资源消耗可能会很大，一个简单的AP请求可能就会消耗完系统资源，从而影响现有的 TP 类线上业务请求，因此需要TP/AP进行隔离。
为了达到隔离，一般会引入一个ETL系统将TP数据复制一份给AP使用，这样会带来更高的维护成本和整合成本。因此最好选择能同时支持TP/AP请求的数据存储组件，一个实例就可以完成TP/AP两种请求，避免提升架构的复杂性。
丰富的计算生态
部分订单系统需要依靠计算来实现更丰富的功能，比如订单信息补全、稽核、刷单检测、用户行为分析等。目前计算主要分为批量计算和流计算，因此设计的订单系统要有能力对接 Spark、Flink 等流批计算引擎，通过计算引擎完成更多的用户需求。
上面我们介绍了在设计一个订单系统时候，需要考虑的多种因素，接下来，我们看一下订单类系统的架构演进。
架构演进
在订单增长迅速、需求愈加复杂的背景下，大规模订单系统的架构经过了多轮的演进，从单一的MySQL到结合各种NoSQL的架构方案，慢慢解决了各方面的问题来满足上一章提到的需求，接下来我们看一下订单系统的架构是如何演进的。
小规模
在订单系统早期，企业处于刚开始发展的阶段，订单量和查询量都不大，很多方案都可以满足需求。为了加快应用上线和版本迭代速度，很多订单系统都没有考虑后续的可扩展性，直接采用了单MySQL数据库这种集中式的架构方案。MySQL这一类数据库的优势十分明显，主要是支持SQL、事务。SQL结合事务的ACID特性，可以方便的完成业务逻辑并提供一些查询能力，同时SQL比较通用且容易迁移到同类产品中，这种架构也是订单架构中精简模型。
大规模
随着系统中的订单量和查询量迅速增长，系统规模从小规模阶段进入了大规模阶段，MySQL这类数据库的劣势逐渐凸显出来，用户需求变得更多且更复杂，订单系统也越来越难以维护，其中最主要的问题是性能问题和容量问题。
MySQL分库分表
容量和性能的单机瓶颈问题是伴随业务增长一直存在的，隔一段时间就需要提升MySQL实例规格进行MySQL扩容。基于MySQL解决单机瓶颈的方案是采用分库分表，将单个库的压力分散到多个库上，可以暂时解决容量瓶颈问题和部分查询性能问题，但是过一段时间最终还是会遇到当前分库分表量不够，需要重新水平切分的场景，然后会伴随数据迁移等繁琐的后续工作，升级压力十分巨大。而且分库分表会和上层的业务逻辑强耦合，带来更大的后续架构升级难度。
MySQL 分库分表+ Elasticsearch
为了解决 MySQL 在复杂查询场景下的查询性能瓶颈，一般的订单系统会引入 Elasticsearch 或者 Solr 等搜索引擎作为查询引擎，用来做查询加速。该架构选型通过 Elasticsearch 弥补了 MySQL 的查询短板问题，提供了一些更优秀的功能实现，比如更快的模糊查询，更好用的多字段自由组合查询，更丰富的统计接口和很强大的全文检索等等。该架构模式下，主要的业务逻辑还是通过 MySQL 完成，确实解决了查询的痛点，但同时暴露了一个新的问题，用户需要自己维护数据同步服务，保证两部分数据的一致性，因此，这里需要考虑如何完成数据同步。
常见的同步方案是监听 MySQL 的 binlog 异步写数据到 Elasticsearch 中，同步过程中为了解决消费乱序、消费失败、数据不一致等问题，引入了 Canal、Kafka 等中间件来，还需要自己定制化地开发同步组件。
该架构确实解决了查询的短板问题，为用户带来了优秀的查询体验，但还是有些问题没有解决：
- 当数据量和业务量翻倍后，容量和性能又再次遇到瓶颈。要解决新的单机瓶颈，这时候需要重新分库分表，带来的体验很差。或者是寻找一款可以横向扩展的数据库组件，不用考虑单机瓶颈，因此无需进行分库分表，从根本上解决单机瓶颈问题。
- 该架构引入的数据同步链路较长，开发复杂、运维成本极高，一旦出现丢数据的问题，处理起来比较麻烦。
- Elasticsearch 需要进行运维和优化，即便是云上托管的 Elasticsearch 服务也需要进行运维和优化，因此这里也会存在很大一部分开销成本。
无分库分表
分库分表可以分散单库单表的压力，但是需要预先规划好容量，一旦触发再次扩容，需要重新进行数据 hash 迁移，代价较高，我们期望寻找一种无分库分表的解决方案。
MySQL + Tablestore
表格存储（Tablestore）是阿里云自研的结构化数据存储服务，提供海量结构化数据存储以及快速的查询和分析服务。表格存储的分布式存储和强大的索引引擎能够支持 PB 级存储、千万 TPS 以及毫秒级延迟的服务能力。
采用 MySQL+Tablestore 的架构方案后，上述架构遇到的各种问题都能够解决，包括MySQL查询瓶颈和容量问题、数据同步的开发成本问题、数据一致性问题、组件过多带来的维护复杂问题等等。该架构简单清晰，两个系统能力互补，可以发挥各自系统最大的优势，且成本最低、性能最好、扩展性最强，可以支撑X10，X100的业务增长。
该架构依赖 MySQL 和 Tablestore 作为核心组件，MySQL 完成业务逻辑相关任务，且数据根据需求仅保留最近0.5 ~ 3个月，不会触发 MySQL 的各项瓶颈，因此无需再分库分表。Tablestore 作为订单数据中台完成订单查询、分析等一系列功能。该架构方案能够满足我们在需求分析中提到的各项需求，总结如下：
- 千亿级的数据存储能力。MySQL仅仅存储近一段时间的数据，Tablestore可以无限水平扩展，因此该架构方案的存储能力和容量都不是问题。
- 成本。Tablestore是采用存储计算分离架构，底层基于飞天盘古分布式文件系统，实现存储和计算成本分离，因此相对传统的MySQL等数据库成本要低很多。
- 查询功能及其完整度。Tablestore具有丰富的查询方式，包括基于主表的主键查询、主键范围查询，基于多元索引的多字段自由组合查询、模糊查询、统计聚合、全文检索、地理位置查询等。因为订单查询场景丰富，不同的查询场景需要不同类型的索引。Tablestore 提供多元化的索引来满足不同类型场景下的数据查询需求，其多元索引基于倒排索引和列式存储，可以应对大规模数据和复杂查询场景下的各项查询难题。
- 系统可用性和扩展能力。Tablestore 是一个 Serverless 服务化的产品，全托管，零运维。在大规模订单系统里，偶尔需要定期的大规模数据导入，来自在线数据库或者是来自离线计算引擎，此时需要有足够的计算能力能接纳高吞吐的写入，而平时可能仅需要比较小的计算能力，计算资源要足够的弹性。在订单量突增的情况下，Tablestore 能够自动水平扩容，用户无感知。Tablestore 的 Serverless 化让用户体验更好，做到开箱即用，弹性扩容，按量付费。
- 计算生态。企业在业务刚开始发展阶段，一般是不需要流计算和批计算的，只需要一个能处理业务逻辑、一个查询性能足够的订单系统即可，仅依赖 MySQL+Tablestore 即可满足大部分需求。当然，Tablestore 拥有丰富的计算生态，积极的拥抱开源，除了比较好的支持阿里云自研计算引擎如 MaxCompute 和 DataLakeAnalytics的计算对接，也能支持 Flink 和 Spark 等主流计算引擎的计算需求，无需数据搬迁。
基于MySQL+Tablestore的架构方案在阿里内部多个业务部门以及外部公司得到应用，使得订单查询和计算变得更加简单。阿里内部某百亿~千亿级订单系统采用基于Tablestore的设计后，效果改善十分明显：
- 存储瓶颈。之前MySQL容量告急，频繁扩容。采用基于 Tablestore 的方案后解决了大规模订单的容量问题，未来都不需要考虑扩容的问题。
- 查询性能。慢查询接口平均耗时从 7 秒左右降低到 100 毫秒。
- 成本。跟之前 MySQL 费用相比，成本下降7倍以上。
- 计算。采用基于 Tablestore 作为数据仓库和计算引擎进行对接后，之前的定时批量计算可以采用流计算，实时性更高，同时批量计算拉取速度更快，离线计算的数据可见性周期更短。
Tablestore
MySQL+Tablestore 的方案是一个相对完善的架构方案，如果不是强依赖MySQL，比如没有遗留系统必须依赖SQL等限制外，那么该架构还有精简的余地。去掉MySQL后，将仅仅依赖Tablestore完成订单系统相关的所有需求，系统的架构复杂度更低。
仅基于 Tablestore 的架构方案，是需要牺牲一些MySQL的能力，比如连表查询(join)、复杂事务、SQL语句支持等。 在 Tablestore上，一般是宽表的形式来存储订单，尽量避免 join。同时 Tablestore 支持分区键级别的事务，能满足一些简单的事务需求。关于 SQL 语句，大部分 SQL 都可以转化成 Tablestore 的 API。如果能够接受这些方面的不足，仅使用 Tablestore 将能够极大的降低架构复杂度，同时能够使用 Tablestore 更多的优势，包括大规模数据存储和扩展能力、较低的成本、完整的查询能力、高可用性、实时扩展能力、完善的计算生态等等。
总结
本篇文章主要探讨了大规模订单系统的需求和架构设计，从单 MySQL 到结合 NoSQL 弥补短板，到最后的MySQL+Tablestore，解决了容量、成本、查询性能、扩展、计算生态等各方面的问题，让大规模订单系统更加简单易实现。
除了订单外，其他类似订单的系统，比如物联网传感器数据、监控数据、日志、指令数据、通知消息等等也都可以采用订单系统类似的架构方案。
之后我们将会详细介绍大规模订单系统的一些实现细节。
- 存储篇：详细介绍基于 MySQL+Tablestore的大规模订单系统的架构实现细节。
- 计算篇：详细介绍 Tablestore 作为数据中台的计算生态，以及基于计算系统如何完成大规模订单系统中的一些特殊需求。
最后，欢迎加入我们的钉钉公开群（钉钉号：23307953），与我们一起探讨大规模订单系统的一些实现问题。
