通信微服务/微前端架构

Question

在阅读有关微前端的文献时，我总是看到前端由不同团队开发的微前端组成。每个微前端都有至少一个后端。我看不到后端相互通信。是对的吗？他们是否分开，完全可以在后端之间没有任何通信的情况下生存？

Answer 1

微前端的好处：

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

最佳微前端架构：

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

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

前端服务通常不应包含业务逻辑；然而，有一种观点认为，对于较小的应用程序/更早的应用程序，拥有一个处理同一域的 UI 和业务逻辑的单一服务是有意义的。拥有过于广泛而不是过于狭窄的服务通常是较小的罪恶。

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

最后，明智地选择前端服务/域的边界非常重要。您有许多前端服务都需要频繁调用相同的后端服务，这不应该是这种情况。最好从单一的广泛前端服务开始，然后随着您对边界变得更加自信而进一步细分。