微前端的出现的背景和意义

微前端是什么

微前端是一种类似于微服务的架构，是一种由独立交付的多个前端应用组成整体的架构风格，将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的应用，而在用户看来仍然是内聚的单个产品。

微前端诞生在两个大的背景下，在提倡拥抱变化的前端社区可以看到新的框架、技术、概念层出不穷，并且随着 Web 标准的演进，前端应用已经具备更好的性能、更快的开发效率。但随着而来的是应用的复杂程度更高、涉及的团队规模更广、更高的性能要求，应用复杂度已经成为阻塞业务发展的重要瓶颈。

微前端就是诞生于 Web 应用日益复杂化的场景中，因为随着网络速度、计算机硬件水平的提升和 Web 标准的演进，过去 Web 应用用户体验远不如传统的应用软件时代已逐渐远去，两者之间在用户体验上的差距不断缩减，并且由于 Web 应用开发速度快、用完即走等特性，导致的一个最终结果就是「能用 Web 技术实现的应用，最终都会通过 Web 来实现」。在近几年涌现了一大批之前只能在传统 PC 软件中才能看到的优秀产品，例如：Photoshop、Web Office、Web IDE。尽管随着 Web 标准的演进，前端工程化也在不断演变，从模块化到组件化在到现在的工程化，但在面对跨团队大规模开发、跨团队企业级应用协作，现有的分治设计模式仍然显得有心无力。

大规模 Web 应用的困局

尽管 Web 应用的复杂度和参与人数以爆炸式的增长速度，但却没有一种新的架构模式来解决现有的困境，并同时兼顾 DX（developer experience）和 UX（user experience）。

以字节跳动内「研发中台」举例，在研发日常工作中需要使用非常多的研发系统，例如：代码管理、代码构建、域名管理、应用发布、CDN 资源管理、对象存储等。站在整个公司研发的角度考虑，最好的产品形态就是将所有的研发系统都放置同一个产品内，用户是无法感知他在使用不同的产品，对于用户而言就是单个产品不存割裂感，也不需要去学习多个平台，仅仅需要学习和了解字节跳动内的「研发中台」即可

传统 Web 应用的利与弊

这里简单分析一下传统 Web 应用在开发大规模应用和涉及多研发团队协作时遇到的一些困境，以上面案例中的「电商运营平台」举例，对于电商运营而言商品、商家、品牌等都是电商运营平台能力的一部分，而不是独立之间的孤岛。若以传统的前端研发模式进行开发，那么此时有两种项目设计策略：

• 将平台内多个系统放置同一个代码仓库维护 ，采用 SPA（Single-page Application） 单页应用模式
• 将系统分为多个仓库维护，在首页聚合所有平台的入口，采用 MPA（Multi-page Application）多页应用模式

若采用多个系统放置同一个项目内维护：

优势：

• 统一的权限管控、统一的 Open API 开发能力
• 更好的代码复用，基础库复用
• 统一的运营管理能力
• 不同系统可以很好的通信
• SPA 应用特有优势：
• 更好的性能
• 具备局部更新，无缝的用户体验
• 提前预加载用户下一页的内容
  劣势：
• 代码权限管控问题
• 项目构建时间长
• 需求发布相互阻塞
• 代码 commit 混乱、分支混乱
• 技术体系要求统一
• 无法同时灰度多条产品功能
• 代码回滚相互影响
• 错误监控无法细粒度拆分

若采用拆分成多个仓库维护

优势

• 可以以项目维度拆分代码，解决权限管控问题
• 仅构建本项目代码，构建速度快
• 可以使用不同的技术体系
• 不存在同一个仓库维护时的 commit 混乱和分支混乱等问题
• 功能灰度互不影响
  劣势
• 用户在使用时体验割裂，会在不同平台间跳转，无法达到SPA 应用带来的用户体验
• 只能以页面维度拆分，无法拆分至区块部分，只能以业务为维度划分
• 多系统同灰度策略困难
• 公共包基础库重复加载
• 不同系统间不可以直接通信
• 公共部分只能每个系统独立实现，同一运维通知困难
• 产品权限无法进行统一收敛

背景和意义总结

其实可以发现由于 Web 应用在逐步取代传统的 PC 软件时，大规模 Web 应用在面对高复杂度和涉及团队成员广下无法同时保证 DX 和 UX 的困境。传统的分而治之的策略已经无法应对现代 Web 应用的复杂性，因此衍生出了微前端这样一种新的架构模式，与后端微服务相同，它同样是延续了分而治之的设计模式，不过却以全新的方法来实现。