吃透这篇微服务数据架构，数据分类存储特性，关系数据库你就行了

微服务数据架构

微服务架构强调技术的多样性，选择最合适的技术解决业务的实际问题，这一原则同样适用于微服务数据存储领域。目前随着数据海量的增长、数据类型的多样性、对数据访问性能更快的诉求，关系数据库越来越不能满足用户的需求，于是NoSQL数据库应运而生。

本章我们首先介绍数据分类，以及不同数据类型适合采用的不同数据存储技术，同时介绍NoSQL存储与关系数据库的主要区别和特性。

在微服务架构下，对于数据一致性的处理，强一致性的事务管理机制不一定是适合的解决方案，之前单体架构下强一致性的事务模式在微服务架构中可能会带来一系列性能损失和数据一致性问题与挑战。微服务架构有很多不同的设计考量，它强调去中心化的数据治理，更强调每个微服务都拥有自己独立的数据存储，而不同服务在数据共享方面需要采取一定的策略和补偿方式来保证数据的一致性。通过对TCC、Saga等模式的介绍，我们可以了解当前微服务架构数据的最终一致性解决方案。

数据分类及存储特性

我们在实施“微服务”架构时，都希望可以让每一个服务来管理其自有的数据，这就是数据管理的去中心化。另外，微服务架构风格的一个关键好处是对持久性的封装，我们可以根据每个服务的不同需要，选择不同的持久化技术。根据每种数据类型的特点选择数据存储的方法也被称为混合持久化技术。

关系数据库概述

经过几十年的发展，关系数据库已经非常成熟，强大的SQL功能和ACID特性，使得关系数据库广泛应用于各式各样的系统中。在微服务架构中，对于事务性的业务类型和复杂的数据查询存储场景，依然建议采用关系数据库作为数据持久层解决方案。下图是典型的一个应用下不同模块访问数据库的模式。

​

核心概念

关系数据库就是建立在关系模型基础上的数据库。通俗来讲，这种数据库由多张表组成，并且这些表之间存在一定的关系。所谓RDBMS（Relational Database Management System，关系数据库管理系统），就是建立在关系模型基础上的数据库，借助集合代数等数学概念和方法来处理数据库中的数据。关系数据库的核心元素和术语如下。

● 记录：数据行，一行记录是一组相关的数据，例如一条用户订阅的数据。

● 字段：数据列，一列数据元素，包含了相同的数据，例如邮政编码的数据。

● 数据表：数据行的集合，表是数据的矩阵。数据库中的表看起来像一个简单的电子表格。

● 数据库：数据表的集合，数据库是一些关联表的集合。

● 主键：一个数据表中只能包含一个主键，可以使用主键来查询数据。

● 外键：外键用于关联两个表。

● 复合键：复合键（组合键）将多列作为一个索引键，一般用于复合索引。

● 索引：使用索引可快速访问数据库表中的特定信息。索引是对数据库表中一列或多列值进行排序的一种结构，类似图书的目录。注：索引查找使用B+数。

RDBMS的主要产品如下。

● Oracle：在以前的大型项目中使用，例如银行、电信等。

● MySQL：Web时代使用最广泛的关系数据库。

● MySQL Server：在微软的项目中使用。

● SQLite：轻量级数据库，主要应用在移动平台。

SQL

SQL（Structured Query Language）是结构化查询语言，是一种用来操作RDBMS的数据库语言，当前关系数据库都支持使用SQL进行操作。也就是说，可以通过SQL操作Oracle、MySQL、SQLite等所有的关系数据库。

MySQL数据库

MySQL是当下最为流行的关系数据库管理系统。在Web应用方面，MySQL是最好的RDBMS应用软件之一。MySQL由瑞典MySQL AB公司开发，目前属于Oracle公司。MySQL将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度，并提高了灵活性。

关系数据库的优势

● 容易理解：二维表结构易于理解，方便根据现实世界建模。相对网状、层次等其他模型来说，关系模型更容易理解。

● 支持SQL：大多数程序员都比较熟悉用SQL来操作数据，同时SQL支持复杂的JOIN等查询。

● 数据一致性：关系数据库支持ACID特性，以及数据库层的事务处理原语支持。适合OLTP事务型的业务数据类型，保持数据的一致性是中心化数据库架构的最大优势。

● 易于维护：丰富的完整性（指实体完整性、参照完整性和用户定义的完整性）大大减低了数据冗余和数据不一致的概率。

● 数据库支持按需配置弹性可伸缩，双机热备保证服务高可用，多份数据备份使业务高可靠。提供高性能的物理设备来保证数据库的性能。

关系数据库的缺点

● 关系数据库存储的是行记录，无法存储数据结构，使用关系数据库存储只能将列表拆成多行，然后查询出来后组装，无法直接存储列表。

● 关系数据库的Schema（数据或模式对象的逻辑结构的集合）扩展很不方便。关系数据库的表结构Schema是强约束，操作不存在的列时会报错，业务变化时扩充列也比较麻烦，需要执行 DDL （ Data Definition Language ， 如 CREATE 、 ALTER 、DROP等）语句修改，而且修改时可能会长时间锁表。

● 如果对一些有大量数据的表进行统计之类的运算，关系数据库的I/O会很高，因为即使只针对其中某一列进行运算，关系数据库也会将整行数据从存储设备读入内存。

● 关系数据库的全文搜索功能比较弱，关系数据库的全文搜索只能使用like进行整表扫描匹配，性能非常低，在互联网这种搜索复杂的场景下无法满足业务要求。关系数据库与对象持久化存在阻抗不匹配问题，所以在面向对象系统中，需要使用第三方提供的数据转换工具，类似MyBatis框架进行数据转换，造成了开发效率和性能的降低。

从数据分类和数据存储特点的角度来看，针对关系数据库的上述问题，可以通过不同的NoSQL解决方案进行优化解决，这些方案与关系数据库相比，在很多微服务应用场景下会有更好的表现。

同时，在微服务场景下，我们的应用作为微服务单独的单元构建起来，微服务不应该追求与持久化存储相匹配，应该摒弃传统的基于数据库脚本驱动的开发模式，利用后端数据层的优势和功能来满足应用程序的需求。所以，我们有必要根据微服务后端连接的数据，选择更加合适的存储技术。