Serverless User Model

作者：刘宇

2021 年 12 月 15 日
本文字数：3723 字
阅读完需：约 12 分钟

目的和目标

Serverless User Model(简称 SUM，下文将使用 SUM 代替)的目标是定义一种 Serverless 开发者模型以及开发者规范；核心目的是基于这套模型或者规范所开发的项目，开发者可以更简单，更方便，更快速的开发 Serverless 应用，并将其部署到线上，并且可以在应用全生命周期发挥作用。

概述和术语

Serverless User Model(SUM) 是针对 Serverless 开发者的应用模型，也是 Serverless 应用开发者的开发规范，通过该规范开发的应用，可以被 Serverless Devs 开发者工具所识别，并使用 Serverless Registry 所提供的组件进行相关功能的实现。

模型概述

该规范提出了一个 Serverless 开发者模型，定义 Serverless Application 规范如下：

Serverless 应用指的是可以被 Serverless Devs 开发者工具所识别的 Serverless 应用，需要具备一个符合 Serverless Application 的 Yaml 文件，对应用进行相对应的资源描述与行为描述。

在当前版本中，Serverless User Model 定义了以下内容：

Serverless Application 规范
Serverless Package Component 使用规范

User 模型

Serverless Application 模型

Serverless Application 模型的定义，基于 Serverless Devs 开发者工具可识别的资源/行为描述文件。该文件仅支持.yaml和.yml两种格式，且需要符合 Yaml 的标准规范。与此同时，Serverless Application 模型规定，一个 Serverless Devs 开发者工具可识别的资源/行为描述文件表示一个 Serverless 应用。

同时，需要注意的是，Serverless Application 模型对应的 Yaml 格式文件默认名称为s.yaml与s.yml，且s.yaml的优先级大于s.yml，即在一个 Serverless 应用下，同时出现s.yaml与s.yml时，系统会优先识别和使用s.yaml，除非用户在使用时指定了其他 Yaml 格式的文件，作为默认文件。

关于 Serverless Application 模型对应的 Yaml 文件格式，也是有着比较严格的要求，其格式为：

edition: 1.0.0          #  命令行YAML规范版本，遵循语义化版本（Semantic Versioning）规范name: applicationName   #  应用名称access: xxx-account1    #  秘钥别名
vars: # [全局变量，提供给各个服务使用]  Key: Value
Service:  ServiceName: # 服务名称    access: xxx-account1      #  秘钥别名，如果和项目的access相同，可省略    component: componentName  #  组件名称    props: serviceProp        #  组件的属性值    actions: serviceActions   #  自定义执行逻辑

复制代码

一个完整的符合 Serverless Application 模型

edition: 1.0.0        #  命令行YAML规范版本，遵循语义化版本（Semantic Versioning）规范name: FullStack       #  项目名称access: xxx-account1  #  秘钥别名
vars: # [全局变量，提供给各个服务使用]  logo: https://image.aliyun.com/xxxx.png
services:  nextjs-portal: #  服务名称    access: xxx-account1  #  秘钥别名，如果和项目的access相同，可省略    component: vue-component  # 组件名称    props: #  组件的属性值      src: ./frontend_src      url: url    actions: # 自定义执行逻辑      pre-deploy: # 在deploy之前运行        - run: s exec -- publish  # 要运行的命令行          path: ./backend_src # 命令行运行的路径        - run: s build  # 要运行的命令行          path: ./backend_src # 命令行运行的路径      post-deploy: # 在deploy之后运行        - run: s clean          path: ./frontend_src
  assets:    component: static    props:      cache-control: "public, max-age=604800, immutable"      www: "./public"
  express-blog:    component: express    props:      app: ./express-blog      url: ${vars.domain}    actions:      pre-deploy:        - run: npm run build          path: ./express-blog
  gateway:    component: serverless-gateway # 路由组件：HTTP URL和服务之间的映射规则    props:      routes:        - route: /~assets          value: ${assets.output.url}        - route: /          value: ${nextjs-portal.output.url}          index: index.html        - route: /~portal          value: ${nextjs-portal.output.url}          inex: index.html        - route: /~blog          value: ${express-blog.output.url}

复制代码

元数据

在该格式中：

关于 Service 参数：

变量赋值

Serverless Application 模型对应的 Yaml 文件支持多种变量格式：

获取当前机器中的环境变量： $e n v (环境变量) ，例如$ {env(secretId)}
获取外部文档的变量： $f i l e (路径) ，例如$ {file(./path)}
获取全局变量：${vars.*}
获取其他项目的变量：${projectName.props.*}
获取 Yaml 中其他项目的结果变量：${projectName.output.*}

