作者 : 赵庆杰（阿里云函数核算）、林雪清（阿里云函数核算）、杜玲玲（高德）、王壁成（高德）
导语
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 给带来的技能红利 ！
新书引荐
点击此处，下载 Serverless 电子书
