为什么（前端）要推动建设 Serverless

• 更快地创建一个服务且免运维：大量的 Nodejs 服务，创建服务，需要申请节点、申请机器，对接构建、部署、日志、监控，还要持续运维服。我们希望能更快创建一个服务并且免运维。

• 更灵活的隔离能力：前端 BFF 接口聚合、微前端等业务场景，需要创建大量的接口服务，快速创建服务的同时，还希望可以以不同粒度灵活进行接口间的隔离。

• 更低的成本：大量低峰期时间cpu/内存利用率很低，服务不再使用了，资源却仍然占用。

我们的方案

我们调研了业界的 Serverless 方案，最终决定了自己的方案：K8s + Knative + Istio 搭建应用级 Serverless。他的优势是：

• 社区相对繁荣，未来充满希望。

• 应用级 Serverless, 和传统通过 Docker 镜像开发，部署相近，现有服务迁移成本低。

• 应用级 Serverless, 通过 Serverless。路由，可以灵活控制隔离的粒度。

通过 Serverless 升级研发模式

那有了 Severless 基础能力，如何通过他来升级我们的研发模式呢？

• 我们提供 npm 包打通公司的基础能力，包括数据存储相关、通信相关

• 上层封装层 各种框架的中间件

• 再上层是面向业务领域的框架，express/koa/以及我们基于egg打造的degg框架，他一定程度上方便了从零到一创建一个公司内部标准的服务。现在我们称之为面向 Serverless 的高级模式，业务同学可以更专注于业务编码，简单、高效完成这么一个日常开发迭代的流程

Serverless 全局图 - 研发视角

从研发视角看下，整个 Serverless的全局，自上而下是：

• 业务场景解决方案 ，基于 Serverless 平台，在Serverless-cli 插件规范下的场景解决方案

• Serverless -cli 和 Vscode 插件，作为面向开发者的统一入口

• 面向业务的研发层，开发IDE, 包括本地的、云端的

• 两层网关，业务层网关到 Istio 打造的Serverless网关

• Bass SDK，用来与后台基础能力通信

• 运行在集群里的应用，包含三类

• 右侧是Appication是传统服务

• 左下是Runtime, Application, 他是将日常业务场景进行抽象，将不变的沉淀到Runtime里。

• 业务工程里只有变的东西，云函数情况下就可以是上面这个Funciton

• Nodejs 框架

• 底层集群， K8s /Knative 集群

右侧：是业务服务环境，下面是常规的日志、监控、报警、性能分析的能力

左下侧：是Nodejs生态体系，包括业务框架、SDK、Nodejs性能分析平台

左上侧：是面向Serverless 研发体系的共享市场

在虚线框里，就是面向一个业务场景，基于 Serverless 能力打造的一个通用解决方案。

Serverless 流程图 - 研发视角

将上面 Serverless 全局图拆分，我们把它分成三部分，这三部分也是我们年初立项，多个团队合作做这件事的一个模块分工，分为底层、平台层，和面向业务的研发层。

在开发者使用过程中，他们的流程是这样的：

• 上层不同场景的工程，使用统一的cli, 也可以通过Vscode插件可视化来完成整个开发流程，Vscode也调用cli能力

• 然后由cli调用平台的能力，再由平台进行权限验证，调用下层通用构建、部署能力

• 最后调用Serverless底层接口，将服务部署到KNative+K8s集群上

Serverless-cli 的定位

我们再来看下 Serverless-cli,  它的定位是，基于插件式命令行扩展框架。他包含如下3个核心能力：

• 与Serverless平台联动，完成服务构建、部署等操作

• 提供规范，灵活的命令扩展能力

• 打造开发者生态，场景方案共享，并保持开发体验的一致性

serverless-cli 的设计

cli 设计包含核心模块、默认命令、webpack相关、配置规范、以及基于cli 框架上层打造的插件生态。

场景方案

场景方案 - FaaS（云函数）

第一个场景方案：云函数。函数即服务，用户快速编写一个函数接口，这里创建了两个接口, 每个接口暴露一个函数，入参为param 和 context, 通过 async 返回函数同步异步结果。这个场景的插件为 @didi/sls-cli-plugin-faas, 用户通过 package.json 中声明依赖即可。FaaS工程类型的优势，是简单高效，并且通过Serverless 路由可以灵活控制隔离粒度。

场景方案 - Sma（微应用）

第二个场景方案：微应用。

页面即服务，前后端代码一体化，service.js 里保留出两个接口 list 和 add， 此时可以在前端组件中，类似远程调用，直接调用这两个方法，如同本地函数一样。另外它的服务端代码上下文和 FaaS 保持一致。

场景方案 - Sma-light（微应用-轻量版）

因为是应用级Severless方案，服务部署过程还是需要经历构建代码、编译镜像、以及整个应用级的部署。故我们基于Runtime的设计，结合Nodejs热更新能力，来支持页面级发布能力，轻量微应用类型工程。它支持

• 静态页面、接口

• 动态页面、接口

• 页面模板、中间件等抽象，打造该工程类型的物料生态

不同场景方案，一致开发体验

我们来感受下，不同场景下一致的开发体验，包括创建、构建、开发、部署等 执行dev 时会一件启动前端资源webpack服务，同时启动服务端runtime服务，打开导航页面。

另外部署，可以执行 sls deploy, 通过 cli 将服务、按场景先后，按流量分组部署到 Severless 平台。也可以通过 Vscode 插件可视化方式进行操作，进行部署、回滚。

云端开发

更进一步，我们提供了云端开发能力，来满足一些如云函数，这类轻量创建服务的方式，开发者可以通过平台创建函数、页面，完成开发、调试，上线，且它的开发体验与本地是完全环境一致，并且是复用的。

基于 Serverless 面向业务聚合

我们来看一个业务使用案例。

这是我们普惠的工作台，是一个面向运营，集合了多个业务线后台系统。这里的菜单栏是配置集成起来的，每个菜单项是一个独立的页面，目前我们还没有采用微前端的一些轻量的隔离方案，使用的是简单、有效的iframe来进行隔离的。每个页面即服务，由每个业务线团队里的每个同学，用他们熟悉的技术栈，通过的前面介绍的微应用解决方案，独立运维。

最后

最后，我们也在积极探索用 V8 Isolate 与我们现有应用级Serverless + Runtime设计结合，实现面向nodejs更轻量高效的Serverless 隔离方案。