转自掘金原文《微前端到底是什么，能够带来什么收益》
本文将解说微前端诞生的背景，具体讲解微前端概念的原因以及其深刻了解，读完本文，置信你对微前端有一个比拟全面的认知，明确它能够解决您团队以及整个企业什么问题，带来怎么样的收益。
一.背景
当初很多企业，根本在物理上进行了利用代码隔离，履行单个利用单个库，闭环部署更新测试环境、预公布环境和正式环境。于是，咱们的探讨的是，基于不同利用不同库并独立部署的状况下，如何实现多个利用之间的资源共享？
之前比拟多的解决形式是npm包模式抽离和援用，比方多个利用我的项目之间，可能有某业务逻辑模块或者其余是可复用的，便抽离进去以npm包的模式进行治理和应用。但这样却带来了以下几个问题：
- 公布效率低下。如果须要迭代npm包内的逻辑业务，须要先公布npm包之后，再每个应用了该npm包的利用都更新一次npm包版本，再各自构建公布一次，过程繁琐。如果波及到的利用更多的话，破费的人力和精力就更多了。
- 多团队合作容易不标准。蕴含通用模块的npm包作为共享资产，“每个人”领有它，但在实践中，这通常意味着没有人领有它。它很快就会充斥芜杂的格调不统一的代码，没有明确的约定或技术愿景。
这些问题让咱们意识到，扩大前端开发规模以便于多个团队能够同时开发一个大型且简单的产品是一个重要但又辣手的难题。
因而，早在2016年，微前端概念诞生了。
二. 微前端概念
Micro Frontends 官网定义了微前端概念：
Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently.
翻译成中文：
从Micro Frontends 官网能够理解到，微前端概念是从微服务概念扩大而来的，摒弃大型单体形式，将前端整体合成为小而简略的块，这些块能够独立开发、测试和部署，同时依然聚合为一个产品呈现在客户背后。能够了解微前端是一种将多个可独立交付的小型前端利用聚合为一个整体的架构格调。
值得注意的几个点：
- 微前端不是一门具体的技术，而是整合了技术、策略和办法，可能会以脚手架、辅助插件和标准束缚这种生态圈模式展现进去，是一种宏观上的架构。这种架构目前有多种计划，都有利弊之处，但只有实用以后业务场景的就是好计划。
- 微前端并没有技术栈的束缚。每一套微前端计划的设计，都是基于理论需要登程。如果是多团队对立应用了react技术栈，可能对微前端计划的跨技术栈应用并没有要求；如果是多团队同时应用了react和vue技术栈，可能就对微前端的跨技术栈要求比拟高。
三. 微前端的劣势
同步更新
比照了npm包形式抽离，让咱们意识到更新流程和效率的重要性。微前端因为是多个子利用的聚合，如果多个业务利用依赖同一个服务利用的功能模块，只须要更新服务利用，其余业务利用就能够立马更新，从而缩短了更新流程和节约了更新老本。
增量降级
因为历史包袱，有团队仍旧存在应用着古老而宏大的前端单体模式，被过期的技术栈或赶工实现的代码品质死死拖住后腿，其水平重大到了让人想颠覆重写。为了防止齐全重写的危险 ，咱们更加偏向于将旧的应用程序逐渐地翻新，与此同时不受影响地持续为咱们的客户提供新性能。
微前端能使咱们更加自在地对产品的各个局部做出独立的决策，让团队能做到继续地减少新性能并且对原有的整体简直不做批改，使咱们的架构、依赖以及用户体验都可能增量降级。
另外，如果主框架中有一个非兼容性的重要更新，每个微前端能够抉择在适合的时候更新，而不是被迫停止以后的开发并立刻更新。如果咱们想要尝试新的技术，或者是新的交互模式，对整体的影响也会更小。
简略、解耦的代码库
每个独自的微前端我的项目的源代码库会远远小于一个单体前端我的项目的源代码库。这些小的代码库将会更易于开发。更值得一提的是，咱们防止了不相关联的组件之间无心造成的不适当的耦合。通过加强应用程序的边界来缩小这种意外耦合的状况的呈现。
当然了，一个独立的、高级的架构形式（例如微前端），不是用来取代标准整洁的优良老代码的。咱们不是想要回避代码优化和代码品质晋升。相同，咱们加大做出谬误决策的难度，减少正确决策的可能性，从而使咱们进入胜利的陷阱。例如，咱们将跨边界共享域模型变得很艰难，所以开发者不太可能这样做。同样，微前端会促使您明确并谨慎地理解数据和事件如何在应用程序的不同局部之间传递，这本是咱们早就应该开始做的事件！
独立部署
与微服务一样，微前端的独立可部署性是要害。它缩小了部署的范畴，从而升高了相干危险。无论您的前端代码在何处托管，每个微前端都应该有本人的间断交付通道，该通道能够构建、测试并将其始终部署到生产环境中。咱们该当可能在不思考其余代码库或者是通道的状况下来部署每个微服务。做到即便原来的单体我的项目是固定的依照季度手动公布版本，或者其余团队提交了未实现的或者是有问题的代码到他们的主分支上，也不会对以后我的项目产生影响。如果一个微前端我的项目已筹备好投入生产，它应该具备这种能力，而决定权就在构建并且保护它的团队手中。
自主的团队
将咱们的代码库和公布周期拆散的更高阶的益处，是使咱们领有了齐全独立的团队，能够参加到本人产品的构思、生产及后续的过程。每个团队都领有为客户提供价值所需的全副资源，这就使得他们可以疾速且无效地口头。为了达到这个目标，咱们的团队须要依据业务性能纵向地划分，而不是依据技术品种。一种简略的办法是依据最终用户将看到的内容来宰割产品，因而每个微前端都封装了应用程序的单个页面，并由一个团队全权负责。与依据技术品种或“横向”关注点（如款式、表单或验证）来组成团队相比，这会使得团队工作更有凝聚力。
四. 微前端计划品种
目前国内微前端计划大略分为：
- 基座模式：通过搭建基座、配置核心来治理子利用。如基于SIngle Spa的偏通用的乾坤计划，也有基于自身团队业务量身定制的计划。
- 自组织模式： 通过约定进行互调，但会遇到解决第三方依赖等问题。
- 去核心模式： 脱离基座模式，每个利用之间都能够彼此分享资源。如基于Webpack 5 Module Federation实现的EMP微前端计划，能够实现多个利用彼此共享资源分享。
其中，目前值得关注是去核心模式中的EMP微前端计划，既能够实现跨技术栈调用，又能够在雷同技术栈的利用间深度定制共享资源，如果刚开始调研微前端的话，能够先尝试理解一下EMP微前端计划，或者会给你带来不错的应用体验。
具体的多计划深刻比照剖析，会在下一篇文章《比照多种微前端计划》具体讲解，欢送大家关注wiki博文首发更新。
EMP微前端wiki博文更新目录：
基础知识解析
微前端到底是什么，能够带来什么收益
比照多种微前端计划
webpack5 module Federation原理学习
EMP的设计架构
多场景应用教程
react我的项目如何应用和接入EMP
vue我的项目如何应用和接入EMP
Vue和React我的项目如何相互近程调用
cocos2d 我的项目如何应用和接入EMP
教你基站搭建技巧
辅助插件的应用教程