导读：曾经被认为“前景很美”、长期处于观望阶段的 Serverless，如今已经逐步进入大规模落地阶段。在今年的“十一出行节”中，高德在核心业务中实现了 Serverless 的规模化应用，并在流量高峰期展现出极为出色的稳定性与性能表现。既然传统应用同样可以提供类似体验，那么 Serverless 的差异化价值究竟体现在哪里？本文将围绕高德 Serverless 规模化落地的真实实践，分享背后的经验与总结。

随着 Serverless 概念持续普及，越来越多开发者正从“了解与观望”走向“实践与应用”，更多真实业务场景也在不断被打开。“Serverless 只适合小型场景吗？”、“是否只能依赖事件驱动？” 这些对 Serverless 技术的早期疑问，正在被越来越多的落地案例所打破。如今，用户已经开始在更多核心业务场景中采用 Serverless 架构，以实现研发提效、弹性扩容与成本优化等目标。作为国内领先的地图与出行平台，高德始终在积极探索前沿技术，并已在核心业务中规模化落地 Serverless，取得了显著成果。

2020 年“十一出行节”期间，高德地图再次刷新纪录——截至 2020 年 10 月 1 日 13 时 27 分 27 秒，高德地图当日活跃用户突破 1 亿，较 2019 年 10 月 1 日提前 3 时 41 分达成这一里程碑。

在此期间，Serverless 作为关键技术场景之一，平稳承接了流量洪峰的挑战。值得关注的是，由 Serverless 支撑的业务在高峰时段表现尤为突出，每分钟函数调用量接近 200 万次。这进一步验证了 Serverless 基础技术的实际价值，也说明其应用边界正在持续扩大。

自主出行是高德地图的核心业务之一，覆盖用户出行过程中的多类功能需求，同时承载着高德地图 APP 内最大的用户流量。下图展示了自主出行核心业务中接入 Node FaaS 的部分典型场景，从左至右依次为：主图场景页、路线规划页、导航结束页。

随着业务能力不断丰富，高德地图已经从单一导航工具升级为集出行服务与生活信息服务于一体的综合型平台，极大拓展了与出行相关的生活服务场景，为用户提供了更全面、更高效、更便捷的使用体验。如上图所示的功能为场景推荐卡片，其核心目标是基于用户出行意图，智能推荐相关内容，从而有效提升出行服务体验。而要达成这一目标，系统必须具备快速迭代能力以及样式灵活调整能力。那么，如何更好地满足这一需求？将卡片样式模板统一存放在云端，并通过服务下发后在客户端渲染，无疑是一种更优解。借助这一方式，业务便能够实现高频、灵活的迭代更新，持续为用户提供更优质、更个性化的服务体验。

经过方案评估后，高德判断该场景属于无状态服务。基于阿里云 Serverless 成熟完善的生态体系，高德最终选择接入 Node FaaS（阿里云函数计算）能力，并在出行前端侧搭建了场景推荐卡片服务。卡片的UI 模板获取、数据请求聚合&逻辑处理、拼接生成 Schema等能力，均由 FaaS 层完成，客户端则根据服务端下发的 Schema 直接进行渲染展示，从而实现更加轻量、灵活、高效的目标。

那么，Serverless 在“十一出行节”流量峰值场景下的实际表现究竟如何？

整体服务成功率均高于 99.99%，总计触发量达到 100W+ 次/分钟，QPS 超过 2W+，各场景服务平均响应时间均低于 60ms，整体稳定性与性能表现均超出预期。

从以上业务场景的支撑效果可以看出，Serverless 的实际表现非常亮眼。当然，也会有人提出疑问：传统应用同样能够实现类似体验，那么 Serverless 架构的核心差异化价值到底是什么？

1. 简单提效

传统 BFF（Back-end For Front-end）层应用，往往会随着时间推移和业务需求不断叠加而逐渐“变重”。BFF 层承担的职责越来越多，冗余代码持续增加，最终容易演变为开发者口中的噩梦——“牵一发而动全身”。随着团队成员更替，模块负责人不断变化，BFF 层也会慢慢成为一个“没人完全了解、也没人轻易敢改”的复杂模块。

当 BFF 层演进为 SFF（Serverless For Front-end）层之后，会带来哪些变化？首先，SFF 的职责更加聚焦，天然具备免运维、低成本等优势，这正是 Serverless 平台能力带来的直接收益，也能够帮助前端团队进一步释放研发效率。其次，开发者不再需要依赖臃肿的富 BFF 层，仅通过一个接口或一个 SFF 服务即可完成能力交付，“牵一发而动全身”的问题自然得到缓解。如果某个接口停服或长期无流量，对应实例会自动缩容至零，定位问题函数会更加直接，后续也更容易下线无用函数，进一步提升资源利用率。

高德在 Serverless 应用实践上走得较为靠前，已经实现 FaaS 层与整体研发体系的深度打通。因此，从应用开发、测试、灰度到正式上线的全生命周期流程，再到流控、弹性扩缩容、容灾等标准化能力建设，整体交付效率相比过去缩短了 40%，显著提升了研发人效。

2. 弹性以及成本

从流量趋势数据可以明显看出，地图出行场景具有典型的流量波峰波谷特征——高峰期与低峰期差异非常明显。按照传统应用架构的资源准备方式，系统通常需要按照最高流量峰值预留资源，这意味着在流量低谷时，大量机器资源会处于闲置状态，进而造成明显的成本浪费。

针对这一问题，高德采用了阿里云函数计算，能够根据实时流量变化自动完成扩缩容。不过，快速扩缩容本身是一项实现复杂度较高的能力，过去往往只有大型企业才能较好地建设和掌握。而函数计算凭借毫秒级启动能力，把“快速扩、快速缩”的弹性能力普惠给更多用户，帮助业务更轻松地实现计算资源弹性利用，同时显著降低整体成本。

3. 可观测性

可观测性是应用上线与故障诊断平台不可或缺的关键能力。只有能够清晰观察 RT 变化、资源使用率以及系统应用的全链路调用情况，才能更快速地定位系统瓶颈并完成问题诊断。阿里云函数计算率先与日志服务、云监控、tracing 平台以及函数工作流编排进行了深度融合，用户只需完成一次配置，即可完整使用上述能力，大幅降低学习门槛与接入成本，实现对应用程序的快速观测与高效诊断。

Serverless 规模化落地的序幕已经正式开启，越来越多的行业与业务场景正在加速解锁。对高德而言，Serverless 在核心业务中的规模化应用，让业务迭代变得更快、更灵活，也为业务创新提供了更充足的前提条件；对于前端开发者来说，则进一步激发了研发潜能，增强了技术能力与工程自信。高德出行业务从 2020 年初的能力试点，到“十一出行节”期间覆盖自主出行核心场景，在接入阿里云函数计算的过程中，积累了十分宝贵的云原生与 Serverless 落地经验，也为未来业务整体上云奠定了坚实基础。

作者简介：何以然（以燃） 阿里巴巴前端技术专家，2016 年入职高德地图，目前负责高德出行业务研发以及 Serverless 相关技术落地

原文链接
本文为阿里云原创内容，未经允许不得转载。