导言
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 指令，判断是否在对应的人群中。
特点：
- 去除网关，缩小链路长度
- 设置缓存，离线零碎和在线零碎解耦，晋升性能
- 数据压缩，缩小内存占用
- 零碎 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 从以下两个维度来管制资源交付速度：
- 突增实例数：可立刻创立的实例数（默认 300）；
- 实例增长速度：超过突增实例数后每分钟可减少的实例数（默认每分钟 300）。以上参数为可调整。
下图展现了在一个调用量快速增长的场景下函数计算 FC 的流控行为：
多机房部署
零碎采纳三单元部署，保障内部媒体都能够就近拜访，升高网络时延。
业务成果
零碎架构降级后，节俭了几千核的机器资源，实现了全面 Serverless 化，调用链路变短了，零碎变得更加弹性、强壮和易于保护，获得了很好的业务成果。
瞻望
在过来的 2022 年，高德在 Serverless 畛域中曾经获得了长足的停顿，然而这不是起点，而只是刚刚开始，后续阿里云函数计算 FC 会和高德一起推动利用的全面 Serverless 化，冀望帮忙高德在更多的场景去应用 Serverless，吃透 Serverless 给带来的技术红利！
作者 : 赵庆杰（阿里云函数计算）、林雪清（阿里云函数计算）、杜玲玲（高德）、王壁成（高德）
原文链接
本文为阿里云原创内容，未经容许不得转载。