经验分享：高德地图如何短时间快速完成春节出行备战工作？-阿里云开发者社区

作者 : 赵庆杰（阿里云函数计算）、林雪清（阿里云函数计算）、杜玲玲（高德）、王壁成（高德）

导言

2023 年春节，经历了三年的疫情后，我们终于在春天迎来了曙光。国人的出行热情空前高涨：回家看看父母亲；心心念念的旅行终于可以成行了。按照高德的估计，2023 年春节出行的峰值流量将比 2022 年同期和 2022 年十一都有相当大比例的增长。然而，就在不久前，受疫情的影响，系统的流量还在相对低位运行。

如何在短时间内快速完成春节出行的备战准备工作，保障系统在春节流量高峰下平稳运行，让民众出行所必需的导航等信息服务访问可以丝般顺滑，成为了摆在技术人员眼前的迫切事情。要在流量变化很大的情况下保障系统平稳运行，同时做到降本增效，怎么做到呢？

过去几年，高德一直在坚定、持续地推进应用的 Serverless 化。经过深入的研究和选型，最终选择阿里云函数计算 FC 作为其应用的 Serverless 计算平台。过去的一年，更是取得了长足的进展。

高德在 Serverless 上的远见帮助他们以更加敏捷、经济的方式应对不确定性以及强劲复苏的春节出行：不用费心考虑流量变化带来的资源变化，无需提前按照峰值流量准备大量的计算资源，不用担心资源是否足够，经济成本大幅下降、研发和运维效率明显提升。

基于之前的 Serverless 成果，高德相关业务快速完成了春节出行备战准备工作，春节保障顺畅完成。

我们一起来看一个典型的案例：在 2022 年阿里云函数计算 FC 是如何助力高德 RTA 广告投放系统实现架构升级的。

业务背景

什么是 RTA

RTA 是一种实时的广告程序接口，通过发挥媒体与广告主双方的数据、模型能力，实现实时的广告优选；RTA 是一种接口技术，更是一种策略导向的投放能力。

广告媒体通过高德的 RTA 接口，来询问是否要投广告，RTA 的服务通过查询高德自己的人群信息，返回投放结果。这样媒体投放广告可以更精准。

原系统的架构&问题

原系统服务器占用较多，依赖链路较长，每次扩容，依赖服务也需相应扩容，造成资源占用较多。

技术选型

人群命中功能

人群命中功能，本质可以归结为检索某个元素是否在一个集合中的问题。

这类问题，业界常用 bloom filter 进行解决。bloom filter 的本质是一组 hash 算法和 bitmap 的组合。优点是查询效率高，占用空间小。Redis 扩展版提供了 bf(bloom filter)功能。由于读取是用 golang，写入是用 Java 的写入，为了避免跨语言带来的库不一致，可能存在的 bloom filter 不同实现导致的命中不一致的问题，可以采用 Redis 扩展版的 bf(bloom filter)功能，在 Redis 服务端实现 bf 功能，保证不同语言调用的数据一致性。

借助 Redis 来实现人群命中功能，就可以去掉算法网关，数据中台侧的很多资源也可以因此节省下来。

数据同步

目前圈人平台的数据更新有 4 种类型：在线、实时、离线单次、离线周期。

目前的圈人策略都是基于离线人群进行圈定。后续虽然有可能使用在线和实时的情况，不过由于 RTA 广告圈定的人群一般较大，实时人群的变化的比例较低，且媒体端均有缓存，实时性要求不高。使用实时，在线人群和离线人群的效果区别不大，所以目前建议只使用离线人群作为主要圈人手段，如果对实时性要求较高，可以考虑离线周期为小时维度的更新(本质上实时性取决于 UDF 更新频率和触发方式)。综合考虑离线周期更新 Redis 的方式。

Serverless 化

为什么要 Serverless 化

通过重新划分应用和平台的界面，Serverless 使得业务可以专注自身业务逻辑，人人都可以快速开发出一个稳定、安全、弹性、可扩展的分布式应用成为可能。

如何实现 Serverless 化

新的技术选型里，引擎服务需要访问 Redis。这是一个有着高频存储访问的系统如何 Serverless 化的问题。

一般认为 Serverless 就是 FaaS+BaaS。FaaS：Function as a Service，函数即服务，一般是各种后端微服务。BaaS：Backend as a Service，就是不适合以 FaaS 形态存在的后端服务，比如存储服务。

Serverless 化的系统架构对云存储提出很高的要求，在可扩展性、延迟和 IOPS 方面，云存储需要能够实现与应用同等/接近的自动扩缩容能力。

阿里云提供 Redis 企业版服务，集群架构版本提供多种实例规格，支持最高 2G 总带宽，6000 万的 QPS。支持调整实例的架构、规格等，以满足不同的性能和容量需求。可实现无感扩缩容。可以满足引擎服务 Serverless 化之后对存储的要求。

而 FaaS 是目前后端微服务 Serverless 化最常见的技术选型。阿里云函数计算 FC 是 Forrester 测评认定的全球领先的函数计算产品，在公有云和集团内都积累了丰富的应用 Serverless 化经验，是合适的选择。

高性能要求

RTA 广告投放系统作为为外部媒体提供相关服务的系统，具有大流量，延迟要求高的特点，是典型的高性能要求场景。这样的场景里，客户端设置的超时时间一般都很短，一旦超时，接口调用就会失败。采用 Serverless 的架构之后，请求的流量会先打入阿里云函数计算 FC 的系统，然后转发到函数实例进行处理。在这个场景里，要求函数计算 FC 的多租户、大流量的情况下，将请求处理的系统耗时（不包括函数自身执行时间）的平均值、P99 值控制在很低的水平，才能保证请求成功率 SLA 的要求。

