小程序云原生数据库的设计与挑战

小程序云开发（腾讯CloudBase）具有易访问、高性能、高可用等特点。云数据库作为核心组件之一，可以有效降低运维成本，帮助开发者快速启动和重复业务。本文将简要介绍如何通过TEG云架构平台部的高性能分布式NoSQL数据库，为近百万小型应用云开发用户提供完整的原生云数据库能力支持。 ？本节我们也尝试从这两个方面来简单梳理一下相关的背景知识。

1.1 云开发

从软件工程的角度来看，软件开发经历了以下三个阶段：传统开发-->敏捷迭代-->Serverless。传统开发模式和敏捷开发模式除了要求开发人员编写核心业务逻辑外，都不可避免地需要对后端基础设施进行管理、控制和优化。例如，一个应用程序的逻辑可能很简单，但一旦涉及到应用程序的发布和部署，开发人员就必须花费大量的精力去申请和建设服务器、数据库、网络等基础设施，同时还要考虑这些后端基础设施的稳定性。性能、可用​​性和监控指标。这一切都是费时费力的，与产品的核心功能无关。对于需要快速开发和试错的产品，传统模式开发速度慢，实施和运维成本较高。

随着Serverless概念的流行，越来越多的开发者转向Serverless架构开发。 **“无服务器”**并不是指后端没有服务器，而是指后端服务器及相关运维操作对上层应用开发者来说是不可见、透明的。用户无需担心后端基础设施。他们可以通过云API，一键直接访问云函数、云数据库、云存储，获得算力、数据库、存储等基础后端功能。这种即用型的开发模式不仅可以让开发者更加专注于自己的业务逻辑，而且还具有成本低、开发速度快、免运维等诸多优点。

1.2 小程序

小程序不需要太多介绍。我想每个使用智能手机的人在日常生活中都已经或多或少的使用过各种小程序：点餐、外卖、打车、购物等等。为了严谨起见，我们按照下图给出一个简单的定义：张小龙朋友圈介绍：小程序是一种无需下载安装即可使用的程序。实现了应用“触手可及”的梦想。用户可以扫描或搜索来打开应用程序。也体现了“用完即走”的理念，用户无需担心安装太多应用程序。应用程序将无处不在、随时可用，但无需安装或卸载它们。

自2017年1月9日微信发布小程序以来（距乔布斯发布第一部iPhone正好十年，有媒体解读为对张小龙的致敬和野心的体现），小程序的发展超过了这些年来，互联网已经形成了完整的生态系统，用户数量和微件数量也取得了长足的进步和发展。其他主流互联网公司也开始落地小部件平台，比如支付宝小部件、百度小部件、抖音小部件等。微信提供的数据显示，2019年微信小程序全球交易额超过8000亿，同比增长160%，日活跃用户超过3亿。目前，微信上在线小部件已超过100万个，用户数量超过150万。开发者、超过8200个第三方平台和小部件在电商和零售行业与去年相比出现了爆发式增长。截至2020微信公开课PRO（也是1月9日），全网小程序数量已突破450万个。可以说，我们已经进入了一个“全民小程序”的时代。

受今年COVID-19疫情影响，由于小程序开发比App开发更容易、门槛更低，也能接触到更多人群，所以各种健康码、申报、信息核验等大部分都是通过了。以小程序的形式推出。同样，线下实体店客流受阻，越来越多的商家和门店将销售转移到线上，以保证疫情期间的现金流。 Widget 也是这种场景的最佳选择。

小部件的日益多样化和流行意味着越来越多的小部件开发者想要进入这个市场。如何基于widget生态来服务这些开发者就成了一个问题。有件事需要解决。于是小程序云开发就出来了。可以说，小程序需求+Serverless理念=小程序云开发。小程序云开发依托微信作为小程序的前端运行，同时通过接入云函数、云数据库等云服务，实现后端基础设施的“开箱即用”。云储存。这些功能可以极大地释放小型软件开发人员的生产力，并大大降低开发成本和难度。

