下载掌阅APP，畅读海量书库
立即打开
云原生数据库在架构设计上最显著的特点，即将原本一体运行的数据库进行拆解 [3][4] 。分层架构的处理流程分为计算服务层、存储服务层和共享存储层。其中，计算服务层负责解析SQL请求，并转化为物理执行计划。存储服务层负责数据缓存管理与事务处理，保证数据的更新和读取符合事务的ACID语义，在实现中不一定是物理分离的，可能一部分集成在计算服务层，一部分集成在共享存储层。共享存储层负责数据的持久化存储，利用分布式一致性协议保证数据的一致性与可靠性。
在云原生时代，云基础设施通过虚拟化的技术实现资源池化。基于2.3.1节所述的分层架构，云原生数据库可以有效地将计算和存储资源解耦，从而分别扩展。因此在资源池化之后，云原生数据库可以按需按量使用、弹性调度资源。
在资源解耦进展上，目前业界是将CPU和内存绑在一起，和SSD持久化存储分开。但随着非易失存储技术和RDMA技术的成熟，下一步甚至会将CPU和内存进行隔离，内存再进行池化，形成三层池化，更好地帮助客户实现按需按量使用资源。
传统的中间件分库分表的方案和企业级的透明分布式数据库都会面临一个挑战：在分布式架构下，数据只能按照一个逻辑进行分片（Sharding）和分区（Partition），业务逻辑和分库逻辑不是完美一致的，一定会产生跨库事务和跨分片处理，每当ACID要求较高时，分布式架构会带来较高的系统性能挑战。例如在高隔离级别下，如果分布式事务占比超过整个事务的5%，那么系统吞吐量会有明显的损耗。完美的分库策略是不存在的，这是分布式业务需要解决的核心挑战，同时需要保证在这个架构数据的高一致性。
云原生的架构，在本质上，下层是分布式共享存储，上层是分布式共享计算池，中间层用于计算存储解耦，这样可以非常好地提供弹性高可用能力，做到分布式技术集中式部署，从而对应用透明。
分布式系统的多个节点通过消息传递进行通信和协调，其不可避免地会出现节点故障、通信异常和网络分区等问题。采用一致性协议可以保证在可能发生上述异常的分布式系统中的多个节点就某个值达成一致。
在分布式领域中，CAP理论 [2] 认为任何基于网络的数据共享系统最多只能满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）三个特性中的两个。其中，一致性指更新操作完成后，各个节点可以同时看到数据的最新版本，各节点的数据完全一致；可用性指在集群的部分节点发生故障时，系统可以在正常响应时间内对外提供服务；分区容忍性指在遇到节点故障或网络分区时，系统能够保证服务的一致性和可用性。由于是分布式系统，网络分区一定会发生，天然地需要满足分区容忍性，因此需要在一致性和可用性之间做出权衡。在实际应用中，云原生数据库通常采用异步多副本复制的方式，例如Paxos、Raft等一致性协议，保证系统的可用性和最终一致性，以牺牲强一致性的代价换取系统可用性的提升。
在线上使用时，云原生数据库会提供不同的高可用策略。高可用策略是根据用户自身业务的特点，采用服务优先级和数据复制方式之间的不同组合，组合出适合自身业务特点的高可用策略。服务优先级有以下两种策略，可以方便用户在可用性和一致性之间做出权衡。
· RTO（Recovery Time Objective）优先：数据库应该尽快恢复服务，即可用时间最长。对于数据库在线时间要求比较高的用户，应该使用RTO优先策略。
· RPO（Recovery Point Objective）优先：数据库应该尽可能保障数据的可靠性，即数据丢失量最少。对于数据一致性要求比较高的用户，应该使用RPO优先策略。
多租户指一套系统能够支撑多个租户。一个租户通常是具有相似的访问模式和权限的一组用户，典型的租户是同一个组织或者公司的若干用户。要实现多租户，首先需要考虑的是数据层面的多租户。数据库层的多租户模型对上层服务和应用的多租户实现有突出影响。多租户通常有某种形式的资源共享，需要避免某个租户的业务“吃掉”系统资源，影响其他租户业务的响应时间。一般实现多租户会采用一租户一数据库系统，或者多租户共享同一个数据库系统，通过命名空间等方式隔离，但是这种模式运维和管理比较复杂。在云原生场景下，数据库可以为不同的租户绑定相应的计算和存储节点以实现资源的隔离和面向不同租户的资源调度。
智能化运维技术是云原生数据库的重要特性。云原生数据库一般通过简易的操作界面和自动化流程帮助用户快速完成常见的运维任务，并可以在多数任务下执行自动化操作：
· 支持自定义备份策略，通过复制实例恢复到任意时间点，找回误删数据。
· 自动在线热升级，及时修复已知Bug。
· 资源和引擎双重监控，链接云监控自定义报警策略。
· 节点故障秒级探测，分钟级切换。
· 提供专家级自助式服务，可解决大部分场景的性能问题。
参考文献
[1]LI F.Cloud-native database systems at Alibaba:Opportunities and challenges[J].Proceedings of the VLDB Endowment, 2019, 12(12):2263-2272.
[2]GILBERT S, LYNCH N.Brewer's conjecture and the feasibility of consistent, available, partitiontolerant web services[J].Acm Sigact News, 2002, 33(2):51-59.
[3]VERBITSKI A, GUPTA A, SAHA D, et al. Amazon aurora: Design considerations for high throughput cloud-native relational databases[C]//Proceedings of the 2017 ACM International Conference on Management of Data, 2017: 1041-1052.
[4]CORBETT J C, DEAN J, EPSTEIN M, et al. Spanner: Google's globally distributed database[J].ACM Transactions on Computer Systems (TOCS), 2013, 31(3): 1-22.