小程序如何抵抗流量洪峰？解析云开发高可用架构设计

小程序一直在为人们的日常生活提供便利，随着用户量的增加，其本身对高并发的需求日益强烈。以“微信读书”小程序来说，它上线10个月，即获客数千万，日均PV过千万、请求量数以亿计。

不止“微信读书”，“猫眼电影”、“云南抗疫”等小程序之所以能够轻松应对高并发请求，离不开其背后腾讯云云开发服务的支持。 本文即将从架构设计等层面，为大家详细解析腾讯云云开发技术。

高并发对于任何形式的服务来说，都是一个不小的技术挑战。

1

传统开发模式

在传统模式下， 一 方面，研发人员被要求具有业务预见性，对业务峰值能够做出相对准确的预估（过高会造成资源浪费，过低则影响业务效果）。另一方面，研发人员需要对业务架构进行合理设计，提前部署大量资源，并且进行大量压测以确保可靠性。 不仅如此，系统上线后还需要众多运维人力投入。总而言之，传统开发模式下要应对高并发问题，会耗费很多的人力物力。

2

云开发模式

在云开发模式下，解决高并发问题就相对确简单了很多。 云开发作为一个 支持多端开发的云+端一体化解决方案，采用足够轻量和弹性的serverless架构，可以无限自动水平扩容，按需使用资源的模式，使得开发者不需要为了应对高并发而提前部署大量资源，大大节约了资源成本。并且，云开发是典型的 NoOps 实践，后期系统无需运维。 

当前，云开发日均调用超过七亿次，云开发的压力测试表现也十分优异：在 20000 并发连接 200ms 云函数执行时间的情况下，云开发服务可支持 8W QPS 的服务能力，250ms 左右的平均响应时间。 

此外，通过云开发各类端侧SDK就可以轻松实现多端开发 （包括微信小程序、WEB端、移动应用等），开发者仅需专注于开发者自身的业务实现，而无需关心传统C/S架构中的服务端基础架构，业务可以快速开发上线，极大地提高开发效率，降低研发成本。

云开发是如何保证高可用的？了解这个问题之前，先看一下云开发的整体架构：

从图中可以看到，用户的一次服务调用需经过多个中间层服务，最终到的用户资源层。因此， 云开发服务的高可用高性能从大的层面上可分为 “数据链路” 和 “底层资源” 两个方面。 目前，云开发系统 “数据链路” 和 “底层资源” 均超过 99.99% 以上的可用性。

1

数据链路

应用从端侧SDK开始访问云资源（云函数、数据库、文件存储）需经过的一系列服务模块最终到的资源层，这一调用链路对开发者来说是透明无感知的，通常称为 “数据链路” 或 “数据管道”。

数据链路为用户提供端侧和云资源侧的连通能力，数据链路也并不仅仅进行数据转发和传输，还包括一系列的处理逻辑，如微信登录鉴权、票据生成与校验、数据编解码、云账户身份鉴权、集群路由、云资源信息绑定、安全规则、数据签名与校验、上下文环境信息注入、访问记数、并发控制等多方面的支持用户能力的逻辑模块。

云开发服务各层服务模块均按多集群进行部署，集群内各层及各服务模块也均进行了跨多机房的冗余部署，提供充分的冗余，并且自动发现和剔除故障主机，保证在服务故障时能够进行快速切换，保证云开发服务的高可用性。

另外数据管道在资源部署上也提供了充足的容量支持，并备有一定量的Buffer，当有用容量需求时，可进行快速扩容。部分模块也开始尝试容器化部署，能够更快速弹性扩容。 

在性能和高可用方面腾讯云云开发也做了很多的设计优化 ，以下为部分设计实现要点：

(1)尽可能简单，不引入不必要的依赖，尽可能减少依赖；
(2)无状态设计，各个模块均无状态的，便于在系统请求量上升时快速进行横向扩容；
(3)可降级设计，链路中各个模块均进行可降级设计，在单个模块出现问题时，可自动或手动降级到备用方案，并且有兜底方案；
(4)多级缓存设计，在系统内部存在多级别的缓存设计，提升系统性能；

(5)自动故障转移，链路上下游主机可以自动发现和剔除故障主机，快速恢复服务；
(6)多集群部署，链路中各个模块均进行了跨机房的多集群部署，在故障是能够进行切换；
(7)重试策略，针对系统中可重试的场景设计重试机制，保证成功率；
(8)采用更性能的实现方式，减少耗时；
(9)快慢请求分离，快请求同步慢请求异步的方式提高性能。

