后端将项目拆分，各个模块各自单独开发，并且根据其访问情况，单独部署不同的机器、容器数量。这样的模块拆分，后端项目向微服务架构演进，各个模块有各自的路由，它们之间内部会通过http、rpc或者kafka进行通信。每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。将一个完整的应用分解为小的、互相连接的微服务,每个服务完成特定的功能, 并且某些特定的服务还能为其他服务提供API接口，使得自动化CI(持续集成)/CD(持续交付)成为可能。
微前端类似于微服务架构, 主要面向于浏览器端，能将一个复杂而庞大的单体应用拆分为多个功能模块清晰且独立的子应用,且共同服于务同一个主应用。各个子应用可以独立运行、独立开发和独立部署。
微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用( Frontend Monolith )后，随之而来的应用不可维护的问题。
区别：微前端主要目的是聚合,即将不同子系统聚合成一个大系统,而微服务架构目前更多是解耦,即解耦不同服务间的依赖.
微前端价值：
技术栈无关：主框架不限制接入应用的技术栈，子应用具备完全自主权
独立开发、独立部署：子应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
独立运行时：每个子应用之间状态隔离，运行时状态不共享
微前端架构解决方案大概分为两类场景：
单实例：即同一时刻，只有一个子应用被展示，子应用具备一个完整的应用生命周期。通常基于 url 的变化来做子应用的切换。
多实例：同一时刻可展示多个子应用。通常使用 Web Components 方案来做子应用封装，子应用更像是一个业务组件而不是应用。
着重介绍单实例场景下的微前端架构实践方案（基于 single-spa），因为这个场景更贴近大部分中后台应用。
微前端实现：
1、MPA 方案的优点在于 部署简单、各应用之间硬隔离，天生具备技术栈无关、独立开发、独立部署的特性。缺点则也很明显，应用之间切换会造成浏览器重刷，由于产品域名之间相互跳转，流程体验上会存在断点。
2、SPA 则天生具备体验上的优势，应用直接无刷新切换，能极大的保证多产品之间流程操作串联时的流程性。缺点则在于各应用技术栈之间是强耦合的。