演讲 PPT: Febase 的工程设计与实践
演讲场所: 网易-组内分享
演讲简介: 本次演讲介绍网易云音乐一站式研发平台 Febase 的工程设计与实现。
演讲时间: 2022-06-09
以下为演讲逐字稿
演讲逐字稿
0. 开场词
大家好，我是 kkdev163，今天为大家带来的分享主题是《Febase 的工程设计与实现》。
大家在日常的开发过程中，或多或少都有使用过 Febase。那你是否对平台的技术实现有过好奇呢？
这次分享，我就为大家揭开 Febase 背后的技术实现，是怎样一个技术架构，驱动了 Febase 平台的 持续迭代 和 扩展。希望能为大家带来一些 启发、思考。
1. 大纲
本次分享会分为 5 个部分..
一.引言 (Febase 产品简介)
- Febase 是一站式的研发平台，覆盖了从工程初始化到线上监控的研发生命周期。
- 上线部署阶段，Febase 提供了一致性的部署体验，如今在一个平台，我们就可以完成 多应用类型的发布
- Febase 还提供了上线流程管控，帮助研发团队养成规范的代码上线流程。
- Febase 还通过 OpenApi 的方式，向第三方平台暴露 应用模型 与 全部底层能力。
二.Febase 的多应用类型部署
由简化到复杂，抽象到具体，从一种 应用类型 到 多种应用类型 的部署
Febase 作为一个研发平台，最核心的功能点是 部署。我们首先来思考下，当我们设计一个部署平台时，最小可行产品(MVP) 是什么？
我的理解是: 这个产品可以将远程仓库代码 clone 下来，构建出线上产物，最后提供出该产物的可访问链接。
当从一个 MVP 扩展到一个 生产环境 可用的服务时，整体架构会有哪些不同？
我以静态部署平台 SDP 为例，展开介绍下:
- SDP 需要提供一个可视化的部署平台，方便开发者配置应用部署的元信息
- 如 应用名、Git 仓库、访问路由等
- 在开发者触发构建时，管理后台会调用 构建服务，触发构建流水线
- 在构建完成后，通知 产物托管服务 下载产物，并存储在 磁盘中。
- 在产物托管完成后，管理后台会通知网关 更新路由信息。
- 之后用户就可以通过 公网链接，请求到 网关
- 最后由 网关 解析路由，读取静态资源
虽然最小可行产品 MVP 很简洁，但我们看到 静态部署平台 需要分别起了 4 个服务，将静态资源托管这件事做到极致。这套架构支撑起了 云音乐庞大的 静态 Web 业务 和 RN 业务。
在 Febase 中，我们并没有重复造一套轮子，而是通过将 SDP 的部署能力下沉，提供出静态部署的原子能力。类似的 Alpaca 平台，提供了容器部署原子能力。这些部署能力，成为了我们打造 Febase 多应用类型部署的基础。
在接入 SDP、Alpaca，甚至未来更多的部署能力时，我们是如何确保整体架构的 可维护性 与 可扩展性的呢？
首先我们为部署能力，定义了一个统一的适配器抽象， 称其为 DeployProvider。在其上定义了公共的抽象方法。
在对接具体的应用类型时，适配器需要实现这个接口, 如静态 Web 类型，在实现时，会调用 sdpRpc 方法实现具体发布逻辑。 容器类型，在实现时，会调用 alpacaRpc 方法实现具体的发布逻辑。
有了这一层抽象和实现后，我们就可以为不同的应用类型部署，提供统一的 Service 和 Controller 接口。在接口内部，我们根据应用类型，选择对应的适配器做发布。
我再通过一个示意图来复述下:
- 在 Node 服务层的后端，抽象出了 DeployProvider 接口
- 针对不同的应用类型，实现适配器
- 对前端我们可以暴露，统一的部署方法。
- 通过这个方式，我们解决了不同应用类型的 部署能力实现差异的问题。
- 并且在未来，新增部署类型时，我们只需以插件的方式新增一个 xProvider，就可以引入该部署能力。
三. Febase 的流程管控设计
- 在 Febase 中，我们希望能规范应用的上线步骤，规避多人开发场景下的分支冲突。
- 同时我们也需要为不同应用类型，提供上线步骤的定制能力。
为此我们在 Febase 中引入了 发布流程 的概念。
一个发布分支，需要走完 「开发」、「卡点」、「上线」等阶段的验证才能被合并入主干。
在引入发布流程时，我们首先要解决的是流程如何管理的问题:
- 每个流程需要以一定的方式定义，并被计算机程序读取。
- 流程当前所处的节点，需要被持久化存储。
- 流程可以以 串行、并行 的方式 向前推进、也可以回退到前置的节点。
为了完成上述对流程的管理，最朴素的方式是，我们可以选择在业务代码中，手动处理流程状态，但是随着 业务复杂度 的提升，流程状态的管理 与 业务逻辑 相耦合，将会使得项目变得难以维护 和 扩展。
为了简化对流程的管理。业界沉淀了一套流程状态管理工具称为「流程引擎」。这套工具就好像前端的视图层框架，我们只需要专注于业务逻辑的编写，DOM 的操作更新就交由框架来处理。大大降低前端开发的复杂度，提升项目的可维护性。
在计划引入「流程引擎」时，我们调研了市面上==的开源产==品，最终选择了自研「流程引擎」，我们的「流程引擎」除了满足常规的流程状态管理外，还有以下几点特色:
- JS 生态，对前端开发者友好。
- 提供前端套件，流程状态管理可驱动前端视图变更。
- 覆盖常见的编排需求，整体复杂度可控，最适合 Febase。
我们来看下自研的「流程引擎」 在 Febase 中的具体使用吧。
在 packages/server/app/workflow/definition 目录中，会定义不同应用类型的流程
└── definition
├── caas-0.0.1
│ ├── fn
│ └── index.ts
├── graphql-0.0.1
│ ├── fn
│ └── index.ts
├── graphql-0.0.2
│ ├── fn
│ └── index.ts
├── node-0.0.1
│ ├── fn
│ └── index.ts
├── node-0.0.2
│ ├── fn
│ └── index.ts
├── react-native-0.0.1
│ ├── fn
│ └── index.ts
├── react-native-0.0.2
│ ├── fn
│ └── index.ts
├── web-0.0.1
│ ├── fn
│ └── index.ts
└── web-0.0.2
├── fn
└── index.ts
打开 web-0.0.2/index.ts
endpoint 指明在流程推进到该节点时需要执行的函数。我们可以在该函数中执行该节点初始化对应的业务逻辑 并根据业务逻辑执行结果 返回相应的 节点流程状态。
以 review 节点为例，在节点初始化时...
我们再来看 complete 节点...
不同应用类型的流程编排和相应的业务处理逻辑，我们是在后端中定义。我们再来看下前端视图部分的映射。
packages/web/src/workflow/definition 中定义不同应用类型的流程视图映射
引擎会为绑定的 Overview 组件 和 节点组件 传入流程状态信息，供渲染使用，并为组件暴露触发流程状态变更的 dispatch 函数，供前端视图层调用。
通过声明式的代码，我们将 流程编排好了 并对视图做了绑定。 在发布详情页，我们只需使用 useWorkflow 方法传入 流程 ID，引擎就会为我们提供出对应的流程组件，并在流程状态变化时，驱动对应节点视图的渲染。
通过自研的流程引擎，我们将 流程状态管理 与 具体的业务逻辑 解耦，并通过 流程引擎 驱动前端视图的变更，以此降低了业务逻辑开发的复杂度，且在未来引入新应用类型时具有良好的扩展性。
四. OpenAPI 网关的设计
Febase 的后端，不仅需要面向 Febase 管理后台前端提供接口。 同时还要向 第三方平台，如 Overmind、低代码平台 还有 CLI 工具，如 Mug 等提供开放接口。 过去我们搭建公技产品时的做法是，面向管理后台前端使用 Cookie 登录认证。 对第三方平台，使用特殊请求头。 通过白名单的方式，来指定开放接口 然后在每个业务逻辑实现中，根据 请求来源，单独地做 权限校验。 过去这种 职责不单一、面向过程式的鉴权方式，将会导致 难以维护 和 扩展，无法承载 Febase 开放平台的全部底层能力的目标。
我们的做法是抽取出了 单独的 OpenAPI 网关层。
在后端的接口中，用声明式的方式，描述接口所需的 最低权限。 在应用启动时，会收集全部的路由+权限声明，并存入数据库中。 并将 路由与权限信息注册至网关。 由于路由与权限信息都做了入库，所以也可以在管理后台中，对接口的权限做配置管理。 对于多消费场景，统一使用 Febase 派发的 用户 Token 进行认证和鉴权。 只有满足权限要求的请求，才会打到 Febase 后端。 这么做的好处是
- 声明式的鉴权配置
- 多消费场景的统一认证机制
- 与 业务逻辑层的职责单一
以此达到架构的可扩展和易维护。
介绍完多个模块的设计实现后，我们再来看下 Febase 的主体架构
介绍完主体的架构后，我们介绍下 Febase 引入 GraphQL 应用类型的步骤。
由于可扩展性的架构设计，Febase 工程引入 GraphQL 部署流程，就像增加一个新插件一样，不会污染已有应用的业务逻辑，也不会增加整体工程的复杂度，使得整体架构保持良好的可维护性。
四.未来展望
介绍未来将 Febase 向集团内推广，我们需要做哪些努力？ 如底层部署的 租户隔离 、 域名定制 等
自动创建 曙光 埋点应用