1

在阅读有关微前端的文献时，我总是看到前端是由不同团队开发的微前端组成的。每个微前端至少有一个后端。我没有看到后端相互通信。那正确吗？他们是否以这种方式分开，以至于他们可以完全生活而无需后端之间的任何通信？

4

1 回答 1

0

微前端的好处：

  • 能够在团队/域之间独立部署 UI 代码
  • 每个团队使用不同技术的能力
  • 该域的 UI 代码的硬边界/封装
  • 给定更小的代码库，更快的构建、测试和部署时间

最佳微前端架构：

  • 假设一个用户面向 webapp：
  • “平台”微前端服务于“骨架”页面
  • 从用户的角度来看，它是一个具有一个域名的单个站点（避免 CORS 问题）
  • “骨架”页面根据命名空间路由调用特定于团队的前端，通常这种基于路径的路由是通过入口或反向代理处理的（例如/namespace/accounting，转到会计前端）
  • 前端服务（微前端）严格负责表示问题，并经常调用对各种数据拥有所有权的其他后端服务。
  • 前端服务包含用于服务静态资产/组件以及处理 ajax 请求/组合 UI 特定数据的逻辑。

摘要：
您的前端服务通常必须调用后端服务来组合数据以用于演示目的。例如，如果您需要显示用户数据，您可能需要调用一些 UserService 或 AccountService 以获取有关该用户的其他详细信息。我不建议尝试使用特定于前端服务的复制数据构建单独的数据存储。

前端服务通常不应该包含业务逻辑；但是，有一个论点是，对于较小的应用程序/早期来说，拥有一个处理同一域的 UI 和业务逻辑的单一服务是有意义的。拥有过于宽泛而不是过于狭窄的服务通常是较小的邪恶。

但是，在微服务架构中，将服务之间的必要依赖关系降至最低仍然很重要。一个常见的问题是运行到“依赖”地狱，你调用Service A，它需要调用Service B 等等，这使得架构变得缓慢而脆弱。前端服务通常会调用仅“一层深”的服务，然后将这些响应组合成单个显示数据/有效负载。

最后，明智地选择前端服务/域的边界非常重要。您不应该有许多前端服务都需要频繁调用相同的后端服务。最好从单一广泛的前端服务开始，随着您对边界的信心越来越大，进一步分解它。

于 2020-12-28T21:33:25.133 回答