导读

高德启动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-1、清明、双旦、春节的出行顶峰，不再须要运维或者业务开发同学在节前提前扩容，节后再缩容了。

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

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

5. 后续打算

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

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

欢送对Serverless、云原生、或者Go利用开发感兴趣的小伙伴，想一起做点事件的同学来退出咱们（不论之前是什么技术栈，英雄不问出处，投简历到 gdtech@alibaba-inc.com，邮件主题为：姓名-技术方向-来自高德技术），这里有大规模的落地场景和简略凋谢的技术气氛。欢送自荐或举荐。