天下大势，分久必合，合久必分。随着业务的发展，技术栈也因此而越来越难以统一，出现了多样化。在走向多样化后。用户越来越厌倦一家公司的应用软件（APP）分散在多个不同的应用上。应用的获客成本越来越高，应用又一次走向聚合。 在分离了前后端之后，拆分降低了系统的复杂度，并进一步提高了软件的开发效率，随着业务的不断扩张，应用又开始变得臃肿。既然应用变大了，我们就继续往下拆分，拆分成更小的单位。来解决复杂的前端应用。
#一、什么是微前端
微前端是一种类似于微服务的架构，它将微服务的理念用于浏览器端。即将单页面前端应用由单一的单位体应用转变为把多个小型前端应用聚合为一个应用。各个前端应用还可以独立开发、独立部署。
#二、微前端的技术拆分方式
从技术实践上，微前端架构可以采用以下几种方式进行：
- （1）路由分发式。通过HTTP服务器的反向代理功能，将请求路由到对应的应用上。
- （2）前端微服务化。在不同的架构之上设计通信和加载机制，以在一个页面内加载对应的应用。
- （3）微应用。通过软件工程的方式，在部署构建环境中，把多个独立的应用组合成一个单体应用。
- （4）微件化。开发一个新的构建系统，将部分业务功能构建成一个独立的chunk代码，使用时只需要远程加载即可。
- （5）前端容器化。将iframe 作为容器来容纳其他前端应用。
- （6）应用插件化。借助于Web Components技术，来构建跨框架的前端应用。 实施方式虽然多，但都是依据场景面而采用的。在有些场景下，可能没有合适的方式，在有些场景下，则可以同时使用多种方案。
#三、微前端的业务划分方式
与微服务类似，要划分不同的前端边界不是一件容易的事。就当前面言，以下几咱方式是常见的划分微前端的方式：
- 按照业务拆分。
- 按照权限拆分。
- 按照变更的频率拆分。
- 按照组织结构拆分。
- 跟随后端微服务划分。 因为每个项目都有自己特殊的背景，所以切分微前端的方式就不一样。即使项目的类型相似，也存在一些细微的差异。
#四、微前端的架构模式
从微前端应用间的关系来看分为两种：基座模式（管理式）、自组织式，分别对应两种不同的架构模式：
- 基座模式：通过一个主应用来管理其它应用。设计难度小、方便实践，但是通用度低。
- 自组织模式。应用之间是平等的，不存在相互管理的模式，设计难度大，不方便实施，但是通用度高。
就当前而言，基座模式实施起来比较方便，方案上也是蛮多的。 不论那种方式，都需要提供一个查找应用的机制。在微前端中称为服务的注册表模式。和微服务架构相似，不论哪种微前端试，都需要有一个应用注册表的服务，它可以一个固定值的配置文件，如JSON文件，或者是一个可动态更新的配置，又或者是一种动态的服务。它主要做以下一些事情：
- 应用发现。让主应用可以寻找到其它应用。
- 应用注册。即提供新的微前端应用，向应用注册表注册的功能。
- 第三方应用注册。即让第三方应用接入系统中。
- 访问权限等想着设置。
应用在部署的时候，可能在注册表服务中注册。如果基于注册表来管理应用。那么使用基座模式来开发就比较方便。