2

底层资源

底层资源的高可用是云开发服务高可用的关键一环，这一部分将对 “云函数 ”和 “云数据库” 进行分别介绍。

云函数优化

云函数在高可用性方面进行了充分的架构考量，在部署上做了充分的冗余，下图为云函数高可的部署架构。

从图中可以看到， 云函数从接入层到资源层，各层均进行了多集群的部署，每个集群都按跨机房的方式部署。集群内单机或单机房故障系统能够自动发现并且快速剔除，这种部署方式可以应对单机故障、机房网络故障等设施类故障。集群故障也能够快速的切换用户集群来快速恢复服务，缩短故障时间，保证高可用性。另外这种部署上的设计，也便于进行更大范围的横向扩容，提供更大的系统并发容量，以满足客户不断上涨的业务需求。  同时，在发布策略上，按集群进行逐步的灰度，如果出现系统Bug，能够只影响少量请求。 

在云函数资源底层，面多高并发请求，首先就需要有充足的能够承担高并发的计算资源，云开发的云函数底层建立了规模非常大的资源池，同时也预留的大量的Buffer资源，云函数系统从资源池分配资源给函数实例，在资源池消耗到一定程度时，系统可以自动化申请云上VM资源，快速扩容资源池，实现多层次的水平弹性伸缩，以应对开发者可能的海量业务需求。

目前，云函数已经完成了新一轮的系统架构升级，以更高的可用性和性能，应对未来更大并发的调整。   云函数在执行性能方面，也做了非常多的优化。熟悉云开发的开发者应该了解，函数在一次调用中会涉及到函数的启动，启动又可以分为冷启动和热启动，热启动是非常快速的，而冷启动则相对较慢。

冷启动的过程如图所示，对比可以看出，冷启动需要创建函数实例，创建过程又包含多个子任务，如下载函数代码、部署函数等，通常需要几百毫秒的耗时。 

启动耗时对于云函数性能来说是非常关键的，所 以云函数性能的优化重点之一就在于减少冷启动率和冷启动耗时。云函数在 启动耗时方面也做了诸多优化：

(1) 优化代码下载耗时，在虚拟机内核可用区内建立多级缓存，提升下载云函数代码包下载速度；

(2)优化函数网络部署策略，降低部署耗时；
(3)优化容器启动，降低启动时间；
(4)基于用户请求量变化趋势和周期性的请求量变化规律，对云函数并发量进行准实时预测，提前进行扩缩容量；
(5)支持版本别名，用户更新代码， 以Rolling Update方式进行新旧版本替换，保证热启动率；
(6)优化函数实例预留时间，保证整体的低冷启动率。

云函数底层也采用了腾讯云自研的轻量级虚拟化技术，MicroVM启动时间缩短至90毫秒，函数冷启动减低至200毫秒，并且支持上万台计算节点同时扩容； 

目前，经过函数底架构上和性能上的不断优化，部署云函数实例的各阶段耗时也在不断减少，进而云函数的冷启动时间不断降低。为客户提供更高的可用性和性能支持。 

云开发目前为开发者提供单个云函数 1000 并发的能力支持 ，假设云函数的执行时间为 100ms，单个云函数可以达到 10000 QPS，这已经可以满足大部分用户场景的需求了，50个云函数的总QPS将可以达到 50W QPS。

云数据库优化

云数据库在接入层和数据库底层也做了非常多的专项优化，同时也在部署方面进行了诸多方面的设计。云数据库的部署架构如图所示。

从架构图中可以看到， 云数据库接入层进行了分层设计并支持水平横向扩容，所有用户请求会被分配到不同的主机上，每个主机都独立的维护用户数据库连接，这种方式保证了数据库接入层能够大规模进行水平扩展。

另外，在部署上也进行了多集群的策略部署，集群内部能够自动发现故障主机并剔除。不同用户分配到不同的接入集群，用户请求可在多集群上进行灵活调度，以应对可能出现的服务故障，提供更高的可用性和更短的恢复时间。 数据库引擎实例也均进行了跨主机的多数据库实例的部署，在单数据库实例故障时能够进行自动化的转移。 发布时 按集群进行进行灰度，影响范围小， 在发布策略上也能做到更加可靠 。

数据库为每个数据实例进行每日的全量备份和准实时的增量备份， 数据底层也将支持在线热迁移。在出现主机负载过较高时，自动在线热迁移用户实例到负载低的主机，此过程用户几乎是无感知的。热迁移同时也能够支持全局的数据库主机间的负载均衡。 

