8、架构：服务端介绍

news2024/11/23 21:10:27

作为一个产品化的项目，就必然有服务端的支持，这次的项目我们依然使用与上一本小册一样的技术栈 NestJS作为产品的服务端开发语言。

服务端的内容对于常规的前端开发会比较难上手，因为除了服务端的开发语言之外，我们还需要安装各种各样的中间件来完成我们的需求，比如数据库、Redis、以及其他日志、监控等等的额外内容，所以如果团队内部以及有服务端的同学支持，可以只看服务端的一些架构相关内容，具体的代码实现可以暂时忽略。对于工程中所使用的环境以及中间件配置，这里依然再次推荐和耳朵写的一篇介绍文章，总体内容非常全面，需要的同学可以点击查看【环境与中间件配置】，还有其他的环境问题的话，可以留言或者加群沟通一起解决。

由于整个项目比较庞大，涉及的内容与模块也非常多，一个人很难维护所有的内容，所以这里需要将这样一个巨大的服务拆解为一个个子应用，然后以微服务的模式再集成为一个完成的项目，这样可以减少各个模块之间的强依赖性且方便各个模块的独立开发与构建。

在正式开发服务端项目之前，将拆分出来的各个微服务应用进行简单的介绍以方便大家理解它们的功能。

Auth & User

用户与权限系统，我们将基于 RBAC 权限管理模型开发一个独立的系统来管理后续所有系统的用户与权限，减少每个系统都需要重复开发权限的功能。

什么是 RBAC 模型

RBAC（Role-Based Access Control） 的三要素即用户、角色与权限。用户通过赋予的角色，执行角色所拥有的权限。

RBAC 引入之后用户的流程如上图所示，用户在进入系统之后，会先进行角色判断，再根据对应的角色查询所匹配的权限，最后根据返回结果来判断是否可执行。

由于 RBAC 权限管理系统在上一本小册中进行了详细的介绍，这里就不过多阐述概念性的内容，这期小册的用户权限系统会基于之前的项目延续开发，减少研发成本，采用的数据库结构如下所示：

Materials

整个搭建体系中比较核心的服务就是物料资产管理，作为搭建服务的基础，需要针对每个搭建的原子物料的产物进行统一管理，包括版本、安全以及配套的开发提效的一些功能。

与之前网关小册中介绍的物料服务不同的是，在新的搭建体系中的物料服务保存的物料类型只有下述几种:

基础组件
物料组件
区块
模板

主要是去除了页面类型，因为页面是一种直面用户的产物结果，也不具备原子性与复用性，所以就不再归属于物料系统里面管理，而是将搭建产物放在搭建服务中进行统一的管理。

上图是物料服务的数据库表结构展示，避免有些同学不理解所以这里再次解释一下：

在我们的物料管理类型中分为虚拟物料与实体物料，分别对应的是开发物料的代码仓库管理模式采用的 monorepo 跟 multirepo。

对于上述两种代码仓库管理模式各有千秋，常规的物料系统一般都是采用 multirepo 管理产物，这样方便工程的构建与管理产物的版本。对于业务组件库这种本身就有领域壁垒的类型产物，以 multirepo 的模式来管理非常方便，也能够让大部分的开发所接受，但这都不是绝对的，具体也要看自己的习惯以及团队的模式。

对于基础组件库来说，开发使用 monorepo 模式来管理代码肯定是最为方便的，因为基础组件库本身有不少的逻辑与基础能力可以复用，所有的依赖都是聚合在一个仓库，方便即时修改与同步。

但这种模式对于物料管理系统来说就没有那么友好了，monorepo 的构建产物不具备唯一性，同时每次的构建产物结果可能存在多个，产物的结果无论是新增还是删除都无法被物料系统所感知，鉴于这种情况才引入虚拟物料的概念，在构建后将产物结果手动同步给物料系统，也可以通过前端界面来手动维护版本管理。

在 NestJS 的小册中，由于并没有实际的场景对应，所以仍有部分同学有困惑，那么在接下来的搭建体系中会对这个概念有更好的理解。

DevOps

Materials 系统只会管理搭建所需要的物料，虽然会关注物料的产物但不会关注搭建产物的构建与发布，而将搭建产物的 CI/CD 过程放在物料系统中显然不合适，但两者又有非常多的重复功能可以复用，所以在此之上重新抽离一套专注于前端资源的 DevOps 项目，作为搭建服务与物料服务的底层 CI/CD 模块，此模块只负责通用性的 CI/CD 过程，不具备业务属性，不同的属性将在物料与搭建服务中进行开发。

所以 DevOps 模块的表结构也会比较简单，仅仅只保留了构建相关的表，与 Materials 系统共用 Projct 表。

一个完整的 DevOps 服务涉及的内容也是非常多的，除了 CI/CD 之外还会包含项目管理、质量监控等等模块，但对于低代码这个产品体系中，我们仅聚焦开发 CI/CD 构建的模块，用于我们搭建中需要的物料以及搭建后的产物的构建与发布，所以不会有非常多重量级的开发任务，如果想了解更多 DevOps 的同学，可以参考我之前的工程化专栏相关的系列文章或者 DevOps 小册。