使用 API 网关和微服务的 Blazor 服务器指南

Question

到目前为止，我还没有找到使用Blazor服务器（不是WebAssembly）和API网关和微服务的指导。讨论这些Blazor以及API网关和微服务的文章总是提到Blazor WebAssembly（Wasm）。（是不是假设Blazor Server应用程序不会使用微服务？此外，值得一提的是，选择Blazor服务器而不是Blazor WebAssembly的原因是为了更好地保护知识产权。）

无论如何。。。我想知道的是 Blazor Server 应用是否应该位于网关前面，通过网关将其内部 API 调用发送到网关后面的微服务，如下所示......

[浏览器] ----（SignalR）--- [Blazor Server App] ----（https）---- [API Gateway] ----（http）---- [微服务]

还是将应用程序放在网关后面，让SignalR连接隧道通过网关更有意义，就像这样……

[浏览器] ----(SignalR)---- [API网关] ----(SignalR)---- [Blazor Server App] ----(超文本传输协议)---- [微服务]

在建立SignalR连接之前，请记住浏览器中应用程序的初始加载。那需要分开处理吗？它会影响上面给出的选项的选择吗？我错过了什么更好的解决方案吗？

Answer 1

我们使用Blazor服务器端作为运行在Azure Service Fabric(本身是一个无状态的ASP.NET核心服务)中的一组微服务的前端，所以这是一个完全合法的场景。我们的整个应用程序运行在Azure的云中，所以我将使用它的产品来描述我们的实现。

为了更好地分离关注点和更容易地保护互联网边界，我们为公共API和SignalR提供了两个独立的服务。因此，API网关充当了安全边界，因为它可以处理HTTPS卸载，位于面向公共的子网上，并路由到虚拟网络上的内部服务。然后，提供SignalR访问的服务在应用网关实例后面的面向公共的子网上运行（用于防火墙服务路由功能）。

因此，我们设置了如下两个服务:

[浏览器]--（SignalR）--[Azure应用程序网关]--[AzureService Fabric-Blazor服务器端应用程序]--[SF Service Remoting]--[微服务]

[浏览器]-[https]-[Azure API管理]-[http]-[Azure Service Fabric-ASP.NET核心API]-[SF Service Remoting]-[微服务]

特别是在支持身份验证时，ASP。NET Core在内部设置了一些密钥，用于加密Blazor会话中使用的状态。在微服务场景中，除非您在网络堆栈（负载平衡器、网关、路由器等）中一直有粘性路由，以确保所有请求始终命中同一个实例（并且假设您的实例在您不注意的情况下不会重新构建并移到其他位置），否则您将遇到关于无法解除状态保护的模糊且无用的错误。

修复非常简单-在启动中。cs。NET核心服务，确保您设置了＜code＞服务。添加数据保护（）并进行适当配置。由于我们使用的是Service Fabric，因此我们使用的第三方库非常适合此目的。要使用，请安装NuGet包＜code＞SoCreate.AspNetCore.DatapProtection。ServiceFabric到您的ASP。NET核心服务，只需在启动时输入以下内容即可。＜code＞ConfigureService（）＜/code＞方法中的cs：

public void ConfigureServices(IServiceCollection services)
{
  //...
  services.AddDataProtection().PersistKeysToServiceFabricDistributedCache(opt => {
    //Unique for this ASP.NET Core microservice, don't use a new GUID each time or you'll be back where you started without a single store for all the services
    opt.CacheStoreId = new Guid("b87d03b5-f8d1-456f-966d-11d2c4d9774d"); 

    //Specifically points to the service to use - if not set, it'll be automatically discovered
    opt.CacheStoreServiceUri = new Uri("fabric:/MyApplication/DataProtectionStore");   });
  //...
}

您可以在后一种方法上指定其他选项来标识它应使用的特定服务和唯一 ID（以便可以在应用程序之间共享服务），但如果它位于同一应用程序中并且您未指定这些选项，它将找到它本身。

然后创建一个有状态服务实例，安装< code>SoCreate。在文件中获取反映服务名称的extensions . caching . service fabric ，并替换其从< code>StatefulService的继承，改为从< code > DistributedCacheStoreService 继承。删除服务中的所有其他内容，但设置更新的构造函数。在名为“DataProtectionStore”的服务中，您的< code > data protection store . cs 文件应该如下所示:

using System.Fabric;
using SoCreate.Extensions.Caching.ServiceFabric

namespace DataProtectionStore
{
  internal sealed class DataProtectionStore : DistributedCacheStoreService
  {
    protected override int MaxCacheSizeInMegabytes => 500; //Optional

    public DataProtectionStore(StatefulServiceContext context) : base(context, message => ServiceEventSource.Current.ServiceMessage(context, message))
    {
    }
  }
}

您可以在此处找到特定于在“网络场”或微服务/分布式环境中托管ASP.NETCore的其他有用指南。