微前端应用

微前端会为我们带来很多好处：

复杂度可控: 每一个UI业务模块由独立的前端团队开发,避免代码巨无霸,保持开发时的高速编译,保持较低的复杂度,便于维护与开发效率。
独立部署: 每一个模块可单独部署,颗粒度可小到单个组件的UI独立部署,不对其他模块有任何影响。
技术选型灵活: 也是最具吸引力的,在同一项目下可以使用如今市面上所有前端技术栈,也包括未来的前端技术栈。
容错: 单个模块发生错误,不影响全局。
扩展: 每一个服务可以独立横向扩展以满足业务伸缩性，与资源的不必要消耗。
从上面不难看出微前端能够带来的一些好处：独立开发、独立部署、各个系统自治、单一职责、技术栈无关，甚至于能够解决遗留系统的迁移。防止一个普通应用演变为一个不可维护的巨石应用。

需要明确得是微前端不是框架、不是工具/库，而是一套架构体系，它包括若干库、工具、中心化治理平台以及相关配套设施，主要包括已下3部分：

微前端的基础设施。这是目前讨论得最多的，一个微应用如何通过一个组件基座加载进来、脚手架工具、怎么单独构建和部署、怎么联调。
微前端配置中心：标准化的配置文件格式，支持灰度、回滚、红蓝、A/B 等发布策略。
微前端的可观察性工具：对于任何分布式特点的架构，线上/线下治理都很重要。
那微前端就是一把万能的钥匙吗？很明显不是的，作为类似微服务的一种架构，它同样拥有微服务所带来的一系列问题，比如服务拆分的粒度、基础设施引入所带来的维护问题等等。

解决方案
在这里采用FE萝卜头的对比角度对方案进行分类：硬/软隔离。服务端路由分发与 iFrame 是典型的基于浏览器的硬隔离方案，其天然支持多技术栈、多源的灵活组合，不过其在应用协调与治理方面需要投入较大的精力。软隔离更多地依赖于应用框架或者开发构建流程，来实现容错与样式、DOM 等隔离。

浏览器硬隔离
路由分发式
通过路由将不同的业务分发到不同的、独立前端应用上。其通常可以通过 HTTP 服务器的反向代理（比如Nginx）来实现，又或者是应用框架自带的路由来解决。

这种方式实现起来非常简单，并且也能够做到独立开发、独立部署，但这更像是多个前端应用的聚合，我们只是将这些不同的前端应用拼凑到一起，使他们看起来像是一个完整的整体。