赵庆杰（阿里云函数计算）、林雪清（阿里云函数计算）、杜玲玲（高德）、王壁成（高德）
导言
经历了三年的疫情后，国人的出行热情空前高涨：回家看看父母亲；心心念念的旅行终于可以成行了。按照高德的估计，2023年春节出行的峰值流量将比2022年同期和2022年十一都有相当大比例的增长。然而，就在不久前，受疫情的影响，系统的流量还在相对低位运行。
如何在短时间内快速完成春节出行的备战准备工作，保障系统在春节流量高峰下平稳运行，让民众出行所必需的导航等信息服务访问可以丝般顺滑，成为了摆在技术人员眼前的迫切事情。要在流量变化很大的情况下保障系统平稳运行，同时做到降本增效，怎么做到呢？
过去几年，高德一直在坚定、持续地推进应用的Serverless化。经过深入的研究和选型，最终选择阿里云函数计算（Aliyun FC）作为其应用的的Serverless计算平台。过去的一年，更是取得了长足的进展。
高德在Serverless上的远见帮助他们以更加敏捷、经济的方式应对不确定性以及强劲复苏的春节出行：不用费心考虑流量变化带来的资源变化，无需提前按照峰值流量准备大量的计算资源，不用担心资源是否足够，经济成本大幅下降、研发和运维效率明显提升。
基于之前的Serverless成果，高德相关业务快速完成了春节出行备战准备工作，春节保障顺畅完成。
我们一起来看一个典型的案例：在去年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化最常见的技术选型。阿里云函数计算是Forrester测评认定的全球领先的函数计算产品，在公有云和集团内都积累了丰富的应用Serverless化经验，是合适的选择。
高性能要求
RTA广告投放系统作为为外部媒体提供相关服务的系统，具有大流量，延迟要求高的特点，是典型的高性能要求场景。这样的场景里，客户端设置的超时时间一般都很短，一旦超时，接口调用就会失败。采用Serverless的架构之后，请求的流量会先打入FC的系统，然后转发到函数实例进行处理。在这个场景里，要求FC的多租户、大流量的情况下，将请求处理的系统耗时（不包括函数自身执行时间）的平均值、P99值控制在很低的水平，才能保证请求成功率SLA的要求。
落地方案
系统架构
新架构里，中台生成人群后，调用Redis的BF.INSERT 等指令，生成bf。 引擎侧拿到设备ID后，通过Redis的BF.EXISTS 指令，判断是否在对应的人群中。
特点：
- 去除网关，减少链路长度
- 设置缓存，离线系统和在线系统解耦，提升性能
- 数据压缩，减少内存占用
- 系统Serverless化，实现实时弹性和免运维，加快应用迭代速度
请求调度
前面我们提到高德RTA广告投放系统具有流量大，延迟要求高的特点，是典型的高性能要求场景。而FC是一个典型的多租系统，一个集群内不单单有高德RTA广告投放函数，还有非常多其它业务的函数。对FC的请求调度提出非常高要求：
- 单函数QPS无上限，大量长尾函数不消耗资源
- 调度服务要保证高可用，单点故障对服务无影响
- 请求处理所需的系统耗时要控制在平均值小于2ms，P99值小于10ms
我们来看看FC是怎么做到的。
为了实现实时弹性，当函数的请求到达函数计算的前端机之后，前端机会找调度节点（Partitionworker）要一个处理请求的实例，并将请求转发给它。调度节点接收到请求之后，如果有实例可用，则根据负载均衡策略获取一个实例并返回给前端机；如果没有，则实时创建一个，并返回给前端机。实例的创建时间可以达到百毫秒级别。
- 为了保证高可用和横向可扩展，调度节点采用分区架构
- 同一个用户/函数的请求映射在连续的分片区域内
- 单函数请求可跨越多个分片，横向扩展
- 调度节点（Partitionworker）通过心跳向分片管理器（Partitionmaster）汇报分片和节点状态
- Partition master 通过移动/分裂/合并分片进行负载均衡
- 调度 100 万函数，单函数最大峰值 20 万TPS，调度延时小于 1ms
- 任何节点故障，请求会被路由到其他 Partitionworker 上，对可用性无影响
我们看到一个请求需要通过前端机和调度节点的处理之后，才转发给具体的函数实例。因此请求处理的系统耗时包括前端机的处理时间、调度节点的处理时间、前端机和调度节点的通信时间以及前端机和函数实例的通信时间，过去一年，我们对函数计算的前端机、调度系统针对性的做了很多的优化，保证了系统在超大流量的情况下，请求处理的请求处理所需的系统耗时要控制在平均值小于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实现了Pod资源池化、镜像加速、镜像预热、计算实例Recycle等等技术，保证了极速的资源交付速度。
高可用
为了实现高可用，FC的资源在每个region不止分布在一个 K8s 集群，而是多个 K8s 集群，做到了任何一个 K8s 集群出现问题，会自动地切换到正常集群的能力。每个集群都有多种资源池类型：独占资源池、混跑资源池和可抢占资源池。FC根据业务的特点，进行统一调度，从而把成本进一步的降低。
交付SLA
在资源的交付总量方面，目前FC已经有了单函数交付几万个实例的案例，由于FC有资源池池化动态补充的能力，理论上，FC单函数可以交付的实例数远不止几万个实例。在资源的交付速度方面，FC可以做到百毫秒级别的实例创建速度。遇到burst的情况，FC从以下两个维度来控制资源交付速度：
- 突增实例数：可立即创建的实例数（默认300）；
- 实例增长速度：超过突增实例数后每分钟可增加的实例数（默认每分钟300）。
以上参数为可调整。
下图展示了在一个调用量快速增长的场景下FC的流控行为：
多机房部署
系统采用三单元部署，保证外部媒体都可以就近访问，降低网络时延。
业务效果
系统架构升级后，节省了几千核的机器资源，实现了全面Serverless化，调用链路变短了，系统变得更加弹性、健壮和易于维护，取得了很好的业务效果。
展望
在过去的2022年，高德在 Serverless 领域中已经取得了长足的进展， 然而这不是终点，而只是刚刚开始，后续FC会和高德一起推进应用的全面 Serverless 化，期望帮助高德在更多的场景去使用 Serverless，吃透 Serverless 给带来的技术红利 ！
