作者 | 邓学祥（祥翼）
起源 | Serverless 公众号

高德从 FY21 财年开始启动 Serverless 建设，至今一年了，高德 Serverless 业务的峰值超过十万 qps 量级，平台从 0 到 1，qps 从零到十万，成为阿里团体内 Serverless 利用落地规模最大的 BU，这两头的过程是怎么样的？遇到过哪些问题？高德为什么要搞 Serverless/Faas？是如何做 Serverless/Faas 的？技术计划是什么样的？目前停顿怎么样？后续又有哪些打算？本文将和大家做一个简略的分享。

1. Why- 高德为什么要搞 Serverless

高德为什么要搞 Serverless？背景起因是高德 FY21 财年启动了一个客户端上云我的项目。客户端上云我的项目的次要目标是 为了晋升客户端的开发迭代效率。

以前客户端业务逻辑都在端上，产品需要的变更须要走客户端发版能力公布，而客户端发版须要走各种测试流程、灰度流程，解决客户端解体等问题，目前的节奏是一个月一个版本。

客户端上云之后，某些易变的业务逻辑放到云上来。新的产品需要在云端来开发，不必走月度的版本公布，放慢了需要的开发迭代效率，离产研同频的现实指标又近了一步（为什么要说“又”，是因为高德之前也做了一些优化往产研同频的方向致力，然而咱们心愿云端一体化开发能够是其中最无效的一个技术助力）。

1.1 指标：客户端开发模式 – 端云一体

尽管开发模式从以前的端开发转变为当初的云 + 端开发，开发同学应该还是原来负责相应业务的同学，然而大家晓得，服务端开发和客户端开发显然是有差别的，客户端开发是面向单机模式的开发，服务端开发通常是集群模式，须要思考分布式系统的协调、负载平衡、故障转移降级等各种简单问题。如果应用传统的服务端模式来开发，这个过渡危险就会比拟大。

Faas 很好地解决了这一问题。咱们联合高德客户端现有的 xbus 框架（一套客户端上的本地服务注册、调用的框架），扩大了 xbus-cloud 组件，使得云上的开发就像端上开发一样，指标是一套代码、两地运行，一套业务代码既能在客户端上运行，也能在服务端上运行。

高德客户端次要有三个端：IOS、android、车机（类 Linux 操作系统）。次要有两种语言：C++ 和 Node.js。传统地图功能：如地图显示、导航门路显示、导航播报等等，因为须要跨三个端，采纳的 C++ 语言来开发。地图导航根底之上的一些地图利用性能，如行前 / 行后卡片、举荐目的地等，次要用 Node.js 来开发。

FY20 财年淘系前端团队开发了 Node.js Faas runtime。高德客户端上云我的项目，Node.js 的局部就采纳了现有的淘系的 Node.js runtime，来接入团体的 Faas 平台，实现 Node.js 这部分的一些业务上云。2020 年十一期间很好地撑持了高德的十一出行节业务。

C++ Faas 没有现有的解决方案，因而咱们决定在团体的基础设施之上做加法，新建 C++ Faas 根底平台，来助力高德客户端上云。

1.1.1 端云一体的最佳实际要害：客户端和 Faas 之间的接口形象

本来客户端的逻辑移到 Faas 服务端上来，或者新的需要一部分在 Faas 服务端上开发，这里的成败关键点在于：客户端和 Faas 的接口协议定义，也就是 Faas 的 API 定义，好的 API 定义除了对系统的可维护性有益处以外，对后续撑持业务的迭代开发也很重要，好的 API 定义请参考谷朴大神的文档：《API 设计最佳实际的思考》。

现实状况下：客户端做成一个解析 Faas 返回后果数据的一个浏览器。浏览器协定一旦定义好，就不会常常变换，你看 IE、Chrome 就很少更新。当然咱们的这个浏览器会简单一些，咱们这个浏览器是地图浏览器。如何测验客户端和 Faas 之间的接口定义好不好，能够看后续的产品需要迭代，如果有些产品需要迭代只须要在 Faas 上实现，不须要客户端的任何批改，那么这个接口形象就是胜利的。

1.2 BFF 层开发提效

提到高德，大家首先想到的应该是其工具属性：高德是一个导航工具（这个说法当初曾经不太精确了，因为高德这几年在做工具化往平台化的转型，咱们要做万能的高德，高德的交易类业务正在衰亡，高德打车、门票、酒店等业务倒退很迅猛）。