服务顺序

如果一个 Serverless Application 模型对应的 Yaml 文件中有过多的服务，系统会默认分析部署顺序，该部署顺序分为两个步骤：

分析项目中的依赖关系
有依赖关系的按照依赖关系从前到后部署，无依赖关系的按 Yaml 配置的从上到下部署

行为描述

在 Serverless Application 模型对应的 Yaml 文件中，可以针对服务，提供对应的行为操作，其基本格式是：

actions: # 自定义执行逻辑  pre-命令: # 在命令之前运行    - run: command  # 要运行的操作      path: ./path # 运行操作的路径  post-命令: # 在命令之后运行    - run: command  # 要运行的操作      path: ./path # 运行操作的路径

复制代码

例如：

actions: # 自定义执行逻辑  pre-deploy: # 在deploy之前运行    - run: s exec -- publish  # 要运行的命令行      path: ./backend_src # 命令行运行的路径    - run: s build  # 要运行的命令行      path: ./backend_src # 命令行运行的路径  post-deploy: # 在deploy之后运行    - run: s clean      path: ./frontend_src

复制代码

当 Serverless Devs 开发者工具执行到该服务时，会在进行相关的命令之行之前，优先按照顺序执行pre-命令的操作，所有内容完成执行之后，再执行post-命令的操作。

以下面的 Yaml 为例：

edition: 1.0.0        #  命令行YAML规范版本，遵循语义化版本（Semantic Versioning）规范name: FullStack       #  项目名称
services:  nextjs-portal: #  服务名称    access: xxx-account1  #  秘钥别名，如果和项目的access相同，可省略    component: vue-component  # 组件名称    props: #  组件的属性值      src: ./frontend_src      url: url    actions: # 自定义执行逻辑      pre-deploy: # 在deploy之前运行        - run: s exec -- publish  # 要运行的命令行          path: ./backend_src # 命令行运行的路径        - run: s build  # 要运行的命令行          path: ./backend_src # 命令行运行的路径      post-deploy: # 在deploy之后运行        - run: s clean          path: ./frontend_src

复制代码

当开发者在当前应用下执行了deploy命令，系统将会按照以下顺序进行操作：

在./backend_src目录下执行s exec -- publish
在./backend_src目录下执行s build
调用组件vue-component的deploy方法，并将props和项目的基本信息传入到组件vue-component的deploy方法中
在./frontend_src目录下执行s clean

以上顺序仅适用于整个流程没有出错的前提下，如果流程出现错误，系统将会进行报错，并终止后续流程的执行。

Serverless Package Component 使用规范

Serverless 开发者模型，规定了 Serverless Package Component 的使用规范。对于一个符合 Serverless Application 模型的 Yaml 文件：

edition: 1.0.0          #  命令行YAML规范版本，遵循语义化版本（Semantic Versioning）规范name: applicationName   #  应用名称access: xxx-account1    #  秘钥别名
vars: # [全局变量，提供给各个服务使用]  Key: Value
Service:  ServiceName: # 服务名称    access: xxx-account1      #  秘钥别名，如果和项目的access相同，可省略    component: componentName  #  组件名称    props: serviceProp        #  组件的属性值    actions: serviceActions   #  自定义执行逻辑

复制代码

在规范中，不同的 Service 都需要明确需要使用的 component。此时的 component 格式将会分为几种：

一个存在与指定 registry 的组件，例如fc组件等；
一个存在 Github 的仓库，且按照规 Serverless Package Component 规范发布了 Release，例如devsapp/fc
一个本地的且符合 Serverless Package Component 规范的组件路径，例如./../start-component/

适用范围

以上规范适用于条件仅限于 Serverless Devs 开发者工具所支持、所识别的 Serverless 应用。Serverless 应用开发者，可以通过上述的规范，快速通过 Serverless Devs 开发者工具，进行 Serverless 应用的创建、开发、运维等全生命周期的管理。

设计原则

为了给 Serverless 开发者更加规范和科学的 Serverless 应用开发流程，可以让 Serverless 开发者更好的通过 Serverless Devs 开发者工具对 Serverless Devs 应用进行全生命周期的管理，Serverless User Model 从开发者角度出发，提出 Serverless Application 规范以及 Serverless Package Component 规范，可以帮助开发者快速管理和操作 Serverless 应用。

发布于: 4 小时前阅读数: 6

原文链接:【http://xie.infoq.cn/article/a478b34a6d55e4e648e8517f5】。文章转载请联系作者。