本文已参与「 新人创作礼 」活动，一起开启掘金创作之路
什么是微前端等
“微前端架构”是一种使用微服务模式构建前端应用的方法。
微前端的理念是将你的前端拆分为一组可独立部署、松散耦合的应用。然后将这些应用组装在一起以创建面向用户的单个应用程序。
1、微前端究竟是什么？
“微前端架构”是一种使用微服务模式构建前端应用的方法。
微前端的理念是将你的前端拆分为一组可独立部署、松散耦合的应用。然后将这些应用组装在一起以创建面向用户的单个应用程序。
实现微前端有很多技术方法（详见下方链接），不同的企业有不同的对策；从服务端转换（听起来很奇特，但它基本等同于古老 php 的 include 语句，可以跨越应用程序障碍）到 iframe 和 JavaScript 元框架和 Web 组件等都是可选的微前端方案。
2、好处：组织灵活性和一致性
微前端的支持者强调它能像微服务那样减少团队间的依赖，提升组织灵活度。微前端的其他好处有：
独立部署不同的服务实现自治团队，具备独立迭代和创新的能力能够围绕业务部门或产品来打造团队这些都是很有价值的优势，对于大型和复杂的项目尤其明显；但即使是较小的应用程序项目也可以受益于独立部署等微前端特性。
当我在 2010 年开始开发电子商务应用（那时微服务还没出现）时，我一直担心无关变量以某种方式破坏结账流程。我们建立了覆盖广泛的测试框架来预防这种情况，但回想起来，这种场景正是独立服务 + 微前端大显身手的好去处。
3、不足：操作复杂性
我们现在不仅要编辑静态文件，还要完成诸如构建复杂系统、转换和大型框架等任务，所以想要实现正常运行的前端环境需要一系列复杂的工作。微前端让前端环境变得更加复杂了。如今在整个应用中进行任何类型的测试都可能需要多个前端协作，更不用说将这些前端组装在一起所需要的各种工具了。
经历微服务的开发者会很熟悉下面这些挑战：
需要在开发中运行许多不同的应用来测试完整的应用体验跟踪和调试整个系统的问题应付整个系统的版本控制任务本质上来说，我们是在用整个系统的复杂度代价换取单个前端的简洁度。
现状：
目前只要有一点规模的公司，都要去做微前端，一般模块之间的依赖性还是非常之多。微前端能够很好地把项目进行结合起来。
我个人的看法是，对于一个有一定规模的开发团队：20人+
15%比例的，基础架构团队。
大约也就3个人：可以去承当50%的基础架构工作，50%沉淀到各个业务线充当救火员的角色。这类一般都是高潜 & 资深开发去当任。
微前端做之前一定要做好技术前端的基础架构，否则再好的微前端，都是为了微而微。这样就有点缺乏初心。
一般新业务不太适合，因为业务为主，老业务在做之前，一点要把业务 & 基础架构的抽象提取出来。
而目前乾坤虽然很香，但是真正把他维护非常好的公司屈指可数。
大部分的微前端框架都是基于乾坤，当然目前微前端发展了好几年，其实都是有比较的成熟方案体系。切莫忘记初心。
