浅析小程序云原生数据库的设计与应用 - WXOPEN Club

作者：杨哲、刘翔、王伟嘉

小程序云开发拥有易接入、高性能、高可用等特性，提供完整的原生云端能力支持，可有效降低后端与运维成本，帮助开发者更专注于业务，实现快速上线与迭代。其中，小程序云开发的数据库是一个既可在小程序前端操作、也能在云函数中读写的 JSON 数据库，强大且稳定。

本篇，将简要地为大家介绍，我们是怎样为云开发构建一个安全易用、高性能和高可用的nosql文档型数据库。

Serverless理念引领新的开发趋势

在介绍云开发数据库的架构前，我先简单介绍一下云开发数据库的设计背景。

对于小程序等应用的开发者而言，传统的开发模式和敏捷开发模式除了需要开发者编写核心的业务逻辑外，都不可避免地需要对后端的基础设施进行管控和优化。比如，一个应用的逻辑可以很简单，可一旦涉及到应用的发布部署，就需要开发者花费大量精力进行服务器、数据库、网络等基础设施的申请和搭建，还要考虑这些后端基础设施的稳定性、可用性和监控指标。这一切耗时耗力又与产品的核心功能无关，对于需要快速开发和试错的产品，传统的模式开发速度慢、部署和运维成本较高。

但通过serverless无服务器架构，用户可以无需关心后端的基础设施，直接通过云API一键接入云函数、云数据库和云存储来获取算力、数据库、存储等基础的后端能力。这种随用随取的开发模式，不但可以让开发者能更专注于自身的业务逻辑，还具有低成本、开发速度快以及免运维等诸多优势。对于小程序云开发而言，它结合了serverless和小程序的两者的开发理念，以微信作为小程序前端运行的依托，同时又通过接入云函数、云数据库和云存储，来达到对后端基础设施的开箱即用。这些特性可以在很大程度上解放小程序开发者的生产力，降低开发的成本和难度，让小程序开发者向全栈发展，更容易开发出稳定高效的后端服务。想了解更多可以查看云开发产品文档：https://cloud.tencent.com/product/tcb

例如，腾讯相册这款官方小程序就使用云开发来构建。

传统的开发模式，开发者必须从小程序端开始，发送一系列请求到后台进行鉴权，文件和数据库处理等繁琐的操作，同时也需要耗费不少精力进行许多基础服务的设计和搭建以及后期的运维等工作。

但通过云开发，开发者可以天然地获取微信的登录态、方便地获取存储和数据库等能力，其它的负载、容灾、监控等，都由云开发来负责，而这一切都对开发者是透明的。这就大大提高了开发者的效率。

通过云开发，腾讯相册小程序将开发时间由1周以上压缩到只有1到2天。

云开发数据库架构介绍

云数据库作为云开发中的数据库组件，具有以下几个特点：

1、安全性：对于数据库而言，安全性是第一位的，丢数据的情况不可容忍

2、易用性：云数据库开箱即用，用完即走，无需运维部署

3、低成本：云数据库支持按访问量、数据量收费，成本控制更精细更低廉

4、高性能：云数据作为一款nosql文档型数据库，天然具有非常高的读写性能。同时我们底层硬件也使用了固态硬盘来提供更强的读写能力

5、灵活性：当用户业务量扩展，需要更大规模更高性能的数据库时，云数据库也支持热迁移上云，过程用户无感知

下面，我将对云开发数据库的基本架构做一个简要的介绍。

云数据的整体架构可以分为这么几部分：最上层的客户端、中间部分的接入层、底部的存储层及周边管控、告警、备份模块等。

我们从最上层的客户端部分看起，开发者通过云开发提供的SDK，可以在微信小程序和qq小程序中一键获取云数据库的登录态，然后将数据读写请求发送给接入层。接入层收到用户的读写请求后，由keeper和agent这两个无状态的模块对接入的读写请求进行相关处理。

其中keeper主要负载请求的鉴权、认证缓存，以及读写请求数的统计，是云数据库权限校验，负载均衡和计费功能实现的核心模块。同时，keeper还对事务类的请求进行了优化，通过一致性哈希和缓存会话，keeper会将不同事务的请求压力分摊到agent模块，提供更好的事务使用性能。

agent模块则有下面几大功能：

一、是维护接入层到底层数据库实例的连接池，通过复用已建立的连接来减少请求鉴权和连接创建的耗时。

二、是统计请求的并发数，对读写请求的QPS进行平滑处理，避免短时间的毛刺影响数据库性能和可用性。三是对热迁移的优化，通过agent模块，我们会在热迁移切换数据库实例时，将请求挂起，切换后再将请求恢复这种方式，实现热迁移过程对用户的全程无感知。

