前言

回顾过去二十年的技术发展，整个应用形态和技术架构发生了很大的升级换代，而任何技术的发展都与几个重要的变量相关。

一，应用形态的变迁，产生更多的场景和需求。整个应用形态从企业应用、互联网服务再到移动应用，历经了几个不同阶段的发展。从最早企业内应用系统，到通过移动互联网技术覆盖到每个人生活的方方面面，这个过程中产生了大量的场景和需求。而新的场景和需求，是推动产品和技术发展的主要因素。

二，更复杂的场景，更大规模的挑战，推动技术的快速发展。新一代应用面临更复杂的场景和更大的规模挑战，老一代技术架构无法支撑业务的快速发展，所以急需推动新的技术的研究和发展。这是一个综合的 ROI 的考虑，流量和数据到一定规模才能让技术架构升级带来更大的效率和成本的收益。

三，技术基础设施的完善，提供了技术和产品发展的基础。互联网、4G/5G 等基础设施的建立和完善，是新一代应用诞生和发展的基础。分布式技术、云计算、新一代硬件等技术的成熟，是技术架构变革的基础。

本篇文章会给大家分享应用系统数据架构的演进以及云上的架构最佳实践，这里先对数据系统的分类做一个定义，数据系统如果按照主体来区分的话分为以下两类：

1. 应用为主体：常见的数据架构都是以『应用』为主体，数据主要产生自应用。数据架构围绕业务来设计，通常是先定义业务模型后设计业务流程。由于业务之间区分度很大，每个业务都有截然不同的业务模型，所以数据系统需要具备高度『抽象』的能力，所以通常会选择关系型数据库这类抽象能力强的组件作为核心存储。
2. 数据为主体：这类数据系统通常围绕『特定类型数据』进行构建，比如说围绕云原生监控数据设计的以 Prometheus 为核心的监控数据系统，再比如围绕日志数据分析设计的 ELK 数据系统。这类数据系统的设计过程通常是围绕数据的收集、存储、处理、查询和分析等环节来设计整套数据系统，数据具备统一的『具象』的模型。不同的场景有不同的数据系统，当某个场景具备通用性以及得到一定规模的应用，通常在开源界会诞生一套成熟的、完整的解决方案，比如说云原生 Prometheus、ELK、Hadoop 等。

本篇文章介绍的数据架构主要是第一类，即以『应用为主体』的数据架构。

应用系统数据架构

应用系统数据架构历经了多次迭代，从传统的单一系统数据架构，到由多组件构成的现代数据架构。现代数据架构下包含不同的计算和存储组件，这些组件在处理不同类型数据以及负载下各有优劣。现代数据架构通过合理选择和组合这些组件，让各个组件能发挥最大的能力，从而让整个数据系统能满足更多样化的场景需求以及能支撑更大的数据规模。

传统数据架构（单一系统）

LAMP 架构

一个应用系统的基本构成包括：API（提供服务接口）、应用（业务处理逻辑）、数据存储（应用数据存储）以及运行环境（应用和数据库的运行环境）。互联网早期最流行的 LAMP 架构就是典型的单一系统数据架构，其中使用 Apache Server 作为 API 层、使用 PHP 开发应用，使用 MySQL 作为应用数据存储，所有组件均运行在 Linux 系统上。

整套架构采用开源软件构建，相比商业软件能提供更低的成本，所以能快速在互联网早期的各大中小站点流行起来，成为最流行的建站技术架构。但随着互联网的流量越来越大，LAMP 架构面临的最大的问题是可扩展性，需要解决应用和存储的扩展问题。

如何进行扩展

关于扩展技术的几个基本概念：

• Scale-up vs Scale-out
  • Scale-up 即直接提升机器的配置规格，是最直接的扩展手段，计算和存储均可通过 Scale-up 的方式来进行扩展，但扩展空间有限，相对成本较高。Scale-out 即增加更多的机器进来，是相对成本更低、更灵活的手段，但需要相关组件具备能 Scale-out 的能力。

• 存储和计算分离
  • 存储和计算是两个不同维度的资源，如果强绑定会极大限制扩展性。对数据系统来说，应用节点和存储节点分离就是应用了存储计算分离的设计思想，让应用和存储都能独立扩展。

Scale-out 具备更好的灵活性和经济性，计算和存储进行 Scale-out 的常见技术手段包括：

• 存储 Scale-out
  • 通常采用数据分片技术，将数据分散到多台机器上。