针对高德导航来说，相比团体其余业务（如电商）来说，有大量的只读场景是高德业务的一大技术特点。这些只读场景里，大量的需要是 BFF（Backend For Frontend）类型的只读场景。为什么这么说？因为导航的最外围性能，例如 routing、traffic、eta 等都是绝对稳固的，这部分的次要工作在继续一直地优化算法，使得高德的交通更准，算出的门路更优。这些外围性能在接口和性能上都是绝对比较稳定的，而前端需要是多变的，例如减少个门路上的限宽墩提醒等。

Faas 特地适宜做 BFF 层开发，在 Faas 上调用后端绝对稳固的各个 Baas 服务，Faas 服务来做数据和调用逻辑封装、疾速开发、公布。在业界，Faas 用的最多的场景也正是 BFF 场景（另外一个叫法是 SFF 场景，service for frontend）。

1.3 Serverless 是云时代的高级语言

FY21，高德是团体内第一个全面上云的 BU，尽管高德曾经全面上云了，然而这还不是云时代的终局，目前次要是全面 pouch 化并上云，容器方面做了标准化，在规模化、资源利用率方面能够全面享受云的红利，然而业务开发模式上基本上还和以前一样，仍是一个大型的分布式系统的写法。对于研发模式来说还并没有享受云的红利，能够类比为咱们当初是在用汇编语言的形式来写跑在云上的服务。而 Serverless、云原生能够了解为云时代的高级语言，真正做到了 Cloud as a computer，只须要关注于业务开发，不须要思考大型分布式系统的各种复杂性。

1.4 Go-Faas 补充 Go 语言生态

后面讲到了因为客户端上云我的项目，咱们在阿里云 FC（函数计算）团队之上做加法，开发了 C++ Faas Runtime。不仅如此，咱们还开发了 Go-Faas，咱们为什么会做 Go-Faas 呢？这里也简略介绍一下背景，高德服务端 Go 局部的 qps 峰值已超百万。高德已补齐了阿里各中间件的 Go 客户端，和团体中间件部门共建。可观测性、自动化测试体系也根本欠缺，目前 Go 生态已根本欠缺。补齐了 Go-Faas 之后，咱们就既能用 Go 写 Baas 服务，又能用 Go 写 Faas 服务了，在不同的业务场景采纳不同的服务实现形式，Go-Faas 次要利用于上文提到的 BFF 场景。

2. How- 技术计划介绍：在团体现有基础设施之上做加法

2.1 整体技术架构

上文讲了咱们为什么要做这个事件，接下来讲咱们具体是怎么做这个事件的，是如何实现的，具体的技术计划是什么样的。

本着在团体现有的基础设施、现有的中间件根底之上做加法的思维，咱们和 CSE、阿里云 FC 函数计算团队单干共建，开发了 C++ Faas Runtime 和 Go Faas Runtime。整体和团体拉通的技术架构如下图所示，次要分为研发态、运行态、运维态三个局部。

2.1.1 运行态

先说运行态，业务流量从咱们网关进来，调用到 FC API Server，转发到 C++/Go Faas Runtime，runtime 来实现用户函数里的性能。runtime 的架构本文下一章节会具体介绍。

和 runtime container 一起部署的有监控、日志、Dapr 各种 side car，side car 来实现各种日志采集上报性能，dapr side car 来实现调用团体中间件的性能。

另外目前 dapr 还在试点的阶段，调用中间件次要是通过 Broker 和各个中间件 proxy 来实现，中间件调用的有 HSF、Tair、metaq、diamond 等中间件 proxy。

最初 Autoscaling 模块来治理函数实例的扩缩容，达到函数主动伸缩的目标。这里的调度就有各种策略了，有依据申请并发量的调度、函数实例的 CPU 使用率的调度。也能提前设置预留实例数，防止缩容到 0 之后的冷启动问题。

底层调用的是团体 ASI 的能力，ASI 能够简略了解为团体的 K8S+ sigma（团体的调度零碎），最终的部署是 FC 调用 ASI 来实现函数实例部署，弹性伸缩的，部署的最小单位是上图中的 pod，一个 pod 里蕴含 runtime container 和 sidecar set container。

2.1.2 研发态

再来看研发态，运行态决定函数是如何运行的，研发态关注函数的开发体验，如何不便地让开发者开发、调试、部署、测试一个函数。

C++ Faas 有个跨平台的难点问题，C++ Faas runtime 里有一些依赖库，这些依赖库没有 Java 依赖库治理那么不便。这样依赖库的装置比拟麻烦，Faas 脚手架就是为了解决这个问题，调用脚手架，一键生成 C++ Faas 示例工程，装置好各种依赖包。为了本地能不便地 debug，开发了一个 C++ Faas Runtime Boot 模块，函数 runtime 启动入口在 boot 模块里，boot 模块里集成 runtime 和用户 Faas 函数，能够对 runtime 来做 debug 单步调试。

