酷家乐 Serverless FaaS 产品落地实践


【编者的话】最近两年,Serverless 这个概念非常火热,其能带来的弹性伸缩、快速开发、无运维等特性也深深吸引了众多优秀的实践者。

酷家乐技术团队自 2019 年底开始实验性地落地 Knative 作为酷家乐函数计算基础设施,同时自研以 Node.js 语言为主的 FaaS 产品来赋能公司内部业务方。

本文主要介绍 Serverless FaaS 在酷家乐的落地方式以及对未来 FaaS 发展的一些看法。

对 FaaS 平台的理解

随着云计算服务体系的发展,慢慢演进出 IaaS(Infrastructure as a Service),CaaS(Container as a Service),PaaS(Platform as a Service)和 FaaS(Function as a Service)等服务模型。
1.png

根据上图蓝色方块可知,每个服务模型的弹性单元是不一样的。

服务的可拓展粒度正在越变越小,这也代表着开发者需要关注的内容越来越少。

无论是哪种服务模型,其目的都是通过封装行业现有认可的基本解决方案和架构,提供给用户业务快速启动的能力。

Faas 是一种相对较新的服务模型,以函数做为服务,也是当前 Serverless 主流表现形式。

在该服务模型下,用户只需要关注函数逻辑即可完成服务开发,而不需要去关心复杂的应用维护和基础设施建设。

FaaS 平台(Function as a Service)是为用户提供开发、运行和管理的函数服务平台。

以承载“函数”的方式来启动基础应用框架,并对应用实现资源编排、自动伸缩、全生命周期覆盖、底层资源联动等保障,从而实现云服务的 Serverless。

FaaS 可以带来的业务收益

FaaS 带来的最大好处,就是可以让业务快速启动,免去运维、维护的烦恼。

这里从“开发模式、分工方式、框架设计、实现过程”四个角度介绍下当前业务开发存在的困难点:
  • 在传统业务开发模式中,技术栈、方案往往都会因公司规模、团队而异,如果没有持续做技术沉淀,基本没法复用,各组内选型自由,导致业务间切换成本很高。
  • 在传统业务分工方式中,前端由于涉及到服务端知识的学习成本,无法自行开发和维护 BFF 之类的适配层,后端也因接口定义多、乱而导致系统结构复杂。
  • 在传统业务框架设计中,既要考虑各种技术细节和业务因素,还要考虑后期的维护和升级等等,业务开发前期的沉没成本非常高。
  • 在传统应用实现过程中,服务器资源申请、构建部署、服务质量、服务稳定性等基本服务要求,都需要耗费大量的人力成本去维护。


2.png

通过 FaaS 的服务开发方式,可以较好的用来解决上述问题:
  • “统一”了业务组间的业务实现方式,业务切换快
  • 消除服务端技术壁垒,可以使用熟悉的技术栈做业务逻辑开发
  • 对用户“无框架”概念,用户只需要了解函数的输入和输出
  • 从部署、发布、监控“一条龙”式的平台服务,也较好的规避了常规的稳定性问题


3.png

酷家乐 FaaS 平台的落地方式

FaaS 基础设施

经过对各 FaaS 技术栈的分析比对,我们最终选择使用 Kubernetes + Knative + Istio 的组合方式来搭建应用级 Serverless。
4.png

上图是酷家乐现有的 Serverless 架构切面,简单可以分为用户层和平台层。

用户层:
  • 通过 serverless-cli 来完成本地创建、开发、调试、发布等用户操作
  • Serverless 管理平台集成了实时日志查看、全链路查询等实用功能,并提供了一些页面式函数操作


平台层:
  • 主网关、FaaS 网关做请求转发,再由 Knative 网关转发到函数
  • Built-in 是虚拟的一层,表示 image 的功能属性
  • Runtime 是各语言栈的函数运行时,目前使用的主要是 node.js
  • Knative 和 Kubernetes,底层资源编排


FaaS 前台架构

5.png

这是酷家乐 FaaS 前台的整体架构,虚线框内是函数构建&部署流程。

对于企业而言,使用内部现有的 GitLab 托管函数代码、基于 GitLab CI 来控制流程是最简单通用、成本最低的管理手段,

由于构建&部署操作常常会随着集群信息、发布逻辑等改变而改变,如果让用户经常去更新代码仓库是体验非常差的行为,

