高德地图|如虎添翼！高德地图+Serverless 护航你的假日出行( 二 ) 客户端|阿里巴巴|机器

两者构成了恶性的循环，不利于 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 的进行缩容，不涉及任何人为操作运维，所以这也解决了我们在节日大促期间过多人现场值班的困境。