• 计算 Scale-out
  • 无状态计算：计算不依赖任何状态，可以发生在任意节点上，所以计算节点可非常容易实现 Scale-out，但需要解决计算调度问题。常见 Web 应用中的 LoadBalancer 后置一堆 Web Server 就是一个简单的无状态计算扩展架构。
  • 有状态计算：计算依赖状态，计算的扩展依赖状态的迁移。如果状态不可迁移，那计算的扩展只能采取 Scale-up 的方式。如果状态可迁移，那计算就可实现 Scale-out，此时计算的可扩展性依赖于状态迁移的灵活性。对于可 Scale-out 的计算我们分为两类实现方式，分别是：
    • 基于状态路由计算：通常用于状态迁移代价大的数据架构，比如数据库的分库分表。分库分表的扩展需要进行数据复制，所以通常需要提前规划，根据数据所在分片来路由计算。
    • 基于计算复制状态：如果状态能非常灵活的复制或者是共享，那可基于计算来复制状态，是一种更灵活的计算扩展架构。比如说基于共享存储的大数据计算架构，可灵活调度任意计算节点对数据进行处理。

可扩展的传统数据架构

LAMP 架构应用上面提到的扩展技术，演变成了上图的可扩展的数据架构。应用侧通常是无状态计算，所以可以简单采取 Scale-out 的扩展方式，前置 Load Balancer 来进行流量调度。存储侧采取分库分表的方式来进行存储和计算的扩展，以及只读库的方式来对查询计算进行扩展。虽然各层具备了扩展能力，但该系统还存在一些问题：

• 存储侧扩展灵活性差，扩展成本较高：计算侧通常是无状态计算节点，扩展相对灵活。但存储侧的扩展需要进行数据复制迁移，扩展周期长且灵活性差。同时 MySQL 的分库分表每次扩展需要双倍资源，成本也较高。
• 单一存储系统，提供的能力有限：MySQL 作为关系模型数据库，在业务模型抽象上提供极强的抽象能力，所以可以说是一个万能存储。在互联网早期应用负载不高的情况下，MySQL 是最优选择，且已经拥有了成熟的扩展方案。但是随着应用场景和负载不断变化，MySQL 还是难以承载。
• 存储成本高：简单来说，关系数据库是结构化数据存储单位成本最高的存储系统。

如何解决存储侧扩展问题

MySQL 不是万能的，但 MySQL 对应用系统来说是不可替换的，到目前为止都是这样。虽然现在有更多新的云原生关系数据库出现来取代传统 MySQL 的位置，但本质上都脱不了 MySQL 这个壳，只是更强大的 MySQL 而已。所以很多解决方案都是围绕 MySQL 作为辅助方案而不是替换方案出现，比如说 Memcached/Redis 这类缓存系统，帮助 MySQL 抵御大部分查询流量，来解决 MySQL 容易被查询打崩的问题。

这个设计思想是『分而治之』，将原本 MySQL 所承担的职责进行细分，能分离解决的就分离解决。现代数据架构就是基于此思路，仍然以 MySQL 作为应用交互和业务数据存储的核心，但是使用一些辅助方案解决 MySQL 的问题。

现代数据架构（多样化系统）

定义问题，分而治之

前面提到 MySQL 是应用系统数据架构的核心存储，且是不可替换的组件。MySQL 直接承载业务数据和大部分业务交互，现代数据架构的演进思路是围绕 MySQL 提供辅助解决方案，采用『分而治之』的设计思路。所以我们首先得罗列清楚在单一系统架构中 MySQL 所承担的职责，以及明确哪些点是可以分而治之的。分而治之的具体手段包括：

1. 流量卸载：承载和抵御 MySQL 的部分读写流量，让 MySQL 有更多资源进行事务处理。由于读和写依赖 MySQL 内数据，所以在卸载流量的同时还会复制全部或者部分数据。
2. 数据卸载：MySQL 内部分数据会用于事务处理，而部分数据仅存储和查询。不参与事务处理的数据可卸载，来降低表的存储量，对降成本和减负载都是有极大好处的。

为方便理解对 MySQL 承载的职责的具体含义，我们对应到一个实际场景来解释对应的职责，我们以『电商订单』系统来进行举例。

事务处理一般是需要根据数据库内的一致的状态决定操作的执行，必须要有 ACID 的保证，这部分只能由 MySQL 来承载。MySQL 的大部分查询流量都是可被卸载的，最简单的是创建只读库来卸载查询流量，但某些复杂查询操作只读库无法很高效的执行，必须依赖外部存储来加速，比如说数据搜索和数据分析。所以这部分流量需要卸载，并且需要复制部分或者全部数据。另外 MySQL 内存储的数据并不会都用于事务处理，很大一部分数据在生成后仅提供查询或非事务型操作，这部分数据的查询流量和存储都是可被卸载的。