我们把 CI 过程脚本、Dockerfile 等公用文件,都使用 OSS 来托管;每次执行 CI 流程时,都会下载这些文件的最新版本,并根据 ci stages 步骤按需执行。

这样的话,我们每次的部署逻辑更新都会对用户无感。

FaaS 研发流程

6.png

与传统研发模式相比,FaaS 模式下除去了技术选型、资源申请等繁琐的流程,让用户更专注于业务逻辑上。

FaaS 产品介绍

酷家乐目前支持 Node.js、Python、Java 的 FaaS 开发语言,下面简单介绍一下基于社区开源方案自研的 Node.js FaaS 产品。
7.png

上一节有提到,我们使用 gitlab repo 来托管函数代码,repo 和 function 的关系是 1:1,以此保证每个函数之间的彼此独立。

但是在业务推进中发现,真实业务场景这类独立逻辑并没有那么多,往往是需要写多个函数来完成一个功能/需求。

通过对用户场景的具体分析,同时借鉴了社区开源 FaaS 框架的设计思想,我们引入了多函数的承载概念,将 repo 和 function 升级成 1:n 的关系,这样就能把一整套逻辑的代码都聚合在同个 repo 里。

函数部署方式也可以根据实际场景去选择,多函数模式支持独立部署、聚合部署、混合部署三种方式。

比如聚合部署(即 Pod 内聚合多个函数)适合处理低流量多接口业务、混合部署(聚合 + 部分函数独立部署)适合解决热点问题。
8.png

在函数编写格式和用户体验上,我们保持与社区、大部分云服务商的基本一致,便于后续可能的迁移和升级。
9.png

用户通过 faas.yml 配置来声明函数路由信息,并按需自由定义接口路由、部署配置、公共插件等信息。

酷家乐 FaaS 平台的落地场景

目前酷家乐已落地 40+ 函数在线服务,但主要集中在创新、边缘业务。

在已落地的应用场景上,主要可以分为有两类:
  • 提供在线的,以 API 为管理维度的聚合类 API
  • 提供离线的,以响应式和弹性为特点的离线计算业务


10.png

在开发语言上,Node.js 的使用率占多数,这也从侧面表现出 FaaS 对于前台服务的适用性和友好度。

FaaS 和传统应用之间的思考

FaaS 在发展中必定会考虑的一件事,就是如何衡量函数和应用的关系。

从当前发展趋势上看,无论云商还是企业内部、Serverless component(也有用 FaaS 做载体的)或是 FaaS 平台,都想利用 FaaS 带来的红利去实现应用级别的业务。

毕竟应用代表着用户量、业务规模、流量等等,某种意义上是一种革命成功的象征。但是没有一门技术是完美的,我们需要客观地看待 FaaS 对于传统业务应用的意义。

以前在一篇描述“分布式单体”的文章中看到过:


从传统单体应用到分布式微服务,再到现在的Serverless……不过是建立在业务拆分的基础上,用“进程间的远程调用”简单替代了“原来进程内的方法调用”而已。在本质上,Serverless 也并没有改变微服务中存在的内部耦合问题,只是更细化的组件粒度,却增多了系统中远程调用的数量。
而且对于大部分应用来说,FaaS 本身并没有太大的资源优势,虽然单个函数本身在资源占用上很小,但是由微服务拆分出来的函数服务,其需要引入的共享类库和网络客户端的规模是由函数个数 * Pod 数决定的,资源消耗可能会远大于单个微服务的应用。

所以在需求落地前,我们要结合“业务规模和 FaaS 现状”、“资源成本和人力成本”、“跨组合作和快速启动”、“出错成本和容错粒度”等因素来综合考虑是否选择 FaaS,而不是一股脑的上就行。
11.png

未来酷家乐 FaaS 实践方向

相信很多前端开发者都听说过这两个名词:
  • BFF(Backend For Frontend),服务于前端的后端。
  • SFF(Severless For Frontend),Serverless 化的 BFF 架构。


我们也很认可 SFF 能给酷家乐带来的业务价值,让更多的前端同学只需要关注于业务逻辑,就可以完成 API 的编写,发布和上线,实现数据适配层的自管理,减少前后端沟通成本,提高整体研发效率。

这个对于中小型开发团队来说的确是一个不错的选择,未来我们也将会在 SFF 上做更多的场景落地和架构升级,更好、更便利的赋能给我们的内部业务方。
12.png

原文链接:https://tech.kujiale.com/kujia ... ence/,作者:冰蛙

0 个评论

要回复文章请先登录注册