微前端理论和实操微前端理论和实操
微前端如何落地？只听过“微服务”，“微前端”又是什么硬核技术？
它正是借鉴微服务的概念来应用在前端上，将一个巨大的前端工程拆分成一个的小工程，这些小工程具备独立的开发和运行能
力，而整个系统就由这些小工程协同合作。
这个理念很好，可在实际开发中，又该如何落地？如何拆分呢？涉及何种技术？在本文中，作者将从浅入深，逐步为大家讲
解。
随着 Martin Fowler 博客上，那篇 Cam Jackson 写的微前端的文章发布，到处都在讨论 Microfrontend。作为一个微前端 “专
家”，我也分享一下：如何去落地微前端。
微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将单页面前端应用由单一的单体应用转变为多个小
型前端应用聚合为一的应用。各个前端应用还可以独立开发、独立部署。同时，它们也可以在共享组件的同时进行并行开发
——这些组件可以通过 NPM 或者 Git Tag、Git Submodule 来管理。
为什么需要微前端？
微前端不是银弹，它和微服务一样会带来大量的挑战。
遗留系统迁移。解决遗留系统，才是人们采用微前端方案最重要的原因。聚合前端应用。微服务架构，可以解耦后端服务间依
赖。而微前端，则关注于聚合前端应用。热闹驱动开发。新的技术，既然很热闹，那么就学吧。微前端的实现，意味着对前端
应用的拆分。拆分应用的目的，并不只是为了架构上好看，还为了提升开发效率。
为此，微前端带来这么一系列的好处：
应用自治。只需要遵循统一的接口规范或者框架，以便于系统集成到一起，相互之间是不存在依赖关系的。单一职责。每个前
端应用可以只关注于自己所需要完成的功能。技术栈无关。你可以使用 Angular 的同时，又可以使用 React 和 Vue。除此，
它也有一系列的缺点：
应用的拆分基础依赖于基础设施的构建，一旦大量应用依赖于同一基础设施，那么维护变成了一个挑战。拆分的粒度越小，便
意味着架构变得复杂、维护成本变高。技术栈一旦多样化，便意味着技术栈混乱。毕竟没有银弹。
如何设计微前端架构？
就当前而言，要设计出一个微前端应用不是一件容易的事——还没有最佳实践。在不同的落地案例里，使用的都是不同的方
案。出现这种情况的主要原因是，每个项目所面临的情况、所使用的技术都不尽相同。为此，我们需要了解一些基础的微前端
模式。
架构模式
微前端应用间的关系来看，分为两种：基座模式（管理式）、自组织式。分别也对应了两者不同的架构模式：
基座模式。通过一个主应用，来管理其它应用。设计难度小，方便实践，但是通用度低。自组织模式。应用之间是平等的，不
存在相互管理的模式。设计难度大，不方便实施，但是通用度高。就当前而言，基座模式实施起来比较方便，方案上便也是蛮
多的。
资源评论
