微服务？数据库？它们之间究竟是啥关系？

过去几年来，“微服务架构”这个术语持续火热，它描述了一种将软件应用程序设计为可独立部署的服务套件的特定方式。尽管这种架构风格没有确切的定义，但围绕业务能力，自动化部署，网点智能以及语言和数据的分散控制等方面存在着某些共同特征。
简而言之，微服务架构是一种将单应用程序做为一套小型服务开发的方法，每种应用程序都在其本身的进程中运行，并与轻量级机制（一般是HTTP资源的API）进行通讯。这些服务是围绕业务功能构建的，能够经过全自动部署机制进行独立部署。这些微服务的将集中化管理部分降到最少，同时，微服务还能够用不一样的编程语言编写，并使用不一样的数据存储技术。
而涉及到数据存储技术，就不得不谈到数据库，而实际上，微服务和数据库有着微妙的关系，微服务对于数据库也有着和传统架构不尽相同的需求，那么，微服务和数据库究竟有着什么样的关系？数据库又对微服务有何影响？如何选择适合微服务的数据库？巨杉数据库联合创始人兼CTO王涛向CSDN的记者分享了他的观点。

微服务架构催生分布式数据库
王涛认为，谈论数据库必定脱离不了应用。从应用程序开发来看，如今不少企业内部的应用开发都在从传统中间件加数据库的“烟囱式”开发，向微服务架构转型。而在微服务体系架构中，几乎每一个微服务都须要提供数据持久化的能力，而用户也但愿每一个微服务所承载的数据量可以无限的弹性扩张。可是，在采用微服务架构的过程当中，每一个微服务使用自身独立的数据库存储又会使过去集中在一个地方的数据分散到不少不一样的设备中，形成整个IT架构的数据严重碎片化。举例来讲，一些互联网公司仅仅在生产系统中就维护着两、三万个MySQL数据库，这样的话，想要进行企业内部的数据整合是极为困难的。
实际上，此前，当企业用户采用微服务体系架构的时候，从数据管理的角度，业界有两种作法。
第一种作法，就是对应用程序进行微服务改造，底层数据库使用传统集中式数据库进行存储。这种作法对于应用程序的改造相对较小，对于DBA运维人员来讲学习成本也较低，可是相应的，其存在数据紧耦合，没法弹性扩张，以及可能存在单点故障等问题。
第二种作法，可能也是如今业界使用比较多的方式，就是每一组微服务对应一个独立的小数据库，每每使用MySQL或PostgreSQL。这种机制可以解决集中式存储的问题，可是也带来了新的挑战，包括数据极度碎片化，在微服务之间没法共享，运维成本极其高昂。
所以，两种办法都不能很好的解决微服务下数据存储管理的问题，所以分布式数据库就是要解决上述的两个问题。第一就是针对每一个微服务作到数据弹性扩张，第二就是对整个企业IT作到数据的统一治理从而避免碎片化存储。

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

要打造适合微服务架构的数据库，巨杉数据库采用了计算存储分离的架构。其中存储层采用自研的原生分布式数据库引擎，上层计算层则能够建立成百上千个数据库实例，同时每一个数据库实例对应用彻底透明，不需感知。
所以，在这种系统架构下，从单个应用来看，和传统标准数据库彻底一致，不需关注数据被切分在哪些不一样物理设备上，作到弹性伸缩。同时，全部的物理设备从逻辑上进行统一管理，甚至不一样实例里面的数据能够在可配置的权限下进行共享。
那么，适合微服务的分布式数据库都应该具备哪些特性呢？王涛认为这主要应该从两大维度、五个方面来看。
两大维度一是对传统技术的兼容，二是技术和架构的创新。
在对传统技术的兼容方面来看，首先，必须支持ACID。由于从数据库来看，尽管不少人说CAP不可兼得所以要牺牲一致性，但巨杉认为这是不可取的。对于大部分公司来讲，数据都是核心生命线，绝对不能为了上分布式牺牲数据的一致性和安全性，须要对用户的财产和信息负责。所以，新型面向联机交易的分布式数据库必须对传统ACID有完美的支持，与传统Oracle DB2的数据安全性一致性保持兼容。
其次，SQL的完整性。这个主要是从对传统应用的兼容与开发人员能力重用的角度看。通常来讲，SQL语法兼容的完整性，以及对已有标准的兼容必须具有，例如对MySQL、Oracle、DB二、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 数据库报告的数据库厂商。