微前端架构：优势，缺点和痛点
一. 什么是微前端
“微前端架构”就是构建基于微服务的前端应用架构。
其思想是将前端应用切分为一系列可以单独部署的松耦合的应用，然后将这些应用组装起来创建单个面向用户的应用程序。
微前端的实现各不相同，因为不同的公司的技术方案不同，从服务器端页面嵌入到iframes到Javascript元框架(meta-frameworks)和web components。
二. 微服务的一些优势包括：
微前端架构具备以下几个核心价值：
技术栈无关：主框架不限制接入应用的技术栈，子应用具备完全自主权
独立开发、独立部署：子应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
独立运行时：每个子应用之间状态隔离，运行时状态不共享，进行迭代和更新不互相影响。
这些都是实实在在的优点，尤其是对于大型和复杂的项目，但是小的应用程序也能够从独立发布带来一些收益。
三. 缺点：操作复杂
随着我们从编辑静态文件到复杂的构建系统，移植（transpilation）和大型框架，获得功能良好的前端环境的复杂性已经大大增加。微前端进一步加剧了这种趋势，现在在整个应用程序中进行任何类型的测试可能都需要多个协调的前端，更不用说使用什么工具将他们融合在一起了。
微前端老手可能会遇到的挑战：
需要在开发中运行许多不同的应用程序以测试完成的体验
跟踪和调试问题需要跨全部系统
跨系统进行版本控制
本质上讲，是通过前端的简单性换取整个系统（前端/后端）的复杂性。
四. 痛点： 性能，不连贯的体验
在twitter上有许多对于微前端的揶揄
微前端有一些非常糟糕的问题：
每个团队都有自己的选择，浏览器最终可能会下载多个框架和重复的代码
用户不会单独体验你的公司网站或者产品。这也是反对对组件进行完全范围界定的论点之一 ——— 对于完全分离的团队这个问题可能更严重。
微前端的某些实现（尤其是嵌入iframe的实现）可能会带来巨大的可访问性的挑战
虽然拥护者会辩称这些事情不一定要发生，但这种情况似乎确实使我们更有可能看到这些问题。
五. 折中方案： 微前端使用的范围
是利还是弊取决于你和你的环境因素。对于规模较小，位于同一地点的团队和相对简单的产品而言，微前端的好处相对于弊端而言是很小的，而对于大型多面的产品和多个分布式团队而言，好处可能会超过挑战。
还有很多方法在消除不利影响的情况下获取许多好处
通过坚持选择单一的框架，并利用诸如single-spa.js之类的协调框架，您可以通过共享资源和仅下载一次公共代码来减轻很多性能损失。
使用共享的组件库，也可以消除许多用户体验不一致的问题。
当然，在每个步骤中都会放弃一些独立性。在某些时候，就根本不再是微前端架构。在这个范围内那个确切的对你有意义的点在哪里，取决于你的产品和代码组织。
