如何编辑网站,做个网站多少费用,兰州手机网站制作,网络推广公司名称大全来源 | Serverless作者 | 邓学祥头图 | 下载于东方IC导读#xff1a;高德从 FY21 财年开始启动 Serverless 建设#xff0c;至今一年了#xff0c;高德 Serverless 业务的峰值超过十万 qps 量级#xff0c;平台从 0 到 1#xff0c;qps 从零到十万#xff0c;成为阿里集团… 来源 | Serverless作者 | 邓学祥头图 | 下载于东方IC导读高德从 FY21 财年开始启动 Serverless 建设至今一年了高德 Serverless 业务的峰值超过十万 qps 量级平台从 0 到 1qps 从零到十万成为阿里集团内 Serverless 应用落地规模最大的 BU这中间的过程是怎么样的遇到过哪些问题高德为什么要搞 Serverless/Faas是如何做 Serverless/Faas 的技术方案是什么样的目前进展怎么样后续又有哪些计划本文将和大家做一个简单的分享。Why-高德为什么要搞 Serverless高德为什么要搞 Serverless背景原因是高德 FY21 财年启动了一个客户端上云项目。客户端上云项目的主要目的是为了提升客户端的开发迭代效率。以前客户端业务逻辑都在端上产品需求的变更需要走客户端发版才能发布而客户端发版需要走各种测试流程、灰度流程解决客户端崩溃等问题目前的节奏是一个月一个版本。客户端上云之后某些易变的业务逻辑放到云上来。新的产品需求在云端来开发不用走月度的版本发布加快了需求的开发迭代效率离产研同频的理想目标又近了一步为什么要说“又”是因为高德之前也做了一些优化往产研同频的方向努力但是我们希望云端一体化开发可以是其中最有效的一个技术助力。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 基础平台来助力高德客户端上云。端云一体的最佳实践关键客户端和 Faas 之间的接口抽象原本客户端的逻辑移到 Faas 服务端上来或者新的需求一部分在 Faas 服务端上开发这里的成败关键点在于客户端和 Faas 的接口协议定义也就是 Faas 的 API 定义好的 API 定义除了对系统的可维护性有好处以外对后续支撑业务的迭代开发也很重要好的 API 定义请参考谷朴大神的文档《API 设计最佳实践的思考》。理想情况下客户端做成一个解析 Faas 返回结果数据的一个浏览器。浏览器协议一旦定义好就不会经常变换你看 IE、Chrome 就很少更新。当然我们的浏览器会复杂一些它是地图浏览器。如何检验客户端和 Faas 之间的接口定义好不好可以看后续的产品需求迭代如果有些产品需求迭代只需要在 Faas 上完成不需要客户端的任何修改那么这个接口抽象就是成功的。2. BFF 层开发提效提到高德大家首先想到的应该是其工具属性高德是一个导航工具这个说法现在已经不太准确了因为高德这几年在做工具化往平台化的转型我们要做万能的高德高德的交易类业务正在兴起高德打车、门票、酒店等业务发展很迅猛。针对高德导航来说相比集团其他业务如电商来说有大量的只读场景是高德业务的一大技术特点。这些只读场景里大量的需求是 BFFBackend For Frontend类型的只读场景。为什么这么说因为导航的最核心功能例如 routing、traffic、eta 等都是相对稳定的这部分的主要工作在持续不断地优化算法使得高德的交通更准算出的路径更优。这些核心功能在接口和功能上都是相对比较稳定的而前端需求是多变的例如增加个路径上的限宽墩提示等。Faas 特别适合做 BFF 层开发在 Faas 上调用后端相对稳定的各个 Baas 服务Faas 服务来做数据和调用逻辑封装、快速开发、发布。在业界Faas 用的最多的场景也正是 BFF 场景另外一个叫法是 SFF 场景service for frontend。3. Serverless 是云时代的高级语言FY21高德是集团内第一个全面上云的 BU虽然高德已经全面上云了但是这还不是云时代的终局目前主要是全面 pouch 化并上云容器方面做了标准化在规模化、资源利用率方面可以全面享受云的红利但是业务开发模式上基本上还和以前一样仍是一个大型的分布式系统的写法。对于研发模式来说还并没有享受云的红利可以类比为我们现在是在用汇编语言的方式来写跑在云上的服务。而 Serverless、云原生可以理解为云时代的高级语言真正做到了 Cloud as a computer只需要关注于业务开发不需要考虑大型分布式系统的各种复杂性。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 场景。How-技术方案介绍1. 整体技术架构上文讲了我们为什么要做这个事情接下来讲我们具体是怎么做这个事情的是如何实现的具体的技术方案是什么样的。本着在集团现有的基础设施、现有的中间件基础之上做加法的思想我们和 CSE、阿里云 FC 函数计算团队合作共建开发了 C Faas Runtime 和 Go Faas Runtime。整体和集团拉通的技术架构如下图所示主要分为研发态、运行态、运维态三个部分。运行态先说运行态业务流量从我们网关进来调用到 FC API Server转发到 C/Go Faas Runtimeruntime 来完成用户函数里的功能。runtime 的架构本文下一章节会具体介绍。和 runtime container 一起部署的有监控、日志、Dapr 各种 side carside 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。研发态再来看研发态运行态决定函数是如何运行的研发态关注函数的开发体验如何方便地让开发者开发、调试、部署、测试一个函数。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 FaasAone 上也集成了一键生成 example 代码库的功能。C 和 Go Faas 的编译都依赖相应的编译环境Aone 提供了自定义编译镜像的功能我们上传了编译镜像到集团的公共镜像库函数编译时在函数的代码库里指定相应的编译镜像编译镜像里安装了 Faas 的依赖库、SDK等。运维态最后来看函数的运维监控runtime 内部集成了鹰眼、sunfire 采集日志的功能runtime 里面会写这些日志通过 sidecar 里的 agent 采集到鹰眼、或者 sunfire 监控平台上去FC 是通过 SLS 来采集的之后就能使用集团现有的监控平台来做 Faas 的监控了也能接入集团的 GOC 报警平台。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 模块的配置来启动 runtimeruntime 启动之后开启请求和管理监听模式。再往下是 Service 层实现 SDK 里定义的中间件调用的接口包含 RSocket 和 dapr 两种实现方式RSocket 是通过 RSocket broker 的模式来调用中间件的runtime 里集成了 daprdistributed 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 监控界面Daprdapr 架构如下图所示具体可以参考官方文档https://dapr.io/runtime 里以前调用中间件是通过 rsocket 方式来调用的这里 rsocket broker 会有一个中心化问题为了解决 outgoing 流量去中心化问题和集团中间件团队合作引入了 dapr 架构。只是 runtime 层面集成了 dapr对于用户 Faas 来说无感知不需要关心具体调用中间件是通过 rsocket 调用的还是通过 dapr 调用的。后面 runtime 调用中间件切换到 dapr 之后用户 Faas 也是不需要做任何修改的。How-业务如何接入 Serverless如前文所述接入统一在 Aone 上接入。提供了 C Faas/Go Faas 的接入文档。提供了函数的 example 代码库代码库有各种场景的示例包括调用集团各种中间件的代码示例。C Faas/Go Faas 的接入对整个集团开发目前已经有一些高德以外的 BU在自己的业务中落地了 C /Go Faas。Node.js Faas 使用淘宝提供的 runtime 和模板来接入Java Faas 使用阿里云 FC 提供的 runtime 和模板来接入就可以了。1. 接入规范-稳定性三板斧可监控、可灰度、可回滚针对落地新技术大家可能担心的稳定性问题我们的应对法宝是阿里集团的稳定性三板斧可监控、可灰度、可回滚。建立 Faas 链路保障群拉通上下游各相关业务方、基础平台一起按照集团的 1-5-10 要求共同努力做到 1 分钟之内响应线上报警、快速排查5 分钟之内处理10 分钟之内恢复。为了规范接入过程避免犯错误引发线上故障我们制定了 Faas 接入规范和 checkList来帮助业务方快速使用 Faas。可监控、可灰度、可回滚是硬性要求除此之外业务方如果能做到可降级就更好了。我们的 C 客户端上云业务在开始试点阶段就做好了可降级的准备如果调用 Faas 端失败本次调用将会自动降级到本地调用。基本对客户端功能无损只是会增加一些响应延迟另外客户端上该功能的版本可能会比服务端稍微老一点但是功能是向前兼容的基本不影响客户端使用。Now-我们目前的情况1. 基础平台建设情况Go/C Faas Runtime 开发完成对接 FC-Ginkgo/CSE、Aone 完成已发布稳定的 1.0 版本。做了大量的稳定性建设、优雅下线、性能优化、C 编译器优化使用了阿里云基础软件部编译器优化团队提供的编译方式来优化 C Faas 的编译性能提升明显。C/Go Faas 接入鹰眼、sunfire 监控完成函数具备了可观测性。池化功能完成具备秒级弹性的能力。池化 runtime 镜像接入 CSE扩一个新实例的时间由原来的分钟级变为秒级。2. 高德的 Serverless 业务落地情况C Faas 和 Go Faas 以及 Node.js Faas 在高德内部已经有大量的应用落地。举几个例子上图中的前两个图是 C Faas 开发的业务长途天气、沿途搜。后两个截图是 Go-Faas 开发的业务导航 tips、足迹地图。高德是阿里集团内 Serverless 应用落地规模最大 的BU已落地的 Serverless 应用日常峰值超过十万 qps 量级。3. 主要收益高德落地了集团内规模最大的 Serverless 应用之后都有哪些收益呢首先第一个最重要的收益是开发提效。我们基于 Serverless 实现的端云一体组件助力了客户端上云解除了需要实时的客户端发版依赖问题提升了客户端的开发迭代效率。基于 Serverless 开发的 BFF 层提升了 BFF 类场景的开发迭代效率。第二个收益是运维提效。利用 Serverless 的自动弹性扩缩容技术高德应对各种出行高峰就更从容了。例如每年的十一出行节、五一、清明、春节的出行高峰不再需要运维或者业务开发同学在节前提前扩容节后再缩容了。高德业务高峰的特点还不同于电商的秒杀场景。出行高峰的流量不是在 1 秒内突然涨起来的我们目前利用池化技术实现的秒级弹性的能力完全能满足高德的这个业务场景需求。第三个收益是降低成本。高德的业务特点白天流量大、夜间流量低高峰值和低谷值差异较大时间段区分明显。利用 Serverless 在夜间流量低峰时自动缩容技术极大地降低了服务器资源的成本。Next-后续计划FC 弹内函数计算使用优化和 FC 团队一起持续优化弹内函数计算的性能、稳定性、使用体验。用集团内丰富的大流量业务场景来不断打磨好 C/Go Faas Runtime并最终输出到公有云普惠数字化转型浪潮中的更多企业。Dapr 落地解决 outcoming 流量去中心化问题逐步上线一些 C/Go Faas使用 Dapr 的方式调用集团中间件。Faas 混沌工程故障演练逃生能力建设。Faas 在新财年也会参与我们 BU 的故障演练逐一解决演练过程中发现的问题。接入边缘计算。端云一体的场景下Faas 边缘计算能提供更低的延时更好的用户体验。以上要做的事情任重道远另外 FY22 财年我们部门还会做云原生的试点和落地。技术同学都知道从技术选型、技术原型到实际业务落地这之间还有很长的路要走。更多精彩推荐
☞5G、射频、奥特曼这仨有联系吗☞再见 Nacos我要玩 Service Mesh 了☞急CPU 被挖矿该怎么找进程☞立即生效帕特·基辛格卸任 VMware 所有职务☞云原生除了K8S、微服务还有...?点分享点收藏点点赞点在看
