转载

微服务和数据库到底是什么关系?

过去几年来，“微服务架构”这个术语持续火热，它描述了一种将软件应用程序设计为可独立部署的服务套件的特定方式。尽管这种架构风格没有确切的定义，但围绕业务能力，自动化部署，网点智能以及语言和数据的分散控制等方面存在着某些共同特征。

简而言之，微服务架构是一种将单应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中运行，并与轻量级机制（通常是HTTP资源的API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。这些微服务的将集中化管理部分降到最少，同时，微服务还可以用不同的编程语言编写，并使用不同的数据存储技术。

而涉及到数据存储技术，就不得不谈到数据库，而实际上，微服务和数据库有着微妙的关系，微服务对于数据库也有着和传统架构不尽相同的需求，那么，微服务和数据库究竟有着什么样的关系？数据库又对微服务有何影响？如何选择适合微服务的数据库？巨杉数据库联合创始人兼CTO王涛向CSDN的记者分享了他的观点。

微服务架构催生分布式数据库

王涛认为，谈论数据库一定脱离不了应用。从应用程序开发来看，现在很多企业内部的应用开发都在从传统中间件加数据库的“烟囱式”开发，向微服务架构转型。而在微服务体系架构中，几乎每个微服务都需要提供数据持久化的能力，而用户也希望每个微服务所承载的数据量能够无限的弹性扩张。但是，在采用微服务架构的过程中，每个微服务使用自身独立的数据库存储又会使过去集中在一个地方的数据分散到很多不同的设备中，造成整个IT架构的数据严重碎片化。举例来说，一些互联网公司仅仅在生产系统中就维护着两、三万个MySQL数据库，这样的话，想要进行企业内部的数据整合是极为困难的。

实际上，此前，当企业用户采用微服务体系架构的时候，从数据管理的角度，业界有两种做法。

第一种做法，就是对应用程序进行微服务改造，底层数据库使用传统集中式数据库进行存储。这种做法对于应用程序的改造相对较小，对于DBA运维人员来说学习成本也较低，但是相应的，其存在数据紧耦合，无法弹性扩张，以及可能存在单点故障等问题。

第二种做法，可能也是现在业界使用比较多的方式，就是每一组微服务对应一个独立的小数据库，往往使用MySQL或PostgreSQL。这种机制能够解决集中式存储的问题，但是也带来了新的挑战，包括数据极度碎片化，在微服务之间无法共享，运维成本极其高昂。

因此，两种办法都不能很好的解决微服务下数据存储管理的问题，因此分布式数据库就是要解决上述的两个问题。第一就是针对每个微服务做到数据弹性扩张，第二就是对整个企业IT做到数据的统一治理从而避免碎片化存储。

打造适合微服务的分布式数据库

要打造适合微服务架构的数据库，巨杉数据库采用了计算存储分离的架构。其中存储层采用自研的原生分布式数据库引擎，上层计算层则可以创建成百上千个数据库实例，同时每个数据库实例对应用完全透明，不需感知。

因此，在这种系统架构下，从单个应用来看，和传统标准数据库完全一致，不需关注数据被切分在哪些不同物理设备上，做到弹性伸缩。同时，所有的物理设备从逻辑上进行统一管理，甚至不同实例里面的数据可以在可配置的权限下进行共享。

那么，适合微服务的分布式数据库都应该具有哪些特性呢？王涛认为这主要应该从两大维度、五个方面来看。

两大维度一是对传统技术的兼容，二是技术和架构的创新。

在对传统技术的兼容方面来看，首先，必须支持ACID。因为从数据库来看，尽管很多人说CAP不可兼得因此要牺牲一致性，但巨杉认为这是不可取的。对于大部分公司来说，数据都是核心生命线，绝对不能为了上分布式牺牲数据的一致性和安全性，需要对用户的财产和信息负责。因此，新型面向联机交易的分布式数据库必须对传统ACID有完美的支持，与传统Oracle DB2的数据安全性一致性保持兼容。

其次，SQL的完整性。这个主要是从对传统应用的兼容与开发人员能力重用的角度看。一般来说，SQL语法兼容的完整性，以及对已有标准的兼容必须具备，例如对MySQL、Oracle、DB2、PostgreSQL这种主流协议的兼容。

而从新技术的前瞻性来看，首先，未来是私有云和微服务应用的时代，那么作为分布式数据库，就不仅仅简单的将其定位成过去某一个数据库的替代。分布式数据库的核心价值在于，能够从数据库的层面以服务资源池的形式，向上层被从烟囱式架构向微服务架构拆散的成百上千个小服务提供数据库访问能力的平台。在这个定位下，数据库资源池在保证与传统数据库100%兼容的基础上，必须满足分布式弹性扩张，当资源池里面空间和计算能力不足时，需要通过动态增加计算存储节点的方式进行扩容。

其次，过去的数据库由于仅针对某一个特定应用，采用中间件和数据库一对一绑定的方式，因此只需要提供自身一种模式的访问就够了。但是当进行数据库资源池化的时候，上层应用自然面对来自不同开发商、不同业务类型、不同SLA级别的服务，大家采用的开发流程、SQL标准、以及安全策略各不相同，因此分布式数据库必须能够支持多种模式的访问接口。

