云上应用系统数据存储架构演进

一 前言

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

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

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

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

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

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

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

二 应用系统数据架构

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

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

LAMP 架构

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

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

如何进行扩展

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

• Scale-up vs Scale-outScale-up 即直接提升机器的配置规格，是最直接的扩展手段，计算和存储均可通过 Scale-up 的方式来进行扩展，但扩展空间有限，相对成本较高。Scale-out 即增加更多的机器进来，是相对成本更低、更灵活的手段，但需要相关组件具备能 Scale-out 的能力。
• 存储和计算分离存储和计算是两个不同维度的资源，如果强绑定会极大限制扩展性。对数据系统来说，应用节点和存储节点分离就是应用了存储计算分离的设计思想，让应用和存储都能独立扩展。

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

• 存储 Scale-out通常采用数据分片技术，将数据分散到多台机器上。
• 计算 Scale-out基于状态路由计算：通常用于状态迁移代价