一、微前端的架构模式

从微前端应用间的关系来看分为两种： 基座模式（管理式）、自组织式，分别对应两种不同的架构模式：

• 基座模式。通过一个主应用来管理其他应用，设计难度小、方便实践，但是通用度低。
• 自组织模式。应用之间是平等的，不存在相互管理的模式，设计难度大，不方便实施，但是通用度高。

不论哪种方式，都需要提供一个查找应用的机制，在微前端中称为服务的注册表模式。 和微服务架构相似，不论哪种微前端方式，都需要有一个应用注册表的服务，它可以是一个固定值的配置文件， 如 JSON 文件，或者是一个可动态更新的配置，又或者是一种动态的服务。它主要做以下一些事情：

• 应用发现。让主应用可以寻找到其他应用。
• 应用注册。即提供新的微前端应用，向应用注册表注册的功能
• 第三方应用注册。即让第三方应用接入系统中。
• 访问权限等相关配置。

应用在部署的时候，可以在注册表服务中注册。如果基于注册表来管理应用，那么使用基座模式来开发就比较方便。

1.基座模式

在这种模式的微前端架构中，基座承担了微前端应用的基础与技术核心。 基座模式，是由一个主应用和一系列业务子应用构成的系统，并由这个主应用来管理其他子应用， 包括从子应用的生命周期管理到应用间的通信机制。

基座模式中的主应用，类似于 API Gateway 的概念，它作为系统的统一入口，负责荐对应的请求指向对应的服务，子应用，则是负责各个子模块的业务实现， 其架构如下：

这个主应用，既可以只带有单纯的基座功能，也可以带有业务功能。它所处理的业务功能指的是核心部分的业务功能，如：

• 用户的登录、注册管理。
• 系统的统一鉴权管理。
• 导航菜单管理。
• 路由管理。
• 数据管理。
• 通信代理。
• ...

作为应用的基础核心，它还需要：

• 维护应用注册表。在应用注册表上表明系统有多少个服务、能否找到对应的应用等。
• 管理其他子应用。如在何时加载应用、何时卸载应用等。

要实现这种模式的微前端架构，只需要设计好对应的应用加载机制即可，因此在实施的时候也比较方便。

2.自组织模式

自组织指的是，系统内部各子系统之间能自行按照某种规则形成一定的结构或功能。采用这种模式可以使系统内的各种前端应用，都各自 拥有一个小型的基座管理功能，也相当于每个应用都可以是基座。

在采用基座模式时，用户要想访问 A 应用需要先加载主应用，然后才能加载 A 应用。 采用自组织模式时，用户想要访问 A 应用则只访问 A 应用，不需要加载主应用，这也因此使它拥有了更高的自主性。

不过多数时候，不需要自组织模式的微前端架构，因为它设计起来复杂、拥有大量的重复代码。