一、什么是微前端

微前端是由ThoughtWorks 2016年提出，将后端微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还可以 独立开发、独立部署，再将这些小型应用融合为一个完整的应用，或者将原本运行已久、没有关联的几个应用融合为一个应用。微前端既可以将多个项目融合为一，又可以减少项目之 间的耦合，提升项目扩展性，相比一整块的前端仓库，微前端架构下的前端仓库倾向于更小更灵活。

二、为什么需要微前端

举一个具体的例子：

众所周知的美团，几万人规模的大型互联网公司。这个体量的互联网企业，对应的 HR 系统是及其复杂的。据美团技术团队公布美团HR系统是由30多个前端应用，包含1000多个页面，300多个导航菜单项。 想想，如果不把这些应用聚合在一起进行维护使用，那是怎样的一场噩梦。

那么可预见的使用微前端构建类单页应用能带来的好处：

• 解决了随着项目迭代应用越来越庞大，难以维护的问题。【职责单一、应用自治/独立开发/独立部署/增量升级、技术栈无关】
• 解决了跨团队或跨部门协作开发项目导致效率低下的问题。

三、相关的实践方案

从技术实践上，《前端架构从入门到微前端》一书中，将微前端的实施分为六种：

1. 路由分发式：通过 HTTP 服务器的反向代理功能，将请求路由到对应的应用上。
2. 前端微服务化：在不同的框架之上设计通信和加载机制，以在一个页面内加载对应的应用。
3. 微应用：通过软件工程的方式，在部署构建环境中，把多个独立的应用组合成一个单体应用。
4. 微件化：开发一个新的构建系统，将部分业务功能构建成一个独立的 chunk 代码，使用时只需要远程加载即可。
5. 前端容器化：将 iframe 作为容器来容纳其他前端应用。
6. 应用组件化：借助于 Web Components 技术，来构建跨框架的前端应用。

实施的方案虽然很多，但都是依据场景而采用的。毕竟适合当下场景的框架，才是一个好框架。

• 相关对比：

  方案	开发成本	维护成本	可行性	同一框架要求	实现难度	潜在风险	落地实践
  路由分发式	低	低	高	否	简单	无	http 服务器反向代理，如 nginx 配置 location
  前端微服务化	高	低	中	否	困难	共享及隔离粒度不统一	single-spa、qiankun、icestark、mooa等
  微应用	中	中	高	是	正常	多个项目组合，考虑各个部署升级情况	emp
  微件化	高	中	低	是	困难	实现微件管理机制	无
  前端容器化	低	低	高	否	简单	seo不友好、cookie管理、通信机制、刷新后退、安全问题	前后端不分离项目常用
  应用组件化	高	低	高	否	正常	新api,浏览器兼容性	无

  对于微前端方案的选择应该从现有资源及历史积淀中去选择上述一种或几种方案的组合，从不同维度（比如：共享能力、隔离机制、数据方案、路由鉴权等）去考虑，实现工程的平滑迁移， 从而实现架构的迭代升级逐步重构，切忌为了架构而架构，不要无谓的炫技，任何技术都是合适的才是最好的，大巧不工，重剑无锋！