2.竞品分析

事实上，互联网巨头对这个市场的兴趣由来已久。以谷歌为例。自2014年10月收购FileBase以来，Google将其现有的云服务和工具集成到FileBase中，使其成为一站式BaaS（Backend as a service，后端即服务）产品，涵盖四大主要领域开发、质量、分析开发、认证交付、数据库、存储、云功能、机器学习等服务模块，以及多种性能和数据分析工具。

如果你专注于其数据库产品，Filebase提供了两个选项：Cloud Filestore和Real-time Database。虽然它们都是NoSQL数据库，但官方推荐前者，因为它可以提供高性能、良好的可扩展性和其他更高级的功能。参考官网​​的介绍，云文件存储的主要特点如下：

• 灵活性——支持灵活的分层数据结构、文档类型；
• 表达性查询——支持过滤/排序等功能，自动索引，查询性能与结果集的大小成正比（而不是整个数据集的大小）；
• 实时更新——支持数据实时同步；
• 离线支持——缓存离线写入、读取和查询，当您重新上线时同步本地更改；
• 扩展性涉及——基础设施支持自动多区域数据复制、强一致性保证、原子批量操作和事务支持；

另外，filestore支持按需付费计费 是的，可以支持根据数据存储量、流量以及读取（查询）、写入（插入/更新）和删除（删除）的文档数量进行计费操作。并对外提供多个客户端和开发语言版本的sdk。

其他著名的 BaaS 产品包括 Parse，它首先被 Facebook 合并，但不久后就停止运行。目前它作为开源产品运行在GitHub上，需要开发者自己下载源码、部署和维护，已经失去了BaaS的意义。

同样，国内也有很多产品提供**一站式后端服务（BaaS），包括：LeanCloud、Bmob、willddog野狗云服务、智智云等。小程序云开发腾讯云推出的（Tencent CloudBase，TCB）也是同一赛道的产品，即采用Serverless架构的一体化后端云服务。

3。需求与挑战

那么，数据库小型应用云开发的基本要求是什么？面临哪些挑战？ ？功能类似，“开箱即用，用完就跑”，上手简单，无需运维；

当然，最大的挑战是如何利用现有技术同时满足这五个需求，并在它们之间取得良好的平衡。毕竟，在大多数情况下，我们并不是提出新的架构，而是在几种解决方案和组件之间进行选择。就像分布式系统中著名的CAP理论一样，你只能选择一致性/可用性/分区容错性。选择其中两个。

下面先介绍我们使用的架构，然后解释这样的架构下的挑战以及我们采取的相应解决方案。 （不一定是最优方案，读者可以用自己的思维去看，看看我们如何进行权衡）

四．架构和解决方案

围绕前面提到的5个主要需求，我们从架构开始。云开发数据库在设计等方面也进行了相应的改造和优化。架构图如下：

最上面是小程序的访问客户端，中间是访问层，最底层是数据库存储层。当然还有外设管控、报警、备份、元数据管理等模块。

通过云开发提供的SDK，开发者可以在微信小程序、QQ小程序中一键获取云数据库的登录状态，然后向接入层发送数据读写请求。接入层收到用户的读写请求后，由keeper和agent这两个无状态模块来处理访问到的读写请求。其中，用户主要负责请求认证、认证缓存、读写请求数量统计等。是云数据库权限验证、负载均衡、计费功能的核心模块。代理模块主要有以下功能： 1）维护从访问层到底层数据库实例的连接池，通过复用已建立的连接，减少请求认证和连接建立所需的时间； 2）统计并发请求数，平滑读写请求的QPS，避免短期错误影响数据库性能和可用性； 3）热迁移过程中切换数据库实例时，暂停请求，切换后恢复请求，以实现热迁移过程对用户的影响。整个过程都是无意识的。

