微前沿规则

我一直很好奇大型 Web 应用是如何构建的！不久前我终于发现了其中的奥秘，并从此对它产生了浓厚的兴趣。在体验了大规模使用微前端的优势和挑战之后，我决定记录下这段历程，并分享一些“最佳实践”。

这是一份关于设计遵循微前端模式的应用程序的最佳实践清单，仅供参考。每条“规则”都应仔细审视，并根据您的具体用例评估其优缺点。

微前端之间零耦合

为了实现这种架构的优势，应尽可能避免意外耦合；这将释放微前端模式所提供的灵活性和可扩展性，并通过允许增量升级或将来对应用程序的部分进行完全重写，使您的应用程序面向未来。

每个微前端都应该能够独立渲染，也可以在容器应用中渲染。所需数据应由每个微前端自行加载，避免数据瀑布效应。

做：

✅ 共享可互换的库，不会影响其他微前端。✅
加载渲染所需的所有数据。

不要：

❌ 在不同的微前端之间集中存储/共享数据。❌
共享正在积极开发的库。

独立的代码库

每个微前端都应该有自己的代码库，并且所选的版本控制系统不应影响项目的开发或部署方式。所有项目放在同一个单体仓库或各自独立的仓库中都是可以的。

做：

✅ 使用单体仓库。
✅ 使用独立仓库。

 每个微前端都应该独立部署。

每个微前端都应该拥有独立的 CI/CD 流水线，并能够按需部署到生产环境，而无需依赖其他微前端。一个常见的反模式是“地狱部署队列”，即不同的微前端耦合过于紧密，以至于必须按照特定的顺序部署才能避免应用程序崩溃。

做：

✅ 拥有独立的持续集成/持续交付 (CI/CD) 流水线。✅
按需发布。

不要：

❌ 制定发布计划。❌
采用增量/顺序部署，需要先部署先前的版本。

微前端应进行独立测试

由于微前端既需要在容器应用程序中独立渲染，也需要在容器应用程序中渲染，因此对这两种情况都使用单元测试和集成测试进行独立测试是有意义的。

做：

✅ 为每个微前端渲染分别编写单元测试和集成测试。✅
在端到端测试中，对容器应用程序内部的微前端渲染运行集成测试。

 微前端应该进行版本控制。

当新的微前端部署到生产环境时，不应删除旧版本，而应使用语义化版本控制或其他类似方法为新版本添加版本号。容器应用程序可以自行决定使用特定微前端的哪个版本（托管模式）或始终使用最新版本（常青模式）。

做：

✅ 使用语义化版本控制。✅
使用特定版本或“最新”版本。

不要：

❌ 版本变更需要全局部署。❌
删除旧版本。

极简沟通。

微前端之间的通信应该尽可能少且简单，避免使用全局状态和特定于框架的解决方案。

如果两个或多个微前端共享大量消息以提供其最低限度的功能，则它们可能耦合得太紧，并且它们可能具有足够相似的用途，因此应该考虑将它们集成到一个微前端中。

做：

✅ 保持信息简短明了。✅
尽可能避免使用状态和沟通框架。

不要：

❌ 分享状态。❌
进行不必要的沟通。

CSS 应该有作用域。

从一个微前端加载的 CSS 不应该影响其他微前端。

做：

✅ 为你的 CSS 设置作用域。✅
使用 CSS-in-JS 或命名空间库（例如 CSS Modules）。

不要：

❌ 使用全局 CSS。

最终建议

✅ 尽量创建自治团队。✅
尽量围绕业务功能来构建微前端。✅
可重用性是一个不错的“附带结果”，而非最终目标。❌
不要仅仅因为某种架构风格“新颖”就强行采用。❌
你不需要多个 JavaScript 框架。❌
你不需要“微前端框架”。❌
微前端不一定非得是“微”的。