读写请求通过了接入层，再接下来会进入到我们的存储层进行数据库实例的读写。而我们的数据库实例在设计上具有如下几个特点：

一、为了保证数据库的高可用，我们的每个数据库实例都是由一个副本集整体来进行服务。

二、数据安全性方面，我们使用了一致性算法来保证副本集数据的最终一致性。通过定期备份支持用户将数据回档到指定时刻。

三、我们也充分利用云数据的日志、监控、拨测等模块收集的信息，对云数据进行了自动化的运维的相关设计，对常见数据库异常进行秒级探测和自动处理，保证用户业务平稳运行。

云开发数据库设计与优化

那么，围绕云开发数据库，我们做了哪些特性优化呢？

1、访问控制优化

首先是权限控制方面。用户只能访问自己的数据库,所有连接必须__认证__，用户无法访问其他用户的数据库。但可以在自己的数据库上建立多个__不同权限的账户__（比如建一个只读的账户）。当然有了微信全链路免鉴权的特性，这里用户不需要太关心认证问题。

其次是连接数控制方面。我们会分两层进行控制：

1）在接入层进行__客户端连接控制__，根据初始化时实例类型（免费/付费等）进行不同的初始化限制，如果超过限制则提示相应的用户；

2）接入层到存储层也有相应的连接数控制，会__池化__到后端数据库所有主从节点的链接，避免因过多链接而导致的数据库性能问题。

最后是机器层面的出入流量控制以及资源使用限制，原理与连接数控制类似。用户所有的请求都会经过接入层，因此可以在接入层控制qps进而实现后续的__按量付费__功能。qps超过阈值后可以提示用户或者在接入层做排队处理。

PS：有人可能会质疑了，这里不是弹性伸缩的嘛？为何还有qps的限制呢？不应该是我qps越来越高，后端的数据库资源也跟着不断扩容嘛？

是的，默认的配置下会有一定弹性扩展空间，但是会有一个限制。当然，这里限制具体多少跟产品策略有关。

2、数据安全优化

数据安全是数据库最重要的特性之一。毕竟一个存在丢数据风险的数据库并不可能在市场激烈的竞争中活下来。那么云数据库是如何保证数据安全的呢？

1）分布式多副本容灾。云开发数据库底层默认三副本，即一份数据会存储三份放在不同的机器上。节点区分主从状态，主节点可写可读，从节点只读。存储节点之间采用__raft-like__的副本集协议来实现三副本数据的__最终一致性__。另外，所有到数据库的连接必须认证以及所有数据均__加密压缩__存储这两点保证了数据的链路安全以及存储安全。

2）高可用。当机器发生故障时副本集内的数据节点会自动切换（FailOver），从节点变为主节点继续提供服务，将对业务的影响降到最低。

3）备份/回档能力。备份对用户__完全****透明__，后台根据数据库的状态自动选择性地进行全量以及增量备份；支持7天内任意时间回档，可以选择只回档__单个库表__，大大减少回档所需的时间。

另外，如果节点故障需要新加一个节点到副本集中，可选择从备份文件中进行恢复，减少对源集群的__侵入性__。

4）多可用区容灾。云数据库默认跨三机房（AZ）部署，也对用户透明，任意一个机房挂掉也不会对服务产生任何影响；同时也可以支持跨多地域，两地三中心等模式。比如北京、上海、深圳各有一个节点，业务采取就近接入的方式来降低业务访问元数据的时延。

具体云数据库的安全规则可以查看这里：安全规则技术说明。

3、弹性伸缩

很多时候，业务的访问呈现很明显的周期性或者不均匀的特征，比如外卖类业务属于饭点时高峰期，其他时段访问较少；游戏类业务属于晚上及周末高峰期，上班时间较少；还有一些电商类业务属于遇到特殊时间点（双十一，618）做活动大促时是高峰期等等。

如果按照传统的数据库运维模式，需要提前预估量级，然后运维执行扩容，等活动结束后再缩容回来（不然成本是个问题）。那么在小程序的场景，既然要做到用户对后端服务无感知，那么资源的扩缩容也应当不被感受到。

基于这个出发点，我们实现了云数据库的弹性伸缩。依赖管控系统的负载监控模块，我们可以动态地调整数据库的资源，并且自动调整敏感度，来有效应对数据库负载突增的情况，在负载低的时候也可以将资源释放提供给其他更需要的实例。其次，为了避免单个大查询引起的频繁调整，我们设置了滑动窗口和“去毛刺”机制，保证了弹性伸缩尽可能平滑地进行。