高德地图用户体验计划（如虎添翼高德地图）

引言“前方事故多发地段,请注意保持车距...”“您已疲劳驾驶，请注意休息...”“前方经过泰山旅游景区，中国5A级景区，是第一批国家级风景名胜区...."......这是高德出行的导航场景，像这样暖心的语音提示，在春节期间的每天都会有上百亿次，以保障您的出行安全。然而这背后，任何系统抖动或者故障，都会影响到用户的出行安全，所以在节日期间整个团队会严阵以待并去现场值班，以保障系统的稳定性。在过去的2

“前方事故多发地段,请注意保持车距...”

“您已疲劳驾驶，请注意休息...”

“前方经过泰山旅游景区，中国 5 A级景区，是第一批国家级风景名胜区...."

......

这是高德出行的导航场景，像这样暖心的语音提示，在春节期间的每天都会有上百亿次，以保障您的出行安全。然而这背后，任何系统抖动或者故障，都会影响到用户的出行安全，所以在节日期间整个团队会严阵以待并去现场值班，以保障系统的稳定性。

在过去的 2021 年，高德地图提出了新的品牌主张：在“高德地图，哪儿都熟”的背景下，高德出行 App 增添了更多的用户使用场景，随之而来业务系统也变得更为复杂。为了保障系统的稳定性，每一个节日大促期间，都会有同事去现场值班。

为了解决这一困境，我们对系统架构进行了更深的思考，并一致认同 Serverless 会是未来的技术趋势，所以在过去的一年中，我们对 Serverless 技术做了很多的探索，并实现了部分核心业务的 Serverless 化。利用 Serverless ：低成本，免运维，高弹性等优势，达成了上述提及业务，节假日无需同事再去现场值班的目标，让团队成员可以在家过一个安心团圆年。

本文会分享过去的一年，高德地图在 Serverless 领域做过哪些探索？如何与业务相结合，实现了一个低成本，低代码，免运维的现代化的 Serverless 研发平台。

自 2021 年 7 月，高德地图宣布品牌履新：整体向 “出门好生活开放服务平台”升级，同时提出了“高德地图，哪儿都熟”的新品牌主张。高德地图从导航工具升级为出行服务平台、生活信息服务入口； 为了更好地服务用户，拓展和出行相关的生活信息服务场景：高德地图主图、我的页面、行前行后场景以业务卡片的方式，透出了业务推荐信息。下图是高德 App 中出现的几个典型卡片推荐场景：

样式多变

高德地图的业务特点之一是：高频率的样式变化。节日气氛的衬托、假期旅游的引导、交通信息的提醒等等多变不同的需求下，亟需一种能够快速迭代的研发模式。而传统的研发模式是：每一个变化都是在 App 客户端上研发，然后随着 App 版本的发布进行样式再更新。（这种发版效率很慢，并且要考虑到稳定性；每月一个版本，如果仍使用这种研发模式，其实是很难满足业务需求的。）

策略多变

卡片业务背后的后端代码，会随着业务类型的不断增加，因此相应的业务策略越来越多，如果不及时与系统功能模块进行抽离，就像生命力顽强的爬山虎一样，系统代码不断无序增加，越来越臃肿，复杂性也越来越高。而多变的策略，会要求在系统架构上做出改变，达到策略的快速增加与删除，以及实时的生效。

客户端瘦身

过多的业务逻辑糅合到客户端，虽然可以一定程度上提高性能，但是如果客户端过大，也会导致用户不愿更新。其实动辄几百兆的更新，不仅会增加我们的带宽成本，也占用了用户的数据流量。此外因为代码多，相应的涉及业务也多，如果每一个业务都有快速迭代的要求，这就需要 App 客户端拥有能够快频率的更新的能力。

两者构成了恶性的循环，不利于 App 的长期发展，所以客户端瘦身势在必行。

早晚峰值

上班早高峰，下班晚高峰，相信大家都有过一致的体验：堵 ！！同样地图导航类应用，早晚峰值时间段非常的明显，且峰值和低谷的波谷差距非常大，如果所有的机器资源按照峰值去准备，这成本无疑是非常高的，在低峰期，会造成极大的资源浪费。所以我们需要能够按需使用的弹性资源技术，去降低我们的机器资源成本。

经过架构组的多轮讨论，最终我们并达成达成一致目标：全面拥抱 Serverless。 因为 Serverless 的优势特点，恰好解决了我们的业务痛点需求。我们也相信未来一定是属于 Serverless 的时代。

Serverless for frontend

不用多说，当下前端最热的技术趋势就是：云端一体化研发模式，它实际上是以 Serverless 技术作为技术底座去构建的现代化应用研发模式；不仅降低了“全栈开发工程师” 的技术门槛，还大幅提高了研发效率，阿里内部多个大型 App 都已全量使用，比如淘宝，天猫，飞猪等等。经过严格的数据统计，Serverless 在研发提效上能提高 38%，这也是我们选择 Serverless 最重要的数据依据。除此以外，基于 Serverless 实现的 CSR/SSR 首屏提速技术方案，目前也已经非常的成熟，几乎覆盖了阿里内部的 App 应用。

快速迭代

工程卓越一直是我们的追求目标，但是由于各大技术产品关注重点不同，所以对于“研发最后一公里”的相关事项并没有做太多关注，这就导致了技术产品的功能与用户体验出现割裂感，很多业务方放弃使用。

Serverless 的目标就是让你尽可能多的专注自己的业务逻辑，能够少关注或者忽略非业务核心的运维工作；加速开发时间，降低线上资源的冗余成本，所以 Serverless 无疑是扛得起降本提效的大旗的。