我们把职责给定义清楚后，也明确了哪些职责是 MySQL 主要承担的，哪些职责是可以被卸载从而得以有效的『分而治之』的。

在理清了整个解决问题的思路后，接下来才是对架构师最大的挑战：如何选择合适的组件来卸载流量或者存储？

选择合适的存储组件

根据场景定义需求

准确的定义需求是选对组件的前置条件，切勿仅根据功能性需求来进行匹配，还需考虑一些基础性需求，例如存储组件可提供的 SLA、数据可靠性、扩展性、可运维性等等。从上面的表中，我们能够非常清晰的看到对各组件的功能性需求，那接下来我们再看看基础性需求如何区分和选择。

在做数据系统设计时可以把应用数据尝试落在上图的不同周期内，看下如何对存储组件定义合适的基础性需求。通常应用系统最先产生的是事务数据，事务数据会逐步向在线数据、离线数据转换和流动，在线性逐步降低，从面向前台逐步转向后台。再看从事务数据到离线数据，基础性要求的具体变化：

1. SLA 要求逐步从高到底，在线系统对稳定性要求极高，而后台系统相对来说要求可放低。
2. 从 TP 逐步转向 AP，TP 对访问延迟要求更高，而 AP 对分析能力要求更高。
3. 数据的更新频率逐步降低，逐步归档为不可变数据，所以很多离线系统都是基于数据的不可变性来做存储和计算优化。
4. 存储成本逐步降低，数据规模逐步增大。

存储组件的种类和差异

先从宏观层面比较下数据库类存储组件的差异：

• 数据模型和查询语言：这两个点仍然是不同数据库最显著的区别。关系模型、文档模型和宽表模型是相对抽象的模型，而类似时序模型和图模型等其他非关系模型是相对具象的模型。抽象模型表达力更强，而具象模型更贴近具体场景。
• SQL vs NoSQL：SQL 类更适合事务处理，包含开源或商业关系数据库；NoSQL 类更适合非事务数据处理，基本是以开源为主；场景使用上可以与 SQL 类配合使用，提供流量卸载和存储卸载；另外 NoSQL 类更多是具象模型，贴近场景而生。
• 数据库 vs 数据仓库：数据仓库更偏离线数据分析，提供更大规模存储，但是在 SLA 和稳定性方面相比数据库略差。
• 云托管 vs 云原生：云原生的本质是利用云上池化资源来实现更强的弹性，所以简单把一个开源软件托管在云上，并不能称之为云原生。云原生带来的优势是更低使用成本、更低运维成本、更灵活的数据流转以及更弹性的架构。

我们看下当前主流开源数据库以及对应的云原生数据库产品的对比：

在做存储组件选型时，要考虑功能性需求和基础性需求，选择合适的存储组件。以上表格只是列举了部分场景和其中推荐的产品，这些产品不是唯一选择也不一定是最适合的选择，因业务不同发展阶段和需求而异。选择对存储组件是一件很难的事，所以架构师在设计数据架构时，要提前考虑到存储组件的新增或替换，数据架构必须具备这样的灵活性，因为『构建快速迭代能力比应对未知需求的扩展性更重要』。

在一个复杂的应用系统中，必然会存在多套存储组件的组合，而不是单一的存储组件来支撑所有的场景和流量，所以架构师还得面临下一个难题：如何合理的组合这些存储组件？

合理的进行组合

派生数据架构

在数据系统架构中，我们可以看到会存在多套存储组件。对于这些存储组件中的数据，有些是来自应用的直写，有些是来自其他存储组件的数据复制。例如业务关系数据库的数据通常是来自业务，而高速缓存和搜索引擎的数据，通常是来自业务数据库的数据同步与复制。不同用途的存储组件有不同类型的上下游数据链路，我们可以大概将其归类为主存储和辅存储两类，这两类存储有不同的设计目标，主要特征为：

• 主存储：数据产生自业务或者是计算，通常为数据首先落地的存储。在应用系统数据架构中，MySQL 就是主存储。
• 辅存储：数据主要来自主存储的数据同步与复制，辅存储是主存储的某个视图，通常面向数据查询、检索和分析做优化。在应用系统数据架构中，承担流量卸载或存储卸载的存储组件，就是辅存储。

这种主与辅的存储组件相辅相成的架构设计，我们称之为『派生数据体系』。在这个体系下，最大的技术挑战是数据如何在主与辅之间进行同步与复制。

上图我们可以看到几个常见的数据复制方式：