落地方案

系统架构

新架构里，中台生成人群后，调用 Redis 的 BF.INSERT 等指令，生成 bf。引擎侧拿到设备 ID 后，通过 Redis 的 BF.EXISTS 指令，判断是否在对应的人群中。

特点：

1. 去除网关，减少链路长度
2. 设置缓存，离线系统和在线系统解耦，提升性能
3. 数据压缩，减少内存占用
4. 系统 Serverless 化，实现实时弹性和免运维，加快应用迭代速度

请求调度

前面我们提到高德 RTA 广告投放系统具有流量大，延迟要求高的特点，是典型的高性能要求场景。而阿里云函数计算 FC 是一个典型的多租系统，一个集群内不单单有高德 RTA 广告投放函数，还有非常多其它业务的函数。对函数计算 FC 的请求调度提出非常高要求：

单函数 QPS 无上限，大量长尾函数不消耗资源
调度服务要保证高可用，单点故障对服务无影响
请求处理所需的系统耗时要控制在平均值小于 2ms，P99 值小于 10ms

我们来看看函数计算 FC 是怎么做到的。

为了实现实时弹性，当函数的请求到达函数计算 FC 的前端机之后，前端机会找调度节点（Partitionworker）要一个处理请求的实例，并将请求转发给它。调度节点接收到请求之后，如果有实例可用，则根据负载均衡策略获取一个实例并返回给前端机；如果没有，则实时创建一个，并返回给前端机。实例的创建时间可以达到百毫秒级别。

为了保证高可用和横向可扩展，调度节点采用分区架构
同一个用户/函数的请求映射在连续的分片区域内
单函数请求可跨越多个分片，横向扩展
调度节点（Partitionworker）通过心跳向分片管理器（Partitionmaster）汇报分片和节点状态
Partition master 通过移动/分裂/合并分片进行负载均衡
调度 100 万函数，单函数最大峰值 20 万 TPS，调度延时小于 1ms
任何节点故障，请求会被路由到其他 Partitionworker 上，对可用性无影响

我们看到一个请求需要通过前端机和调度节点的处理之后，才转发给具体的函数实例。因此请求处理的系统耗时包括前端机的处理时间、调度节点的处理时间、前端机和调度节点的通信时间以及前端机和函数实例的通信时间，过去一年，我们对函数计算 FC 的前端机、调度系统针对性的做了很多的优化，保证了系统在超大流量的情况下，请求处理的请求处理所需的系统耗时要控制在平均值小于 2ms，P99 值小于 10ms。

资源交付

Serverless 的场景下，业务不再需要关心资源的管理了，平台负责资源的管理和调度。业务流量上涨了，平台需要有能力快速刚性交付业务需要的计算资源；而当流量下降之后，平台需要将空闲的资源自动释放掉。

为了保证包括高德 RTA 广告投放函数在内的函数的资源刚性交付，阿里云函数计算 FC 持续优化了资源管理的实现。

Serverless 新底座：神龙裸金属+安全容器

一开始，阿里云函数计算 FC 采用 Docker 容器的形式来交付函数计算实例。因为 Docker 存在容器逃逸存等这样的安全问题，为了保证安全性，一台宿主机只会部署一个租户的函数。由于函数计算 FC 存在大量的长尾函数，函数实例的规格也往往比较小，比如只有 128M/0.1 核，这限制了资源利用率的提升。

为了解决这个问题，阿里云函数计算 FC 和相关团队合作，将资源底座全面升级到神龙裸金属+安全容器，借助神龙裸金属软硬一体化技术带来的虚拟化效率提升和安全容器安全性保障后实现的多租户高密混部，大幅提升了资源的利用率。

独立的资源管控

由于 K8s 集群的 Pod 产出效率很难满足 Serverless 每分钟几万个实例的创建需求，所以函数计算 FC 与相关团队合作，实现了 Pod 内的计算资源的进一步细分，由函数计算 FC 直接对 Pod 里面的容器进行管控，从而实现了高密部署，以及高频创建的能力。

毫秒级资源交付速度

相比较 K8s 分钟级以上的资源交付速度要求，Serverless 的场景需要将资源的交付速度提升到秒级、毫秒级。为了解决 K8s 基础设施启动耗时和函数计算 FC 对极致弹性强烈诉求之间的矛盾，阿里云函数计算 FC 实现了 Pod 资源池化、镜像加速、镜像预热、计算实例 Recycle 等等技术，保证了极速的资源交付速度。

高可用

为了实现高可用，阿里云函数计算 FC 的资源在每个 region 不止分布在一个K8s集群，而是多个 K8s 集群，做到了任何一个 K8s 集群出现问题，会自动地切换到正常集群的能力。每个集群都有多种资源池类型：独占资源池、混跑资源池和可抢占资源池。函数计算 FC 根据业务的特点，进行统一调度，从而把成本进一步的降低。

交付SLA

在资源的交付总量方面，目前阿里云函数计算 FC 已经有了单函数交付几万个实例的案例，由于函数计算 FC 有资源池池化动态补充的能力，理论上，函数计算 FC 单函数可以交付的实例数远不止几万个实例。在资源的交付速度方面，函数计算 FC 可以做到百毫秒级别的实例创建速度。遇到 burst 的情况，函数计算 FC 从以下两个维度来控制资源交付速度：

1. 突增实例数：可立即创建的实例数（默认 300）；
2. 实例增长速度：超过突增实例数后每分钟可增加的实例数（默认每分钟 300）。
以上参数为可调整。

下图展示了在一个调用量快速增长的场景下函数计算 FC 的流控行为：