高德Serverless平台建设及实践

极客们，请收下2021 微软 x 英特尔***松大赛英雄帖！>>>

导读

高德启动Serverless建设已经有段时间了，目前高德Serverless业务的峰值早已超过十万QPS量级，平台从0到1，QPS从零到超过十万，成为阿里集团内Serverless应用落地规模最大的BU。这个过程如何实现，遇到过哪些问题？本文将和你们分享高德为什么要搞Serverless/Faas，如何作，技术方案是什么？目前进展以及后续计划有哪些，但愿对感兴趣的同窗有所帮助。

1. 高德为何要搞Serverless

背景缘由是高德当年启动了一个客户端上云项目，项目主要目的是为了提高客户端的开发迭代效率。之前客户端业务逻辑都在端上，产品需求的变动须要走客户端发版才能发布，而客户端发版须要走各类测试流程，灰度流程，解客户端崩溃等问题。

客户端上云以后，某些易变的业务逻辑放到云上来。新的产品需求经过在云端来开发，不用走月度的版本发布，加快了需求的开发迭代效率，离产研同频的理想目标又近了一步（为何要说“又”，是由于高德以前也作了一些优化往产研同频的方向努力，可是咱们但愿云端一体化开发能是其中最有效的一个技术助力）。

1.1 目标：客户端开发模式——端云一体

虽然开发模式从之前的端开发转变为如今的云 + 端开发，开发同窗应该仍是原来负责相应业务的同窗，而你们知道，服务端开发和客户端开发显然是有差别的，客户端开发每每是面向单机模式的开发，服务端开发一般是集群模式，须要考虑分布式系统的协调、负载均衡，故障转移降级等各类复杂问题。

若是使用传统的服务端模式来开发，这个过渡风险就会比较大。Faas很好的解决了这一问题。咱们结合高德客户端现有的xbus框架(一套客户端上的本地服务注册、调用的框架)，扩展了xbus-cloud组件，使得云上的开发就像端上开发同样，目标是一套代码，两地运行，一套业务代码既能在客户端上运行，也能在服务端上运行。

高德客户端主要有三个端：iOS、Android、车机（类Linux操做系统）。主要有两种语言，C++和Node.js。传统地图功能：如地图显示，导航路径显示，导航播报等等，因为须要跨三个端，采用C++语言来开发。地图导航基础之上的一些地图应用功能，如行前、行后卡片，推荐目的地等主要是用Node.js来开发的。

在阿里集团，淘系前端团队开发了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定义除了对系统的可维护性有好处之外，对后续支撑业务的迭代开发也很重要。

理想状况下：客户端作成一个解析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是云时代的高级语言

虽然高德已经全面上云了，可是目前还不是云时代的终局，目前主要是全面Docker化并上云，容器方面作了标准化，在规模化，资源利用率方面能够全面享受云的红利，可是业务开发模式上基本还和之前同样，仍是一个大型的分布式系统的写法。

对于研发模式来讲还并无享受云的红利，能够类比为咱们如今是在用汇编语言的方式来写跑在云上的服务。而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. 技术方案介绍——在集团现有基础设施之上作加法

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. 业务如何接入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. 咱们目前的状况

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的自动弹性扩缩容技术，高德应对各类出行高峰就更从容了。例如每一年的10-1出行节，5-一、清明、双旦、春节的出行高峰，再也不须要运维或者业务开发同窗在节前提早扩容，节后再缩容了。

高德业务高峰的特色还不一样于电商的秒杀场景。出行高峰的流量不是在一秒内忽然涨起来的，咱们目前利用池化技术实现的秒级弹性的能力，彻底能知足高德的这个业务场景需求。

**第三个收益是：下降成本。**高德的业务特色，白天流量大、夜间流量低，高峰值和低谷值差别较大，时间段区分明显。利用Serverless在夜间流量低峰时自动缩容技术，极大的下降了服务器资源的成本。

5. 后续计划

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

以上要作的事情任重道远，另外咱们将来还会作更多云原生的试点和落地，技术同窗都知道，从技术选型、技术原型到实际业务落地，这之间还有很长的路要走。

欢迎对Serverless、云原生、或者Go应用开发感兴趣的小伙伴，想一块儿作点事情的同窗来加入咱们（无论以前是什么技术栈，英雄不问出处，投简历到 gdtech@alibaba-inc.com，邮件主题为：姓名-技术方向-来自高德技术），这里有大规模的落地场景和简单开放的技术氛围。欢迎自荐或推荐。