• 应用层多写：这是实现最简单、依赖最少的一种实现方式，通常采取的方式是在应用代码中先向主存储写数据，后向辅存储写数据。这种方式不是很严谨，通常用在对数据可靠性要求不是很高的场景。因为存在的问题有很多，一是很难保证主与辅之间的数据一致性，无法处理数据写入失效问题；二是数据写入的消耗堆积在应用层，加重应用层的代码复杂度和计算负担，不是一种解耦很好的架构；三是扩展性较差，数据同步逻辑固化在代码中，比较难灵活添加辅存储。
• 异步队列复制：这是目前被应用比较广的架构，应用层将派生数据的写入通过队列来异步化和解耦。这种架构下可将主存储和辅存储的数据写入都异步化，也可仅将辅存储的数据写入异步化。第一种方式必须接受主存储可异步写入，否则只能采取第二种方式。而如果采用第二种方式的话，也会遇到和上一种『应用层多写』方案类似的问题，应用层也是多写，只不过是写主存储与队列，队列来解决多个辅存储的写入和扩展性问题。
• CDC（Change Data Capture）技术：这种架构下数据写入主存储后会由主存储再向辅存储进行同步，对应用层是最友好的，只需要与主存储打交道。主存储到辅存储的数据同步，则可以再利用异步队列复制技术来做。不过这种方案对主存储的能力有很高的要求，必须要求主存储能支持 CDC 技术。

『派生数据体系』是一个比较重要的技术架构设计理念，其中 CDC 技术是更好的驱动数据流动的关键手段。具备 CDC 技术的存储组件，才能更好的支撑数据派生体系，从而能让整个数据系统架构更加灵活，降低了数据一致性设计的复杂度，从而来面向高速迭代设计。MySQL 的 CDC 技术是比较成熟的，也演化出来一些中间件和云产品，比如 Canal 以及阿里云的 DTS。所以在我们的现代应用系统数据架构中，也主要是基于 MySQL 的 CDC 技术来进行数据派生。

现代应用系统数据架构

上图就是一个典型的现代应用系统数据架构，我们来系统的看下：

1. 由多存储组件构成，每个存储组件各司其职：
   1. MySQL：承载事务处理，为整个数据架构的主存储，其余组件承担流量卸载和存储卸载的职责。
   2. Redis：作为 MySQL 的查询结果集缓存，帮助 MySQL 来抵御大部分的查询流量，但 Redis 如果失效，则会有击穿 MySQL的风险。
   3. Elasticsearch：倒排索引和搜索引擎技术能提供 MySQL 索引所无法支持的高效模糊查询、全文检索和多字段组合条件过滤的能力，所以主要是承担复杂查询的流量卸载。
   4. HBase：分布式 KV 存储，提供宽表模型。可用于卸载 MySQL 内非事务性数据，可存储 MySQL 内所有表的全量数据，提供低成本的存储卸载。HBase 也是一个在线系统，所以也能提供简单查询的流量卸载。
   5. ClickHouse：MPP 架构的开源数仓，具备非常优异的分析性能，主要职责是分析流量卸载。
2. 基于 MySQL CDC 的派生数据架构，由开源产品 Canal 来做实时数据同步。但这里 ClickHouse 的数据同步并不一定需要是实时增量的，也可采用 T+1 的全量同步方式。
3. 应用系统需要与这些不同组件分别进行交互，且交互接口各不相同。

这个架构具备一定的灵活性，通过 Canal 来解决异构存储间的数据同步问题，通过插件机制可灵活增加新的存储组件来应对未来的新的需求。每个组件都是开源界打磨多年的成熟产品，也有一些中间件来降低应用与这些组件的交互成本。但也存在一些明显的问题：

1. 运维成本极大：运维是一门技术活，需要对组件的原理有比较清楚的了解才能更好的运维，以及进行线上问题的排查和优化。这些开源产品已经将使用成本降的足够低，但是运维成本还是很高，比如 HBase 组件的运维还需要额外运维 Zookeeper、HDFS 等。云托管产品降低了一定的运维成本，但仍无法做到免运维，业务 OPS 仍需要花大量精力在性能调优、容量规划等工作上。另外多组件会比单组件运维成本更高，因为还需要管理组件间的数据流。
2. 多 API 交互复杂：每个组件都提供了不尽相同的 API，应用与不同组件的交互很难抽象和解耦。
3. 成本高：每一个新的组件的引入都需要额外的存储和计算成本，但各组件的偏向不一样，有的更重计算有的更重存储。如果多组件间能共享计算或存储，那能极大的降低成本。而在当前的架构中，每个组件都是相互独立的，需要独享存储和计算资源。

