增量升级、代码解耦、独立部署

务近年来大受欢迎，许多组织转向了微服务以克服大型单体后端架构的局限。但虽然微服务在服务端很流行，很多企业在前端代码库上仍然在沿用问题多多的单体架构。

也许你想构建一个渐进式或响应式的 Web 应用，但却找不到一种将这些功能集成进现有代码中的简单途径;也许你想尝试 JavaScript 语言的新功能(或者是其他可以编译为 JS 的某种语言)，但你却无法将关键的构建工具融入已有的构建流程;或者你只是想扩展开发流程，让多个团队可以同时开发一种产品，但现有单体架构中的耦合度与复杂性让团队间的合作变得磕磕绊绊。这些都是很现实的问题，都会影响你们向客户交付高质量体验的能力。

微前端的定义

最近业界越来越关注复杂的现代化 Web 开发需要怎样的整体架构和组织结构这个问题。于是我们开始看到单体前端正在分解为更小、更简单的模块，这些模块可以各自独立开发、测试和部署，而它们组合在一起仍然对客户表现为一件单一完整的产品。我们将这种技术称为 微前端，其定义为：

“微前端是一种架构风格，其中众多独立交付的前端应用组合成一个大型整体。认为微前端的主要好处有：

• 更小，更紧密且更易维护的代码库。
• 组织更具扩展能力，其团队更加独立自治。
• 能够以更加增量式的风格来升级、更新前端，甚至重写部分前端代码。

这些核心优势与微服务的优势基本一致，这也不是什么巧合。

当然，软件架构领域没有免费的午餐：一切都要付出代价。一些微前端实现可能导致重复依赖，使用户不得不下载更多内容。此外，大幅提升的团队自治水平可能会让各个团队的工作愈加分裂。只不过我们认为这些风险都能控制在合理水平上，微前端终究还是利大于弊的。

好处

我们不会从具体的技术方法或实施细节角度来定义微前端，而是重点关注它的属性和好处。

增量升级

对于许多组织来说，追求增量升级就是他们迈向微前端的***步。对他们来说，老式的大型单体前端要么是用老旧的技术栈打造的，要么就充斥着匆忙写成的代码，已经到了该重写整个前端的时候了。一次性重写整个系统风险很大，我们更倾向一点一点换掉老的应用，同时在不受单体架构拖累的前提下为客户不断提供新功能。

为了做到这一点，解决方案往往就是微前端架构了。一旦某个团队掌握了在几乎不影响旧世界的同时为生产环境引入新功能的诀窍，其他团队就会纷纷效仿。现有代码仍然需要继续维护下去，但在某些情况下还要继续添加新功能，现在总算有了解决方案。

到***，我们就能更随心所欲地改动产品的各个部分，并逐渐升级我们的架构、依赖关系和用户体验。当主框架发生重大变化时每个微前端模块都可以按需升级，不需要整体下线或一次性升级所有内容。如果我们想要尝试新的技术或互动模式，也能在隔离度更好的环境下做试验。

简洁、解耦的代码库

微前端体系下，每个小模块的代码库要比一个单体前端的代码库小很多。对开发者来说这些较小的代码库处理起来更简单方便。而且微前端还能避免无关组件之间不必要的耦合，让代码更简洁。我们可以在应用的限界上下文(详见下方链接)处划出更明显的界限，更好地避免无意间造成的这类耦合问题。

当然，只靠架构更迭本身(比如说“我们改成微前端吧”)并不能自动为以往的优质代码生成替代品。我们要做的是设法让糟糕的决策难以露头，而让正确的决策畅通无阻，从而进入迈向成功的良性循环。例如，现在很难跨越限界上下文共享域模型，所以开发者就不太可能这样做了。类似地，微前端会让开发者更审慎地把握数据和事件在应用的各个部分之间流动的方式，其实就算没有微前端我们本来也应该这样做的!

（编辑：开发网_开封站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!