物料篇-物料系统设计 #

前言 #

上一章介绍了 RBAC 权限模型的设计，后续会将基于 RBAC 的用户中心代码放在 GitHub 上，大家可以进群获取最新的代码进度。

在需求分析中，我们提到了在网关基础服务中需要代理转发静态资源，正常来说这个功能一般是 DevOps 或者搭建系统来完成的，但由于 DevOps 与搭建系统自身就是一个非常庞大的体系，为了专注于网关系统功能不扩散范围，所以我们挑选了一个比较基础的物料服务来进行页面资源的管理。

本章我们将介绍物料的一些相关知识以及物料系统的设计。

物料系统 #

什么是物料? #

物料这个概念也算是一个比较新的名词，有些同学可能没有听说过，但实际上你不仅接触过物料而且已经在使用甚至是开发了。

首先，我们来剖析一个前端的项目构成：应用 -> 页面 -> 区块 -> 业务组件 -> 基础组件。

如果一个成熟的团队会用什么来快速完成整个工程呢？

1. 一套基于团队标准规范的基础组件库，包含 PC 与 H5 甚至多端组件库；
2. 多套符合业务常见的业务组件库，例如电商组件库（购物车、商品库、金刚位、广告位等）；
3. 多种区块组合，例如金刚位与广告位的多种组合模式，需要微调整的模块；
4. 多套模板，例如电商中的各种营销模板（砍一刀、大转盘、抽奖机等）。

上面这些模块在一个稍具规模的团队中，至少具备 1 跟 2 或者更多，只不过不少的团队没有将它们归类并做成一套通用的物料系统而已。

所以物料的概念可以理解为：所有能直接搭建出页面级别的基础模块都可以纳入物料的统筹。

为什么需要物料？ #

前面提到了，一个成熟的团队应该怎样快速完成一个新的工程，以及如何对旧工程进行迭代、优化升级。

当一个团队负责业务越来越多，研发成员逐步增加，项目上下游协作链路越来越长（设计 -> 研发 -> 测试 -> 产品验收），如果每一次新的需求或者新的项目启动的时候，都没有任何开发、样式的规范，也没有任何的资源、组件或者代码的复用率，很容易导致项目迭代、维护困难，业务与样式质量差。最重要的是会有很多重复的工作，造成资源浪费与人工成本增加。

这也是为什么当一个团队的业务逐步稳定之后，就会开始制定设计规范、开发规范，增加代码、组件的复用率，提高个人开发效率。当规范达到一定的标准，相对应也会减少设计、测试的投入，整体的效能也会有所提高。

如何去开启第一步？ #

跟工厂流水线一样，首先从开发语言、脚手架入手，从源头将最基础的地基统一了，才有机会完成后面的规范。不然团队中每个人都根据自己的喜好选择 Vue、React、Angular 或者其他小众一点的框架来开发的话，这个标准的落地就会非常困难。

在完成了基础开发语言与框架的统一之后，就可以联合产品与设计制定相关的基础 UI 级别的规范，产出通用的组件库代码。

最后，再根据自身的业务不断精炼代码，抽取通用逻辑与组件，完成第一批业务组件的积累。

何为组件、区块与模板？ #

基础组件的概念比较好理解，将所有业务剔除，能够保持最小的元素就可以作为基础组件，它是可枚举、可抽象以及通用的，例如常见的 table 以及 form 一套组件。

目前业内做的比较好的 React 技术栈的组件库有 Antd，Vue 技术栈的组件库有 Element 与 iView。个人并不建议每个团队都从头开始造轮子，可以以目前主流成熟的开源组件库为基础做二次开发定制，这也应了小册第一章所说的，并不是所有的轮子都有必要造。

基础组件作为最小单位的构成元素，通用性非常高，覆盖面非常广，但是仍然没办法满足实际业务线快速开发的需求，业务组件也就由此诞生。

业务组件是基于基础组件但附带了业务属性的组件，通常情况下业务组件受垂直业务领域的影响，必然是有领域壁垒的，比如电商组件库与 SCM 组件库就有很大的差距。

