Blazor WebAssembly(托管)微服务策略

Blazor WebAssembly (Hosted) MicroService Strategy

我的应用程序的核心是由一套微服务组成的,每个微服务都主要使用 DDD 架构。

在标准 MVC 解决方案中,客户端将访问我的控制器,而控制器将与我的微服务交互。

在 Blazor 服务器设置中,方法类似。

但是,通过 Blazor WebAssembly(托管)设置,我有机会直接从 Blazor WebAssembly 客户端引用我的微服务。

这明智吗?

或者我是否会更好地在 Blazor 服务器上创建一个外观(它反过来访问微服务)并且只从 Blazor WebAssembly 客户端与该外观通信?

我的 Blazor 服务器有自己的引用微服务的需求,我正要在客户端上注册微服务,然后想知道这是否合理。

这在很大程度上取决于您的体系结构及其约束,并考虑了一个合适的答案。

BFF

你可以使用 BFF(前端后端)模式,你的脸。在这种情况下,另一个微服务将充当 Blazor 应用程序和微服务环境之间的网关。

因此,前端不需要知道在什么服务中查找什么信息。通常,这会简化前端的开发。此外,BFF 可以处理 cross-cutting 诸如身份验证之类的问题。

但是,您引入的新微服务无助于解决您的业务问题。您正在添加另一层意外的复杂性。

此外,使用 BFF,您可以在服务之间创建一种依赖关系。如果您更改或添加微服务的功能,则还需要更新 BFF。

直接打电话给他们

如果您的微服务有一种 HTTP (REST) API(顺便说一句,不是每个微服务都需要那个)可以暴露给 public(您的 Blazor 客户端),直接从客户端是一个选项。

每个服务都需要处理 cross-cutting 问题,比如自己进行身份验证。客户端需要跟踪多个潜在的服务连接。他们会有不同的 URL,但可能还需要不同的 headers 等

结论

视情况而定。您最了解您的架构,并且有很多文章讨论 BFF 的优缺点。我可以推荐从这篇文章开始 https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern.

  • 我们谈论的是 3 个还是 30 个微服务?
  • 客户端调用微服务的频率是多少?
  • 客户端需要多久请求一次多个服务来生成一个视图?
  • 您以前使用过 API 网关吗?
  • 是否需要身份验证或担心?
  • 如何定期更改微服务的API?

希望我的回答能帮助您找到您的答案。 :)