完全弹性

请求毫秒级的调度是 Serverless 的核心竞争力，相比传统的分钟级弹性扩容，Serverless 技术存在巨大的成本优势，扩容所耗费的时间越少，预留的机器资源就会更低，如果到了毫秒级别，就无需预留任何资源，这样成本能够大大的降低，资源利用率可以达到 100%。

低成本迁移利器 - Runtime/Container

做过程序员的同学都知道最痛苦的事情是“改别人的代码”，因此，虽然 Serverless 技术十分诱人，但是对于存量的应用如何迁移到 Serverless 架构上，也一直困扰着我们。

我们应如何以低代码的方式解决传统架构潮汐流量对资源使用不合理的问题，于是我们跟 Serverless 团队同和合作开发 Runtime。由于高德的服务均以 C、Go、Rust 的语言设计，于是我们开发出 C、Go、Rust 的 Runtime。Runtime 集成了集团内的中间件，使得 Serverless 架构可以满足我们之前服务的整个生命周期。让我们可以快速的切换服务到 Serverless 平台上。

但是随着我们使用量变大，业务场景比较复杂，一些对外的服务是无法使用内部 Runtime 的，这个严重的问题一直掣肘着我们，使原有的架构由简单又变得复杂起来。直到阿里云 Serverless 团队的同学，推出了 Custom Runimte/Container 功能，彻底解决了我们后顾之忧。我们只需改几行启动命令，就可以轻松迁移存量的应用。Serverless 团队也针对镜像的快速分发做了大量的创新优化工作，如使用四级缓存，P2P 技术，按需下载等方式，提供了秒级别下载 3G 大小镜像的能力。

得益于 Serverless 技术加持，无人值守的目标也就很容易达成，所有的运维操作，都通过 Serverless 的强大调度能力去解决，比如峰值高峰期，系统会自动毫秒级别进行扩容，低峰期同样也会 Graceful 的进行缩容，不涉及任何人为操作运维，所以这也解决了我们在节日大促期间过多人现场值班的困境。

架构设计

在系统设计上，我们引入了两层 FaaS (Function as a Serverles)，端 FaaS 和业务 FaaS，其中：

• 端 FaaS，也就是 SFF （ Serverless for frontend)，基于 Node.js，实现了端云一体化开发，将原本客户端的逻辑移到 FaaS 服务端来。这里在传统的 Frontend 和 Backend 之间抽象出了 SFF ，用来实现数据和调用逻辑封装，快速开发、发布。
• 在后端，引入业务 FaaS，基于 Java/Go 实现, 用来封装推荐策略逻辑和数据转换代码，可以提高策略迭代效率，同时减少策略迭代对主工程的影响。

从整体上看，将函数计算和容器化微服务整合在一起，综合利用函数计算的高效和传统微服务的灵活，是一种实用高效的架构设计思路。

快速迭代

作为核心的应用，需要一套完备的 CI/CD 流程去保障应用的质量，针对函数的质量，我们基于了 Serverless Devs 工具链同样实现了一套研发全流程方案:。不仅具备函数多环境，函数灰度切流，函数可观测等能力，而且通过这套 Serverless 研发体系，我们实现了 1 分钟开始进入开发，5 分钟完成上线的能力，同时默认具备异地多活的能力。

限流降级，异地多活

对于大流量应用的稳定性，限流保护，降级预案，异地多活是三大必备功能。特别是大促的时候，非预期的流量都可能引起系统雪崩，在我们的 Serverless 研发平台上，集成了阿里云函数计算的并发度流控，QPS 流控的能力，做到了函数粒度的流控。

另外一个亮点是，FaaS 的容灾方案与传统应用的容灾方案相比，有着巨大的优势。在传统应用的容灾方案中，异地多活需要在备机房中准备冗余的机器资源，这些资源也就是成本，但是在 Serverless 场景下的方案中，因为是快速弹性，秒级别就能完成资源的准备，所以无需进行资源冗余准备，这就大大节省了成本。虽然是三单元，但是成本仍然是一个单元的费用，目前所有核心的函数应用，我们都默认实现了三单元容灾。

冷启动优化

如果你的业务对于冷启动非常的敏感，比如 50 ~ 100毫秒的延迟增加，你都无法接受的话，不要担心，我们仍可以通过扩容策略进行弥补：预留资源来消减冷启动对业务的影响。

• 预留实例，根据产品流量曲线，很容易得出固定流量是多少。这部分流量用“预留模式”，适合冷启动敏感的业务；
• 按量扩容模式，按用户设置的并发度或者 CPU 利用率阈值进行扩容，扩容中的实例，不会立即接收流量，而是实例 Ready 后再进行服务。所以扩容中新增的流量会仍然派发到“正在服务中”的实例，并不会触发冷启动。

在过去的 2021 年，高德在 Serverless 领域中，做了很多方向的探索，也实现了部分核心业务的 Serverless 化。单在 Serverless 的业务 QPS 峰值就已经超过 40W QPS， 然而这不是终点，只是刚刚开始，后续我们会全面转向 Serverless 化。比如，地图数据的处理，图片的栽剪，消息的消费等等这些离线的非在线应用，它们同样也是 Serverless 的最佳适用场景，我们期望今后有更多的场景去使用 Serverless，享受 Serverless 给我们带来的技术红利 ！

原文链接：https://developer.aliyun.com/article/873818?utm_content=g_1000327194

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