数据库目前也已经提供自动加索引能力，自动化的分析用户慢查询请求并针对性的进行自动索引优化，能够在用户无感知的情况下优化用户查询性能，使开发者可以更少的关心数据库性能优化就可以有优良的性能体验，更加专注于自身的业务逻辑。 

云开发服务各层均配有大量监控告警， 可以第一时间发现线上异常并紧急介入处理，保证出现故障时能够尽快恢复服务。同时针对每次的故障进行总结改进，逐步降低故障率。  

虽然云开发为开发者提供便利的云服务能力，同时也期望能够尽可能的解决开发者在使用过程中遇到的所有问题，但显然，这是一个永无止境的长期追求。 

其实开发者在这方面也可以有很大的想象和发挥空间。开发者在面对高并发需求时，可以通过云开发做哪些优化呢？

1

预测并发量上涨模型

通常高并发业务按并发量上涨模型来划分，可以分为以下两种形式：

(1) 业务量相对平缓上涨，并发量逐步上升，上升速度平缓，系统有充足的预热时间； 

(2) 业务并发量爆发上涨，并发量瞬间上升，上升速度很快，例如常见的秒杀类业务。 

对于第一种并发量以较均匀的速度上涨的业务，直接使用云开发就可以轻松应对。 

对于第二种呈爆发式上涨的业务，通过一定的策略和技术上的优化，也能较轻松应对。

2

多维度应对瞬时高并发

云函数在应对高并发请求的难点在于弹性，弹性支持了服务资源的按需部署，因此可以为开发者节省了大量资源花费。但也是因为弹性，在面对瞬时高并发需求时，服务瞬间面对比上之前大几十倍甚至上百倍的并发请求，云函数伸缩系统难以预料这种爆发性上涨。 

因为冷启动耗时相对较长，弹性扩容机制难以在秒级时间内实现大量云函数实例部署，无法跟上并发上涨的速度，热启动率降低，启动时间变长，进而导致部分请求超时，甚至出现超并发的情况，进而导致活动参与者因参与失败而放弃，活动效果达不到预期。如何解决这个问题呢？

策略上的优化方案

(1) 提前评估活动并发量及QPS等指标；

(2)充分进行活动预热，在活动越热阶段统计和再评估参与人数及并发量；
(3)在活动预热页面通过埋点代码的方式对业务云函数进行预热，通过参数控制不执行业务逻辑即可，也可以通过其他方式或多种方式进行预热；
(3)在评估并发量之后也别忘记评估套餐是否能满足业务需求，云开发提供按量计费和包年包月两种计费模式，业务方可以根据实际情况调整套餐，或者切换为按量计费，避免因套餐限制影响业务。

技术上的优化方案

技术上的优化核心就一点： 降低耗时

云函数方面 建议如下：

(1) 减少调用依赖服务的次数，如进行请求合并；

(2)降低依赖服务的响应时间，如数据查询耗时，其他接口调用耗时等；
(3)并发调用依赖服务；
(4)根据业务逻辑合并多个函数到单个函数、或拆分单云函数到多个云函数；
(5)精简代码、减少依赖、降低函数体积，缩短冷启动时间。

尽管云开发已经针对数据库查询进行了自动化的索引优化，但是系统对于用户业务逻辑和数据的设计是远远不能及业务方的，所以业务方研发团队可以在查询性能等多方面进行优化。

数据库方面建议如下：

(1) 通过创建高效索引，提升数据库查询效率；

(2)通过优化设计，减少数据库查询；
(3)采用高效的查询条件；
(4)减少返回数据的条数以及字段数，降低数据库的查询时间以及网络数据传输时间；
(5)减少事务的使用，尽量用替代方式；
(6)聚合类需求如排行榜等，可保存中间结果到数据库或缓存，避免每次进行统计计算；
(7)数据量较大，可对集合水平拆分，降低单集合数据量，提升查询效率。

小程序已经如今日常生活必不可少的工具，从猫眼电影小程序的大促活动，到微信读书“每日一答”、”组队读书”等日常运营活动，甚至包括如新华社新媒体中心的“我为祖国点赞”等，而腾讯云云开发者通过对自身架构在数据链路以及底层资源层面的设计，强化了用户在海量小程序应用过程中的高并发高性能，后续腾讯云云开发团队将进一步打磨技术，为用户提供更加极致的使用体验。

-END-