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

Serverless 技术落地架构设计

在系统设计上，我们引入了两层 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 给我们带来的技术红利！
本文为阿里云原创内容，未经允许不得转载。