咱们和团体 Aone 团队单干，函数的公布集成到 Aone 环境上了，能够很不便地在 Aone 上来公布 Go 或者 C++ Faas，Aone 上也集成了一键生成 example 代码库的性能。

C++ 和 Go Faas 的编译都依赖相应的编译环境，Aone 提供了自定义编译镜像的性能，咱们上传了编译镜像到团体的公共镜像库，函数编译时，在函数的代码库里指定相应的编译镜像，编译镜像里装置了 Faas 的依赖库、SDK 等。

2.1.3 运维态

最初来看函数的运维监控，runtime 外部集成了鹰眼、sunfire 采集日志的性能，runtime 外面会写这些日志，通过 sidecar 里的 agent 采集到鹰眼、或者 sunfire 监控平台下来（FC 是通过 SLS 来采集的）之后，就能应用团体现有的监控平台来做 Faas 的监控了，也能接入团体的 GOC 报警平台。

2.2 C++/Go Faas Runtime 架构

下面讲的是和 Aone、FC/CSE、ASI 集成的一个整体架构，Runtime 是这个整体架构的一部分，上面具体讲讲 Runtime 的架构是怎么的，Runtime 是如何设计和实现的。

最下面局部的 用户 Faas 代码只须要依赖 Faas SDK 就能够了，用户只须要实现 Faas SDK 里的 Function 接口就能写本人的 Faas 了。而后如果须要调用内部零碎，能够通过 SDK 里的 Http Client 来调用，如果要调用内部中间件，通过 SDK 里的 Diamond/Tair/HSF/metaq Client 来调用中间件就能够。SDK 里的这些接口屏蔽了底层实现的复杂性，用户不须要关怀这些调用最初是如何实现，不须要关怀 runtime 的具体实现。

SDK 层 就是下面提到的 Function 定义和各种中间件调用的接口定义。SDK 代码是开发给 Faas 用户的。SDK 做的比拟轻薄，次要是接口定义，不蕴含具体的实现。调用中间件的具体实现在 Runtime 里有两种实现形式。

往下是 Runtime 的一个整体架构。Starter 是 runtime 的启动模块，启动之后，runtime 本身是一个 Server，启动的时候依据 Function Config 模块的配置来启动 runtime，runtime 启动之后开启申请和治理监听模式。

再往下是 Service 层，实现 SDK 里定义的中间件调用的接口，蕴含 RSocket 和 dapr 两种实现形式，RSocket 是通过 RSocket broker 的模式来调用中间件的，runtime 里集成了 dapr（distributed application runtime），调用中间件也能够通过 dapr 来调用，在后期 dapr 试点阶段，如果通过 dapr 调用中间件失败了，会降级到 rsocket 的形式来调用中间件。

再往下就是 rsocket 的协定层，封装了调用 rsocket 的各种 metadata 协定。dapr 调用是通过 grpc 形式来调用的。

最上面一层就是集成了 rsocket 和 dapr 了。

rsocket 调用还波及到 broker 抉择的问题，upstream 模块来治理 broker cluster、broker 的注册反注册、keepalive 查看等等，LoadBalance 模块来实现 broker 的负载平衡抉择以及事件治理、连贯治理、重连等等。

最初 runtime 里的 metrics 模块负责鹰眼 trace 的接入，通过 filter 模式来拦挡 Faas 链路的耗时，并输入鹰眼日志。打印 sunfire 日志，供 sidecar 去采集。下图是一个理论业务的 sunfire 监控界面：

2.2.1 Dapr

dapr 架构如下图所示，具体能够参考官网文档。

runtime 里以前调用中间件是通过 rsocket 形式来调用的，这里 rsocket broker 会有一个中心化问题，为了解决 outgoing 流量去中心化问题，和团体中间件团队单干引入了 dapr 架构。只是 runtime 层面集成了 dapr，对于用户 Faas 来说无感知，不须要关怀具体调用中间件是通过 rsocket 调用的还是通过 dapr 调用的。前面 runtime 调用中间件切换到 dapr 之后，用户 Faas 也是不须要做任何批改的。

3. How- 业务如何接入 Serverless

如前文所述，接入对立在 Aone 上接入。提供了 C++ Faas/Go Faas 的接入文档。提供了函数的 example 代码库，代码库有各种场景的示例，包含调用团体各种中间件的代码示例。C++ Faas/Go Faas 的接入对整个团体开发，目前曾经有一些高德以外的 BU，在本人的业务中落地了 C++ /Go Faas。Node.js Faas 应用淘宝提供的 runtime 和模板来接入，Java Faas 应用阿里云 FC 提供的 runtime 和模板来接入就能够了。

