应用微化架构：前端构建时拆分

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

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

以我为例，在过去的这一年里，我使用了：

• 微应用化架构，即开发时分离，构建时合并。
• 前端微服务化架构，即开发时分离，构建独立的架构模式。
• 整洁架构，即将业务代码独立于框架的架构风格。
• 微件化架构，即每个业务构架作为独立的组件，融入到项目。
• ……

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

两个微服务化场景

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

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

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

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

1. Ctrl + C / Ctrl + V 了一下、两下、三下，将它们变成了两个、三个、四个代码库。
2. 运用软件工程来共享代码——通过 git submodule、npm 包、共用 CSS 等方式
3. ……

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

1. 修改公共部分的代码，并在多个项目中更新
2. 在每个项目中，添加不同权限的代码

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

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

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

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

1. 将代码拆分成多个应用，每个应用 只在自己的目录 编写代码。
2. 在构建时，合并不同应用目录以变成一个完整的应用。
3. 通过软件工程的方式，来在多个应用间共享代码。

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

应用微化架构

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

• 构建时拆分架构 。
• 代码删除架构 。笑，以删代码的方式，来形成每个前端应用。
• 微前端准备式架构 。即，随时可以拆分为多个前端应用。

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

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

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

适用场景

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

适用业务场景：

• 多权限系统的早期阶段 。手疼，不废话。
• 微服务化的迁移时 。适用于前后端，手疼，不废话。

如何实现

前端

以 Angular 框架为例，大致就流程便是：

rm -rf / blog
task

后端

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

最近，手疼得厉害，就先不写 DEMO 了——过几天补上。