最后读写请求经过访问层到达存储层读写数据库实例。由于本文的重点主要是在数据库层面，因此我们尝试从四个方面进行描述。为避免本文篇幅过长，部分内容不会提供详细实现，仅进行简要分析。有兴趣的读者可以留言或与我们讨论。

4.1 访问控制

权限控制

首先，用户只能访问自己的数据库，不能访问其他用户的数据库。不同用户的数据库相互隔离，所有连接都必须经过身份验证。默认情况下，用户对数据库具有读写权限，也支持创建多个对数据库具有不同权限的账户（如只读账户）。在小程序云开发场景下，通过使用微信全链路免认证功能，用户无需过多担心认证相关问题。

连接数控制

其次，关于连接数控制，我们分两层进行控制： 1）客户端连接控制在接入层进行，初始化时根据实例类型进行不同的设置（免费/付费等）初始化限制，如果超过限制，则会提示对应的用户； 2）存储层的接入层也有相应的连接数控制，后端数据库中所有主从节点的链接都会被聚合，避免链接过多导致数据库错误。性能问题。

流量和QPS控制

最后还有出入流量控制和机器级资源使用限制。原理与连接数控制类似。所有用户请求都会经过接入层，因此可以在接入层管理QPS，实现后续的按量付费功能。当QPS超过阈值时，可以在接入层提示用户或对用户进行排队。

这里可能有人会问，云开发数据库不具备弹性扩展能力吗？为什么会有qps限制？难道不应该是我的qps越来越高，后端数据库资源也在不断的扩大吗？

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

4.2 数据安全

数据安全是数据库最重要的功能之一。毕竟，存在数据丢失风险的数据库无法在激烈的市场竞争中生存。那么云数据库如何保证数据安全呢？

数据冗余

为了解决不丢失数据的问题，首先要避免数据库出现单点问题，即要有数据冗余。一般来说，业界认为安全的备份数量是三个。因此，云数据库默认是分布式三副本存储，即一份数据三副本存储在不同的机器上，而且机器也必须分布在不同的机房。节点区分主模式和从模式。主节点可以接受读写请求，而从节点只能接受读请求。副本集的存储节点之间采用类似舰队的副本集协议，实现数据三副本的最终一致性。

高可用性

当一台机器出现故障时，副本集中的数据节点会自动切换（FailOver），从节点成为主节点并继续提供服务，最大限度地减少对业务的影响。

备份与回滚

云数据库备份对用户完全透明，后台根据数据库状态自动有选择地进行全量备份和增量备份。具体来说，用户输入的速度越快，后台备份就越频繁。这样做的目的是减少回滚时需要重放的数据，提高回滚性能。

支持7天内随时回滚。您可以选择仅回滚单个表，以进一步减少回滚所需的时间。

如果某个节点发生故障，需要在副本集中添加新节点，可以选择从备份文件中恢复，从而减少对源集群的入侵。

多可用区容灾

云数据库默认跨三个计算机空间（AZ，可用区）实现，对用户也是透明的。机房故障不影响服务；它还可以支持跨越多个机房。区域、三中心、两地点等多种模式。例如北京、上海、深圳各有一个节点，就近访问服务，减少业务访问云数据库的延迟。

此外，所有与数据库的连接都必须经过身份验证，所有数据都必须经过加密和压缩才能存储。这两点保证了数据链路安全和存储安全。

4.3 弹性伸缩

弹性伸缩

很多时候公司的接入模式会呈现出明显的周期性或者不均衡的特征。例如，外卖业务的高峰期出现在用餐时段，其他时段的访问量相对较大。博彩业务高峰期集中在晚上或周末，工作时间较少；部分电商高峰期出现在特殊时期（双十一、618等）。

如果按照传统的数据库运维模式，就得提前预估大小，然后运维扩容，活动结束后再缩容（否则成本就是问题）。那么在小程序的场景下，由于用户肯定对后端服务是无感知的，所以资源的扩张和收缩也不应该感受到。