云上数据架构实践

把现代数据架构搬到云上，可利用云的优势来优化整套架构：一是找到合适的云原生产品替换开源产品，最大好处是降低运维成本，其次能获得更强的稳定性和性能；二是用更少的组件做更多的事，来降低管理和使用成本，也能降低应用交互开发复杂度。

以上就是完整的云上数据架构，重点讲下替换开源组件的几个云产品：

• DTS（数据传输服务）：原理与 Canal 类似，能对接更多数据库上游和下游，全托管的 MySQL 实时数据同步中间件。
• Tair（Redis 企业版）：阿里自研企业级缓存，兼容 Redis 协议，具备更强的性能。
• Tablestore（表格存储）：阿里自研 Bigtable，提供兼容 HBase 的宽表引擎，以及能力和性能都优于 Elasticsearch 的索引引擎。纯 Serverless 免运维能最大程度降低运维成本，同时提供 API 和 SQL 的接口降低应用开发成本。
• ADB（分析型数据库）：阿里自研实时数仓，具备强大的分析性能，完全兼容 MySQL 协议。

接下来我们再重点提下 Tablestore，因为在应用系统在线场景，Tablestore 承载了流量卸载和存储卸载的重要职责。Tair 的使用和定位与 Redis 完全一致，而 Tablestore 相比 HBase 和 Elasticsearch 有更大的差异性。

表格存储 Tablestore

表格存储 Tablestore 是阿里云自研的面向海量结构化和半结构化数据存储的 Serverless 多模型结构化数据存储，被广泛用于社交、物联网、人工智能、元数据和大数据等业务场景。采用与 Google Bigtable 类似的宽表模型，天然的分布式架构，能支撑高吞吐的数据写入以及 PB 级数据存储，具体产品介绍可以参考官网以及权威指南。

Tablestore 提供兼容 HBase 的宽表引擎，以及能力和性能都优于 Elasticsearch 的索引引擎，它的核心能力包括：

• 多模型：提供抽象模型 WideColumn 宽表模型，以及具象模型 Timeline 消息模型以及 Timestream 时序模型。具象模型更适合应用与应用系统，而具象模型是围绕具体场景的数据架构而设计和深度优化。
• 多元化索引：提供二级索引和多元索引，不同查询加速场景提供不同的索引实现，其中多元索引能提供全文检索、地理位置检索以及灵活的多条件组合查询，功能和性能都优于 Elasticsearch。
• 存储计算分离架构：提供计算和存储侧的灵活扩展能力，不仅体现在架构上，也体现在产品形态上。用户可以单独为存储付费或为计算付费，提供更灵活的资源组合，获得最低的成本。
• Serverless 服务：纯 Serverless 服务，提供完全免运维的服务，全球部署、即开即用。零成本即可接入，最大可扩展至千万 TPS 服务能力以及 PB 级存储。
• 计算生态：能够与开源计算引擎对接，融合流批一体计算能力。同时自身提供 CDC 能力，让数据能够更灵活的进行流转。
• CDC 技术：Tablestore 的 CDC 技术名为 Tunnel Service，支持全量和增量的实时数据订阅，并且能无缝对接 Flink 流计算引擎来实现表内数据的实时流计算。
• SQL 支持：提供 SQL 支持，大大降低使用和应用开发门槛。

场景实践

为方便读者特别是开发者更好的理解云上应用系统数据架构的具体实现，我们特此准备了一个完整的实践 《基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践》。在该实践中会以订单系统为例，从需求出发来讲解本文中提到的『分而治之』设计思想的应用，以及如何实现存储卸载（存储分层）、查询、搜索、流批计算等，并给出具体的操作和代码。

《基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-架构篇》

《基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据同步 DTS 篇》

《基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据同步 Canal 篇》

《基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-订单搜索篇》

《基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-SQL 查询和分析》

《基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-基于 DLA 的联邦查询》

《基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据处理ETL篇》

《基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-历史数据分析篇》

《基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据流计算篇》

总结

技术架构的选择没有统一标准答案，是一个综合的权衡考虑。本文主要介绍了应用系统数据架构的变迁，我相信随着应用场景越来越复杂、更多需求的提出，随着底层基础设施的完善，会有更多新技术和产品出现，而数据架构也会继续演进。但是一些经典的设计思想会保留，例如分而治之、派生数据架构、如何灵活的选择和组合存储和计算组件等。

希望本次分享对你设计数据架构有帮助，如果希望继续交流，可以加入我们的开发者技术交流群，可搜索群号『11789671』或『23307953』，亦可直接扫码加入。