采用微前端的 5 个理由

现在大多数人应该都听说过微前端这个概念了。继微服务之后，它似乎是大型系统解耦的下一个目标。但和微服务一样，它并不适合所有人。

我个人认为，在开始使用微前端之前，你应该首先清楚自己为什么要使用微前端。

显然，微前端有多种解决方案。虽然我个人提倡使用 React 作为微前端的基础，但这种方法适用于任何技术和任何实现模式。

如果你对微前端感兴趣，不妨了解一下 Piral。别忘了给它点个赞哦！

1. 独立团队

如果开发工作由多个团队负责，那么组织架构的开销就会变得非常巨大。沟通至少需要每天进行。要有效控制开发和部署，所需的协调工作将变得难以实现。

微前端使得开发资源的扩展管理变得更加容易。通常，每个功能都可以由一个独立的团队开发。每个团队都可以自主发布其功能，无需任何协调。

某些微前端方案至少需要共享构建系统或公共层（例如反向代理）。虽然这些问题可以预先解决，但会增加初始设置难度，使整个解决方案更加复杂。因此，我的建议是寻找初始设置完成后即可正常运行的解决方案。

2. 更快的上市时间

微前端的独立性也会影响各个功能的上市时间。单体架构的功能开发速度会越来越慢，而微前端则能保持这种速度。

当然，底层技术的重构和改进也必不可少，然而，由以下几个步骤组成的周期所能达到的速度是有限的：

• 启动新项目
• 开发最小可行产品
• 运送MVP
• 迭代开发MVP（开发和发布）
• 进入维护模式

每一项新功能都意义重大。初始功能的开发和上线可能只需几分钟到几天，而不是几周甚至几个月。

通过共享部分已使用的资源和功能，可以加快产品上市速度。与其从头开始开发新应用（包括身份验证、日志记录等），不如让一个公共层提供所有这些功能。我的建议是采用应用外壳（app shell）的方式，将那些应该在共享组件中实现的功能集中起来。

3. 功能标志

将各个独立的微前端组合（或拼接）成一个应用程序固然很好，但产品负责人往往希望在技术组合之外更进一步：他们还希望将模块化应用于业务领域。

你是否遇到过某些前端功能应该只对特定用户开放的情况？我想肯定有。当然，管理员功能应该只对管理员开放。虽然前端不应该被用作保护层（这一点在后端仍然需要验证），但我们也不想展示那些无法（或不应该）使用的功能。

因此，我们将在代码中添加类似以下内容：

if (hasFeature('foo')) {
  // ...
}

这种写法很糟糕。我们的代码现在充斥着很多很可能会改变的东西。如果foo某个条件对所有人来说都成立怎么办？如果这个功能对所有人来说都被禁用了怎么办？如果明天又出现了一个新的条件，导致某些代码需要同时判断某个条件是否bar启用怎么办？

由于我们已经实现了良好的模块化，因此添加功能标志非常简单。我们只需要通过功能标志引入模块的条件配置即可。就是这样。无需更改模块的功能层代码，只需在配置层引入功能标志及其管理即可。

虽然类似的方法在传统的单体架构中也能实现，但需要更多的工作量。而微前端架构已经为此做好了充分的准备。我的建议是选择一个支持按用户进行条件配置的微前端框架。

4. 单一责任制

尽管微服务并非万能，但它却被大力推崇。诚然，在很多（甚至大多数）情况下，微服务确实是一个不错的解决方案，但很多时候，单体架构或其他形式的面向服务的架构可能同样有效。

尽管如此，在后端设立一个专门的服务（并配备负责团队）是一个良好的开端。现在用不同的微前端替换单体架构是一个很好的延续，因为精简团队带来的额外优势可以以多种方式加以利用。

一种可能性是组建全栈团队。这样一来，负责后端模块（微服务）的团队也同时负责前端模块（微前端）。太好了！

从技术角度来看，服务及其前端无疑是两回事，但从业务角度来看，它们却密切相关，甚至可以说是同一回事。由同一个团队负责单一的业务能力或功能，无疑是一项优势。

问题之一在于，典型的用户旅程往往会涉及多个业务功能。因此，我的建议是使用一个框架，该框架允许在一个微前端中动态地使用另一个微前端的组件。这种关联必须较弱，以便仍然允许对单个功能进行标记。

5. 技术自由

过去两年，前端技术基本趋于稳定。诚然，随着Svelte 的出现， React等技术可能会再次面临挑战，但说实话，我至今仍未感受到任何优势。目前，在单一代码库中进行开发实在太有吸引力了。

撇开我对任何框架未来走向的个人看法不谈，事实是，目前存在多种解决方案，并不存在万能灵药。因此，我们不仅会遇到背景各异的人（没错，甚至还有一些人正在开发Angular！），还会遇到使用不同（甚至可能已经过时）技术的现有应用程序。

在微前端解决方案中，所有这些不同的应用程序都可以协同工作。用 Angular 编写的页面可以使用 React 微前端的组件，反之亦然。用于保存用户数据的模态对话框可能用 Vue 编写，而其底层页面则用 Svelte 构建。

如何实现一致的用户体验是一个难题，由此引发了诸多问题。其中最重要的问题包括：

• 这里只分享纯 CSS 代码吗？
• 行为方面呢？
• Web组件真的能解决这个问题吗？

因此，技术自由度应该始终是开发微前端时最不应该考虑的因素。我的建议是，一开始就采用简洁的方法，但选择一个至少支持多种框架（包括相应的通信策略）的框架。

结论

微前端并非万能灵药。在特定情况下，它们可以提供帮助并创造价值。如果以上任何原因对您来说都不重要，那么您很可能不需要微前端解决方案。

当您选择微前端解决方案时，请务必了解一下 Piral。