学习微前端

weixin79893765432...

已于 2022-09-24 16:30:31 修改

阅读量172

点赞数

分类专栏：业务与架构文章标签： javascript html html5

于 2021-10-09 12:01:52 首次发布

本文链接：https://blog.csdn.net/mChales_Liu/article/details/120667699

版权

关键词由CSDN通过智能技术生成

10 篇文章 1 订阅

订阅专栏

什么是微服务？先看看维基百科的定义：
微服务是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关的API集相互通信。

一种由独立交付的多个前端应用组成整体的架构风格。具体的，将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的小块，而在用户看来仍然是内聚的单个产品。

简单、松耦合的代码库：代码库更小，更内聚、可维护性更高
增量升级：渐进地升级、更新甚至重写部分前端功能成为了可能。在逐步重构的同时，既要确保中间版本能够平滑过渡，同时还要持续交付新特性。先让新旧代码和谐共存，再逐步转化旧代码，直到整个重构完成。这种增量升级的能力意味着我们能够对产品功能进行低风险的局部替换，包括升级依赖项、更替架构、UI 改版等。另一方面，也带来了技术选型上的灵活性，有助于新技术、新交互模式的实验性试错。
独立开发、测试、部署：缩小变更范围，进而降低相关风险。
团队自治：除代码库及发布周期上的解耦之外，微前端还有助于形成完全独立的团队，自治的团队可扩展性更好。

所有依赖人为约束的方案都很难避免由于人的疏忽导致的线上 bug。

所有的软件工程原则也都会告诉我们，不遗余力、不计成本的去优化、解决一个技术问题是不可取的，尤其是在这个问题的投入产出比不高的情况下。

微前端倡导的不是消极的、投降主义的去回避系统中的历史遗留问题，而是告诉我们，很多时候 我们可以通过分而治之的手段，让「上帝的归上帝，凯撒的归凯撒」。

存在以下场景时，你可能就不需要微前端：

满足以下几点，你才确实可能需要微前端：

系统本身是需要集成和被集成的一般有两种情况：
- 旧的系统不能下，新的需求还在来。没有一家商业公司会同意工程师以单纯的技术升级的理由，直接下线一个有着一定用户的存量系统的。而你大概又不能简单通过 iframe 这种「靠谱的」手段完成新功能的接入，因为产品说需要「弹个框弹到中间」
- 你的系统需要有一套支持动态插拔的机制。这个机制可以是一套精心设计的插件体系，但一旦出现接入应用或被接入应用年代够久远、改造成本过高的场景，可能后面还是会过渡到各种微前端的玩法。
系统中的部件具备足够清晰的服务边界。通过微前端手段划分服务边界，将复杂度隔离在不同的系统单元中，从而避免因熵增速度不一致带来的代码腐化的传染，以及研发节奏差异带来的工程协同上的问题。