最后，HTAP，即交易分析混合处理能力。譬如一些账务数据，可能最核心的关键应用来自于联机交易业务实时使用这些数据，但是同时一些后台的实时报表，或者安全审计机构需要进行统计分析的时候，来自不同微服务的业务可能需要对同一份数据同时以交易和分析的方式进行访问。这种情况下，能不能在资源池内对交易与分析业务进行物理资源隔离，及时对同一份数据同时访问并可以做到互不干扰尤为关键，因此，适合微服务的数据库必须具有较强的交易分析混合处理能力。

微服务和数据库到底是什么关系?

巨杉数据库，适合微服务的分布式数据库

正如同巨杉对于分布式数据库的技术定位和目标，巨杉数据库SequoiaDB本身就是以分布式存储底座与上层的数据库实例两层来进行构建的。底层的分布式存储作为资源池，自身负责数据的存储、分布式事务控制、记录和表锁等，都在底层原生分布式存储实现。

数据库实例层则提供对上层应用程序的SQL服务，用户可以创建MySQL、PostgreSQL、Spark SQL等结构化实例，也可以创建JSON或S3文件系统的非结构化实例。每个实例中的数据对上层应用来说完全透明。因此，在SequoiaDB中，一个MySQL表可以轻易存储十亿甚至百亿级别的数据，开发者在写SQL的时候完全不需要关注底层表到底被分散在多少台物理设备中。

作为业界原生分布式数据库以及新一代分布式数据库的代表，SequoiaDB对于分布式交易与ACID与传统技术完全兼容，架构与功能特性与传统数据库完全兼容。同时，SequoiaDB还积极拥抱新一代微服务与云计算框架，在面向微服务应用开发与云计算基础架构时，支持弹性扩张、资源隔离、多租户、可配置一致性、多模式（支持各类SQL协议）、集群内可配置容灾策略等一系列功能。

事实上，传统单点数据库的容量瓶颈，仅仅是分布式数据库所解决的问题之一。更重要的是在未来微服务化应用开发以及云化平台的趋势下，应用不再以“烟囱式”的中间件加数据库模式进行构建，而是采用数千甚至上万的微服务程序构建成的复杂网状模型。因此，分布式数据库需要能够满足上层应用的弹性扩展、高并发、高吞吐量、与灵活敏捷的需求。而SequoiaDB在这些方面都有着出色的表现，包括：

完整的ACID支持，事务和一致性保证；SQL的完整支持，传统数据库MySQL/PostgreSQL的语法完全兼容。分布式与扩展性，应对数据量的变化，实现存储层和计算层的弹性扩展；多模式访问接口，支持多类型数据管理和多种模式的访问接口； HTAP交易/分析混合处理能力，复杂业务需求下，实现数据的物理隔离，互不干扰。

而在此次大会最新发布的 3.2版本中，巨杉通对SequoiaDB进行大幅度性能优化与提升，使得其在分布式的交易型业务下，整体性能提升2~3倍，CPU消耗节省超过30%，从而大大提升了对微服务的支持力度。

SequoiaDB，不仅仅是支持微服务而已

实际上，SequoiaDB 并不仅仅是微服务的“良师益友”，其更大维度下的定位是一款真正的金融级分布式关系型数据库。

巨杉数据库目前在企业级应用场景主要包括分布式在线交易、数据中台以及分布式内容管理。

在线交易是数据库最广泛应用的场景之一，通常用来支撑核心业务运营。分布式在线交易数据库核心业务价值包括，分布式架构转型，高并发、高处理能力，业务持续扩展能力以及自主可控与数据安全要求。SequoiaDB存储引擎采用原生分布式架构，扩展便捷；完整支持分布式事务、强一致多副本高可用；无单点故障，数据库引擎原生支持多中心容灾。

数据中台是当前十分火热的概念，数据中台在企业微服务架构中的角色十分重要，像齿轮一样连通上层快速迭代的微服务应用和下层基础架构，同时还可以提供全量数据的实时在线服务，泛指传统核心交易以外的所有对外服务业务，基于SequoiaDB构建的数据中台核心业务价值包括：数据高性能实时访问，海量数据全生命周期在线，业务持续扩展能力。

内容管理平台为企业提供存储、管理和使用海量非结构化数据能力。常见应用包括影像平台、文档管理平台、音视频双录系统等。基于SequoiaDB搭建的内容管理平台的核心业务价值包括，海量非结构化数据管理和实时访问，丰富的内容管理功能，海量非结构化数据全生命周期在线以及业务持续扩展能力。

据悉，目前巨杉数据库已在近百家大型商业银行核心生产业务上线，并广泛应用于金融、电信、政府、互联网、交通等领域，企业用户总数超过1000家。同时，巨杉也是中国首家连续两年入选Gartner 数据库报告的数据库厂商。

微服务和数据库到底是什么关系?