无论是业务组件还是基础组件，都属于组件的范畴，最终的产物大多数都是以 Props 这种可配置的传参模式来使用。

区块则是融合了基础与业务组件之后的产物，与组件不同的是，区块是以复制代码的模式直接添加到工程化当中。

当你的业务需要大量的重复模块的代码，这些模块的代码在每一处都会有不同的业务处理方式，无法通过配置来完成所有的功能时，这个时候就需要区块来帮你完成了。

模板可以看作大号区块，但更加成熟，以页面级别为单位，由前三种子模块组装而成，同样也是以代码的模板加入到工程中。

产物管理 #

组件一般都是以配置模式使用，所以通常都需要经过构建才能被工程所引用，常规的组件产物有两种形态：NPM 包与 CDN 资源。这种模式非常利于组件模块快速被工程引入，而且通过构建之后非常方便版本管理。

至于区块与模板，因为已经是纯 Code 的模式，所以发布 NPM 与 CDN 都不太合适，一般是直接使用 Git 仓库源码模式来管理。但是通过仓库源码直接管理的话，依赖引入（需要手动引入或者全局引入一套全组件依赖）与版本管理都会有问题。

此时，就需要借助一个物料系统来帮我们将这些零碎的模块统一管理起来，方便业务同学使用。

物料系统设计 #

基于上述的分析与讨论，最终我们的物料系统需要保存的数据类型有上述几种:

1. 基础组件
2. 物料组件
3. 区块
4. 模板
5. 页面

其中，页面的产物类型是额外附加上去，一般属于搭建系统才会保存的产物类型，但由于我们的网关系统中需要这种产物，所以才会放进来。

在产物管理中提到了，组件与区块、模板在存储方面是有一些区别的，所以在物料体系设计中，需要对这两种类型的产物做一些兼容性的合并。

首先考虑接入物料系统中的代码仓库管理模式采用 monorepo 还是 multirepo。

对于上述两种代码仓库管理模式各有千秋，常规的物料系统一般都是采用 multirepo 管理产物，这样方便数据管理产物的构建与版本。对于业务组件库这种本身就有领域壁垒的类型产物，以 multirepo 的模式来管理非常方便，也能够让大部分的开发所接受。

但是，如果采用 multirepo 来管理基础组件库，对开发来说就非常难受。因为基础组件库本身有不少的逻辑与基础能力可以复用，但 multirepo 模式会把它拆得比较零碎，所以对于基础组件库常见的管理模式是 monorepo。

那么问题来了，multirepo 的管理模式在物料系统中可以有唯一的映射，每一次的项目构建的产物结果都具备唯一性，但是 monorepo 的构建产物不具备唯一性，每次的构建产物结果可能存在多个。

为了解决这个问题，在我们的物料系统中，引入虚拟物料的概念，也就是 monorepo 模式管理的工程，可以手动在系统中申明，在构建环境不再关注构建产物的具体结果，根据构建的版本统一升级所有虚拟物料的版本即可。

下图分别是真实物料与虚拟物料添加的界面，虚拟物料的产物结果是通过人工添加进去管理的，而真实物料则是每一个仓库就对应一个物料。

下图是物料系统一个单仓的管理与发布界面：

对于区块、模板以及页面这种类型的物料，在发布的时候除了版本管理之外，最好也将 Code 内容完整地存在数据库中，这样方便其他的系统消费，例如使用 Snapshot 做成代码插入插件，在 VS Code 中开发时直接消费区块、模板等物料。

写在最后 #

本章介绍了物料的特性以及物料系统该怎么设计，具体的开发细节以及数据表结构设计将会在下一章详细讲述。

在物料系统设计中出现的截图是已经投入使用的完整版本，它包含了 DevOps 与搭建体系，但小册的物料实战并不会展示完整的体系，而是聚焦在物料管理控制这个流程上。有兴趣的同学在跟着完成物料实战之后，可以结合自己公司的 CICD 体系完善起来。

如果你有什么疑问，欢迎在评论区提出或者加群沟通。 👏