应用微化架构

前端架构,在过去的这一两年里,发生了很大的变化。

与后端相比,前端以开放、开源、共享而著称。这三个要素,促使前端的发展变得越来越快——完善的基础设施,多样性的前端构架,丰富的生态系统,以及正在快速形成的架构体系。

应用微化架构_第1张图片

以我为例,在过去的这一年里,我们使用了:

  • 微应用化架构,即开发时分离,构建时合并。

  • 前端微服务化架构,即开发时分离,构建独立的架构模式。

  • 整洁架构,即将业务代码独立于框架的架构风格。

  • 微件化架构,即每个业务构架作为独立的组件,融入到项目。

  • ……

最近的最近,在与同事对于过去架构的反思和总结中,我们讨论出了一个新的架构模式:应用微化架构。由于它是一个反向的微应用化架构模式,所以从模式上来说,我们便将名字反向了一下。由于这一种架构模式,实施和设计相当的简单。所以,在进行详细的介绍之前,先了解一下我们遇到的问题。

两个微服务化场景

应对于业务复杂的前端应用而言,我们都有一个共同的痛点是:代码太多,影响开发效率——影响 IDE 的响应,影响到系统的构建。为此,应对于这种情况,我们的第一反应就是,拆分代码库。在我们过去的一些场合里,我们做了相似的决定。

应用微化架构_第2张图片

场景 1:多角色系统的拆分

角色与权限,往往是阻碍前端系统拆分一个难点。不同的角色,不同的权限,可是呢,在后台系统中, 它们确拥有同样的界面,只是受限于权限原因,我们要拆分成多个系统。

在这个系统里,是由一个团队来维护的。为此在这个项目里,于是我们:

  1. Ctrl + C / Ctrl + V 了一下、两下、三下,将它们变成了两个、三个、四个代码库。

  2. 运用软件工程来共享代码——通过 git submodule、npm 包、共用 CSS 等方式

  3. ……

好了,我们成功地拆分成了多个系统。可是呢,当我们收到一个新的业务需求,我们就需要:

  1. 修改公共部分的代码,并在多个项目中更新

  2. 在每个项目中,添加不同权限的代码

于是乎,每次更新的时候,我们都需要一个 Checklist 去一一更新每个代码库。


应用微化架构_第3张图片

场景 2:多应用系统的拆分

在随后的一个系统里,我们遇到的场景也是拆分。

稍有不同的是,系统有多个应用,而每个应用是由不同的团队来维护。这便是一个非常适合于使用微前端的系统。我们采用了微前端中的微应用化方案,来解决这个问题:

  1. 将代码拆分成多个应用,每个应用只在自己的目录编写代码。

  2. 在构建时,合并不同应用目录以变成一个完整的应用。

  3. 通过软件工程的方式,来在多个应用间共享代码。

一切都好,唯一的问题和之前相似:通过软件工程来共享代码仍然有很多坑。

应用微化架构

应用微化架构_第4张图片

应用微化架构,是一种开发时整体,构建时拆分,运行时分离的前端架构模式。即应用微化架构从一份代码中,构建出适用于不同环境的多套目标代码。实现上它是一种:

  • 构建时拆分架构

  • 代码删除架构。笑,以删代码的方式,来形成每个前端应用。

  • 微前端准备式架构。即,随时可以拆分为多个前端应用。

由于它与微应用化的相似性,我们将它与微应用化做一个对比。它与微应用化不同的是,应用微化是在构建时对应用进行拆分,而非在本地模式下对应用拆分。相似的是,它也是基于构建系统的应用拆分方式。

即:微应用化,是一个随时可合并式架构。而应用微化,则是一个随时可拆分式架构

它不仅仅是一个适合于前端的架构模式,也是一适用于后端的架构模式。

适用场景

为了方便后期我的查阅,我还是简单地写个相应架构的电梯演进。

关键因素 描述
对于 想拆解单体前端应用的团队
我们的架构 应用微化
是一个 类微前端架构
它可以 在开发时是单一代码库,构建时拆分应用,运行时多个应用存在
但他不同于 代码库拆分
它的优势是 灵活库高、维护成本低

适用业务场景:

  • 多权限系统的早期阶段。手疼,不废话。

  • 微服务化的迁移时。适用于前后端,手疼,不废话。

如何实现

应用微化架构_第5张图片

前端

以 Angular 框架为例,大致就流程便是:

  1. 准备好适用于不同环境的路由文件(需要配置为路由懒加载)

  2. 编写一个删除代码的脚本,诸如于 rm -rf / blog(笑~)。

  3. 将这些 task 加到 pipeline 上。

后端

相似的,对于 Spring Boot 构建的微服务也是类似的。

最近,代码敲多了,手疼得厉害,就先不写 DEMO 了——以后补上。

你可能感兴趣的:(应用微化架构)