3.1 接入标准 - 稳定性三板斧：可监控、可灰度、可回滚

针对落地新技术大家可能放心的稳定性问题，咱们的应答法宝是阿里团体的稳定性三板斧：可监控、可灰度、可回滚。建设 Faas 链路保障群，拉通上下游各相干业务方、根底平台一起，依照团体的 1-5-10 要求，独特努力做到 1 分钟之内响应线上报警、疾速排查；5 分钟之内解决；10 分钟之内复原。

为了标准接入过程，防止犯错误引发线上故障，咱们制订了 Faas 接入标准和 checkList，来帮忙业务方疾速应用 Faas。

可监控、可灰度、可回滚是硬性要求，除此之外，业务方如果能做到可降级就更好了。咱们的 C++ 客户端上云业务，在开始试点阶段，就做好了可降级的筹备，如果调用 Faas 端失败，本次调用将会主动降级到本地调用。根本对客户端性能无损，只是会减少一些响应提早，另外客户端上该性能的版本，可能会比服务端略微老一点，然而性能是向前兼容的，根本不影响客户端应用。

4. Now- 咱们目前的状况

4.1 根底平台建设状况

• Go/C++ Faas Runtime 开发实现，对接 FC-Ginkgo/CSE、Aone 实现，已公布稳固的 1.0 版本。
• 做了大量的稳定性建设、优雅下线、性能优化、C 编译器优化，应用了阿里云根底软件部编译器优化团队提供的编译形式来优化 C++ Faas 的编译，性能晋升显著。
• C++/Go Faas 接入鹰眼、sunfire 监控实现，函数具备了可观测性。
• 池化性能实现，具备秒级弹性的能力。池化 runtime 镜像接入 CSE，扩一个新实例的工夫由原来的分钟级变为秒级。

4.2 高德的 Serverless 业务落地状况

C++ Faas 和 Go Faas 以及 Node.js Faas 在高德外部曾经有大量的利用落地。举几个例子：

上图中的前两个图是 C++ Faas 开发的业务：短途天气、沿途搜。后两个截图是 Go-Faas 开发的业务：导航 tips、脚印地图。

高德是阿里团体内 Serverless 利用落地规模最大 的 BU，已落地的 Serverless 利用，日常峰值超过十万 qps 量级。

4.3 次要收益

高德落地了团体内规模最大的 Serverless 利用之后，都有哪些收益呢？

首先第一个最重要的收益是：开发提效。咱们基于 Serverless 实现的端云一体组件，助力了客户端上云，解除了须要实时的客户端发版依赖问题，晋升了客户端的开发迭代效率。基于 Serverless 开发的 BFF 层，晋升了 BFF 类场景的开发迭代效率。

第二个收益是：运维提效。利用 Serverless 的主动弹性扩缩容技术，高德应答各种出行顶峰就更从容了。例如每年的十一出行节、五一、清明、春节的出行顶峰，不再须要运维或者业务开发同学在节前提前扩容，节后再缩容了。高德业务顶峰的特点还不同于电商的秒杀场景。出行顶峰的流量不是在 1 秒内忽然涨起来的，咱们目前利用池化技术实现的秒级弹性的能力，齐全能满足高德的这个业务场景需要。

第三个收益是：降低成本。高德的业务特点，白天流量大、夜间流量低，顶峰值和低谷值差别较大，时间段辨别显著。利用 Serverless 在夜间流量低峰时主动缩容技术，极大地升高了服务器资源的老本。

5. Next- 后续打算

• FC 弹内函数计算应用优化，和 FC 团队一起继续优化弹内函数计算的性能、稳定性、应用体验。用团体内丰盛的大流量业务场景，来一直打磨好 C++/Go Faas Runtime，并最终输入到私有云，普惠数字化转型浪潮中的更多企业。
• Dapr 落地，解决 outcoming 流量去中心化问题，逐渐上线一些 C++/Go Faas，应用 Dapr 的形式调用团体中间件。
• Faas 混沌工程，故障演练，逃生能力建设。Faas 在新财年也会参加咱们 BU 的故障演练，逐个解决演练过程中发现的问题。
• 接入边缘计算。端云一体的场景下，Faas + 边缘计算，能提供更低的延时，更好的用户体验。

以上要做的事件任重道远，另外 FY22 财年咱们部门还会做云原生的试点和落地。技术同学都晓得，从技术选型、技术原型到理论业务落地，这之间还有很长的路要走。