起源
最近在做一个基于Web的商业应用。客户希望这个应用在架构上能满足以下需求：
1) 尽量简单满足最初上线的基本功能与性能高求；
2)具有良好的可扩展性。可以兼容现有服务并方便后期引入新的技术；
3)所采用架构及其后期evolve需尽量减少后期维修成本。
架构师的工作内容除了沟通之外主要是权衡(trade-off)。就是对各种架构进行评估和尝试最后选择一个相对更可行的架构方案。
微服务架构设计思想主要应用在后端系统的设计并很好地应用在很多商业场景。然而随着前端组件在基于browser的应用越来越复杂和沉重，有些公司开始将微服务的技术思想应用到浏览器端。即：Micro frontends【1】。
什么是微前端
简单地说微前端的思路是将Web应用切分成多少独立的微前端应用。每个微前端应用拥有独立的前端、后端及数据库组件。并独立开发、部署、运行与维护。以下是微前端架构与其它架构的对比：
应用场景
每种技术与设计思想都是为了解决某类实际问题。微前端的架构与技术适用于以下应用场景：
1). 遗留系统的兼容与迁移：
技术的发展日新月异。采用更好更优秀的技术支持业务是很多公司提高竞争力的手段。大多数拥有已上线运营的软业系统的商业公司的开发团队面临的一个实际问题是： 如何在兼容现有系统的情况下采用更新更优秀的技术与框架开发新的功能。使用微前端是一个不错的选择。
2). 应用聚合
大多数公司内部都部署了各种软件应用提供各种内部与外部服务。如果能将这些软件应用聚合成一个可以提供统一用戶体验的应用将会提高员工的工作效率及客户的体验。采用微前端是一个不错的选择。
3).单一职责与应用自治
由于每个微前端应用都是独立的开发与部署并且各应用之间通过统一的接口规范与框架聚合在一起。这既可提高开发团队的专注水平又保证各团队之间的协作。比如：亚马逊内部就提倡：" you make it you own it"。
架构模式
微前端应用可采用以下两种架构模式：
1) 管理式模式
2)自组织式模式
划分方式
微前端应用边界可按以下方式划分：
1) 按业务划分
2) 按组织结构划分
3) 按权限划分
4) 按变更频率划分
5) 按服务划分
实现方式
1) 路由分发式
即通过反向代理或路由组件将服务请求分发到不同的独立前端应用上。
2)微应用集成式
即先根据微应用边界划分后独立开发及步骤一系列独立的微应用。然后再集成到一个新的应用上。
3)微组件运行时集成
指将业务服务分解并编译成可以在集成应用上直接可运行的组件并保存与维护在相应的组件仓库中。集成页面在运行时直接加载和调用相应的组成提供相应的服务。
4)建立基于微容器的前端架构
感觉这个思路和微软的Sharepoint的Web Part及java的portlet的思路相近。即将微应用以微组件的形式存在。应用通过微容器在集成应用运行时对微组件进管理。目前可使用的方法有：使用 iFrame 创建容器、使用Web Components技术等。
几种微前端框架
1) single-spa
2) stencil
3) mooa
4) single-spa-angular
5) single-spa-angular-cli
其中single-spa-angular|-cli是single-spa-angular的旧版本。已不再维护。
1. https://www.thoughtworks.com/radar/techniques/micro-frontends
