微前端架构

在基础实施上，微前端架构与单体应用架构有相当大的区别。在单体应用架构中只有一个共享层，而在微前端架构中则可以存在多个共享层，即有的是应用间共用的共享层，有的是应用间的公用共享层。所以在微前端架构设计初期需要做好如下几件事情：

组件和模式库

在应用之间提供通用的UI组件、共享的业务组件，以及相应的函数功能模块，比如日期转换等。（utils、components）

设计应用间的通信机制，并提供相应的底层库支持。

数据共享机制

对于通用的数据，采取一定的策略来缓存数据，而不是每一个应用单独获取自己的数据。

专用的构建系统

在某些微前端实现中，如微件化，构建系统用于构建出每一个单独的应用，又可以构建出最后的整个应用。

提取组件与模式库

系统内有多个应用采用同一框架的微前端架构，模式库作为微前端架构的核心基础，可以用于共享代码。

在实施的过程中经常会遇见一个头疼的问题： 样式冲突 。如果在一个页面里同时有多个前端应用，那么就会存在以下几种形式的样式：

对于组件级别样式来说，有些框架可以从底层上直接支持组件模式样式隔离，比如 Angular 。当然还可以使用对应的 CSS 样式前缀来保证唯一，只不过在开发的过程中要多注意即可。

对于应用级样式，则需要制定一个统一的规范，可以根据应用名加前缀，如 dashboard- ,也可以根据路由来增加响应的前缀，以确保应用本身的样式不会影响到其他的应用。此外，我们往往会为这些应用，创建一个统一的样式库。以确保一致的用户体验。

对于系统级样式，大抵只存在于基座模式设计的微前端框架里。在这种方案里，有基座应用来控制其他的应用，也存在部分的样式。在编写这些样式的时候，需要注意对其他应用的影响，此外也可以作为统一的样式库承载的应用来使用。

对于多个项目中使用的业务组件库和共享函数，我们既可以提供 NPM 包的方式，也可以提供 GIt submodule 的方式，引入到项目中。

对于业务组件库，在开发的前期我们需要频繁的改动，我们可以将其抽取为 submodule 的方式在项目中使用。因为此种方式当我们需要改动时即可轻松的修改，并在其他的项目中更新使用。当这个组件库趋向于稳定版本时，可以尝试将其作为 NPM 包发布。

此外，对于业务组件以及共享库的修改应当是兼容式修改。即兼容之前代码。若难以兼容之前代码，那么要对项目中使用到的部分进行逐一排查，直到确定已更新到下游API。要还要进行响应部分的测试，以确保组件修改带来的影响都已经修复。