本文概述了微前端，以及如何将遗留用户界面分解为微前端架构。
什么是微前端？
微前端是一种架构方法，它将微服务的概念扩展到 Web 应用程序的前端。在微前端体系结构中，复杂的 Web 应用程序被分解为更小的、可独立部署且可维护的单元，称为微前端。每个微前端负责用户界面的特定部分及其相关功能。
微前端的主要特征和概念包括：
- 独立：微前端是自成一体的，独立开发、测试和部署。这种自主权允许不同的团队以最少的协调处理应用程序的不同部分。
- 与技术无关：每个微前端都可以使用不同的前端技术（例如，Angular，React，Vue.js），只要它们可以集成到父应用程序或Shell应用程序中即可。
- 隔离：微前端在代码和依赖关系方面都是相互隔离的。这种隔离可确保一个微前端中的更改不会影响其他前端。
- 集成：容器或 Shell 应用程序负责集成和编排微前端。它提供了用户界面的整体结构，并处理微前端之间的路由。
- 独立部署：微前端可以独立部署，从而实现持续交付和更快的更新。这降低了回归问题的风险，并加快了发布周期。
- 松散耦合：微前端通过定义良好的 API 和共享协议（如 HTTP）进行通信，从而允许它们松散耦合。这种关注点的分离简化了开发和维护。
- 用户界面组合：容器应用程序通过将微前端组合在一起来组装用户界面。这种组合可以在服务器端（服务器端包含）或客户端（客户端路由）上完成。
- 扩展和性能：微型前端支持应用程序特定部分的水平扩展，有助于优化频繁访问区域的性能。
- 分散式团队：不同的团队或开发团队可以在单独的微前端上工作。这种去中心化对于大型或分布式组织是有利的。
微前端架构在大型、复杂的 Web 应用程序中特别有用，在这些应用程序中，整体式方法可能会导致开发瓶颈、复杂性增加以及维护和扩展应用程序的困难。
通过使用微前端，组织可以在其前端开发过程中实现更大的灵活性、敏捷性和可维护性，从而与软件架构领域微服务的更广泛趋势保持一致。
微前端框架方案
路由转发
路由分发式前端，即通过路由将不同的业务分发到不同的独立前端应用上。通常可以通过HTTP服务器的反向代理来实现，或者通过应用框架自带的路由来解决。当前而言，路由分发式的架构是采用得最多、最容易的“微前端”方案。只是将不同的前端应用拼凑到一起，让它们看起来像一个完整的整体。这种应用缺少了对应用状态的处理，对用户的体验不太友好。
前端微服务化
前端微服务化是微服务架构在前端的实施，每个前端应用都是完全独立（技术栈、部署、构建独立）、自主运行的，最后通过模块化的方式组合出完整的前端应用。
组合式集成：微应用化
微应用化是指，在开发时应用都是以单一、微小应用的形式存在的，而在运行时，则通过构建系统合并这些应用，并组合成一个新的应用。
纯前端改造，体验良好，可无感知切换，子应用相互隔离。
需要设计和开发，有父子应用处于同一页面运行，需要解决子应用的样式冲突、变量对象污染，通信机制等技术点
微件化
微件化是指每个业务团队编写自己的业务代码，并将编译好的代码部署到指定的服务器上。在运行时，我们只需要加载相应的业务模块即可。
前端容器：iframe
iframe 可以创建一个全新的独立的宿主环境，类似于沙箱隔离，这意味着我们的前端应用之间可以相互独立运行，仅需要做好应用之间的管理、通信即可。
实现简单，子应用之间自带沙箱，天然隔离，互不影响
iframe的样式现实、兼容性等都具有局限性。
结合Web Components构建
Web Components 是一套不同的技术，允许开发者创建可重用的定制元素（它们的功能封装在代码之外）并且在Web应用中使用它们.
Web Components技术，离项目应用还有些距离。
每个子应用都拥有独立的script和css，也可独立部署。
对历史系统改造成本高，子应用通信较为复杂。
以上6中方案各有优缺点，根据业务等实际情况进行选择。另外，为确保前端体验，不论使用上述那种方案都要完成对应的基座架构框架的搭建。
基座就是用于集成各种业务系统前端的框架，可以包括登录、退出
微前端的业务划分方式
常见的几种划分微前端的方式：
按照业务拆分
按照权限拆分
按照变更的频率拆分
按照组织结构拆分
跟随后端微服务拆分
还要根据业务需求选择以上划分方式。