基于这个起点，我们实现了云数据库的弹性伸缩。依托管控系统的负载监控模块，我们可以根据数据库的实时负载动态调整数据库资源，自动调整敏感度，有效应对数据库负载的突然增加。当负载较低时，还可以分配资源。将其发布给其他更需要它的机构。其次，为了避免单个大查询带来的频繁调整，我们设置了滑动窗口和“去毛刺”机制，以确保弹性伸缩尽可能顺利地进行。

数据库热迁移

当实例状态发生变化时（如免费-->付费、冷-->热），可能需要进行数据迁移，比如从性能较差的机器迁移到性能较差的机器具有更好的性能。通过与接入层的配合，我们实现了用户无感知的数据库热迁移，可以在不停止服务的情况下将用户数据从一个数据库无损迁移到另一个数据库。

总体来说，数据库直接迁移主要分为三个部分：

1. 数据同步（Data Synchronization）
2. 割接（Cutover）
3. 状态变更（Status Change） 高性能数据同步完全支持底层数据库。需要先同步整个数据，然后在全阶段同步新生成的操作记录（操作日志），然后不断循环这个过程，直到源数据库和目标数据库之间的距离很小。其实现与副本集中的主从同步非常相似。此阶段，源数据库可读可写。第二步，当两个数据库距离很小时，进行热迁移过程，源数据库变得不可读、不可写，访问层暂时保留用户的请求，不返回错误；数据同步是在双方，目标数据库完成所有操作记录并验证双方数据完全一致后，进行割接，包括用户的复制以及一系列元数据的更改。第三步，割接完成后，目标集群变得可用，之前被接入层阻塞的请求可以被释放并继续执行。由于切换过程非常快（秒级），因此这些请求不会返回超时等错误。当然，这里只考虑最一般的情况。当特定链路发生异常时，必须考虑相应的回滚和响应逻辑，这涉及到状态机的改变。这个比较复杂，这里不再赘述。

   我们认为数据热迁移要让用户完全察觉不到的最大难点在于：

   • 对集群变化的一致性感知能力强；
   • 高性能割接；
   • 割接模式持久化和超时控制；
   • 临时处理用户请求；

   在我们的架构中，底层数据库提供了高性能数据同步的基础能力；由于接入层代理的存在，可以方便地部署代理。用户之间有很强的连贯性，可以临时处理用户的请求（比如街区生活）；引入分布式KV存储系统etcd，实现割接模式的持久化和超时控制，如下图所示：

   经过线上环境测试，数据库梳理的QPS维持在约100%左右。 3k（100%写入），热迁移成功。从前端来看，迁移过程中用户请求的成功率保持在100%，意味着热迁移对用户完全透明。 。

   我们不妨举一个例子来说明数据库热迁移的应用。 微信阅读公司采用小程序云开发。微信阅读小程序的“每日问答”模块采用完整的云数据库作为底层支撑。 “问答PK”、“每日解答”以及不同类别的问题分别存储在不同的表中。顶级QPS（晚上0点左右）接近10k，上线以来业务运行平稳。有一段时间，我们发现共享资源池中某个用户的访问量有明显的上升趋势。弹性伸缩后，仍然不能完全满足其需求。为了避免对微信读书实例的影响，我们决定对整个数据库实例进行热迁移。方法将其移至我们的热资源池中。由于数据量不大（10G），几分钟（秒）就完成了数据迁移割接。整个过程对用户来说是完全透明的，当然也没有向微信透露。阅读例子有一定的影响。

   4.4 智能DBA

   智能DBA是一个非常大的话题，涉及到方方面面。从层次上看，主要包括以下三层：应用层、处理层和汇聚层。采购层负责从多个数据源收集必要的数据和指标；处理层对采集到的数据进行预处理和分析，并生成相应的决策和建议；应用层根据不同的应用场景进行不同的处理，比如自动化运维模块要处理异常，而巡检模块只需要进行巡检和报警。

   自动化运维

   为了进一步减少后端的运维操作，我们实现了自动化运维平台。通过运行时监控存储节点的状态，检测到各个节点并发生故障，然后根据故障的统计结果在决策中心进行相应的自动化运维操作（例如，如果磁盘是只读的，则master 将被迫切换）。还会提醒运维人员，确保自动运维结果正确。

   对于一些自动化运维无法覆盖的问题，我们有一套完整的各级各维度（机器、实例、节点等）的二级监控，总共**69+**不同指标。 element，后端可以实时感知数据库的状态；问题可以尽快得到解决。

   索引优化

   索引是数据库中非常重要的概念，用于加快数据库搜索速度。在小程序的背景下，我们希望将用户对后端数据库的了解减少到尽可能少。结果，实现了许多查询优化功能，例如自动索引构建。当我们的访问层和存储层检测到用户在后端有很多是全表扫描的查询时，它们会根据用户查询中的具体字段添加相应的索引。索引创建完成后，用户可以直接享受优化后的查询结果。 重要的是用户也不知道这个过程。

   我们认为，要让自动索引完全被用户感知不到，必须考虑以下主要问题：

   1. 同步VS。异步？索引过程应该是异步的，否则会阻塞用户的正常请求。
   2. 如何控制索引风险？主要分为两个方向：1）一是检查自动创建索引的频率。索引构建是一项CPU密集型任务，如果数据库一直在进行索引构建显然是不可接受的； 2）其次，要把自动建索引的数量控制在一个相对合理的范围内。一般的表不会有问题，但是如果数据库中的一个表包含多个字段，用户会根据这些字段进行不同的查询，无限制的索引会导致索引数量特别多，严重影响用户的更新效率（因为通过update，除了更新数据之外，对应的索引也会被更新）。
   3. 索引是如何动态更新的？用户查询不是静态的。随着业务的发展或变化，同一张表上的查询可能会发生变化。那么之前自动创建的索引也必须自动删除，否则从长远来看它们将成为数据库的负担和瓶颈。现有索引必须根据用户查询条件的变化动态更新。这里关于索引的最左边的匹配原则也值得考虑。
   4. 如何对用户透明？不仅不影响用户在建立索引时的正常请求，还应该让用户直接感受到查询索引的速度。当表中的数据量较大时，索引更改操作（例如组合索引的字段顺序更改）可能会导致用户同一查询的耗时差异较大。除了向用户解释之外，我们还可以考虑改变索引。改动更加灵活，并且给出了一些查询优化的建议。这有助于用户更好地使用数据库。

   自动建索引功能上线后，数据库实例的平均请求时间大幅下降，整个小应用云开发数据库的平均耗时也降低了**50%**以上，如下图所示。

   确实，自动建立索引有一定的局限性，比如使用不等式、正则匹配等复杂查询方法时。此时就需要其他方法来处理，比如前台询问用户如何优化查询短语；或者使用云数据库的慢日志分析工具来分析慢日志并提供有针对性的解决方案。

   五、总结与展望

   小程序云开发可以极大释放小程序开发者的生产力，降低开发成本和难度。其中，云数据库起着至关重要的作用。针对小型应用云开发对云数据库提出的五大需求：安全、易用、低成本、高性能、灵活性，我们在数据库架构设计方面做了很多改进和优化这使得云数据库更适合小型应用的使用场景。

   未来我们还将在云数据库管控层提供更细粒度的监控（当然用户不需要意识到）、更智能的DBA、更高效的弹性伸缩能力（比如基于在k8的云数据库上）；在云数据库的核心层，我们会封装一些底层的存储引擎能力并暴露给API层，并深度结合Widget的使用场景进行定制开发（例如研究表明很多Widget是为了回答相关问题，

   我们有理由相信云开发数据库会在Serverless理念的指导下不断完善自己，与小伙伴一起发展得越来越好节目。 Lej参考文献Bmob

作者：phoenixliu，腾讯TEG后端开发工程师