7

我们正在微服务架构中构建一个编排器。我们选择 websockets 作为 RPC 协议，以建立一个流管道，该管道可以通过像 Kestrel 这样的支持 websocket 的服务器进行扩展。该编排器将主要在 Linux 服务器（dockerized）上运行。

出于管理和监控目的，我们计划使用http://dotnetify.net/构建一个反应式 Web 管理门户（可以半实时显示计算和客户端的数量，并带有推送通知）。

DotNetify 使用 SignalR，我们不能在 Websockets 之上使用 SignalR 层。在 TCP 协议之上，我们需要最小的开销。Websocket 本身是一个漂亮的标准，并且足够轻量级，但 SignalR 增加了对我们并不真正需要的东西（LAN、微服务）的支持。我们确实考虑过 WAMP，但在概念验证中，我们将在 websocket 总线中使用简单明了的自定义握手。另一个原因是：我们的主要后端是 IBM AIX，而 RDBMS 流程引擎是商业预构建二进制文件，因此在那里实现 SignalR 协议非常麻烦（几乎不可能）。但我们不必这样做，因为我们不想这样做。

在 1 个进程中拥有 [A]“纯”和 [B]“signalR”websocket 服务器的一种可能解决方案是启动多个 Kestrel。我试过这个（在windows和ubuntu上），它似乎运行没有问题。我只是使用了一个Task.Run()数组，然后是Task.WaitAll(backgroundTasks). 一个带 SignalR 的 Kestrel，一个不带 SignalR，在不同的端口上运行。 注意：我找不到在一个 Kestrel 中使用多个端口并从一个端口中排除 SignalR 的正确方法

我的问题是：虽然这似乎运行得很好，但有人可以确认这是安全的吗？特别是使用 libuv 和 os 信号处理？

4

1 回答 1

2

您可以像往常一样使用 SignalR，只需在特定路径上侦听 Websocket 连接，以便与您的 AIX（和其他后端）框进行对话。只需执行以下操作（取自Microsoft Docs）：

app.Use(async (context, next) =>
{
    if (context.Request.Path == "/ws")
    {
        if (context.WebSockets.IsWebSocketRequest)
        {
            WebSocket webSocket = await context.WebSockets.AcceptWebSocketAsync();
            await Echo(context, webSocket);
        }
        else
        {
            context.Response.StatusCode = 400;
        }
    }
    else
    {
        await next();
    }

});

我看不出有什么理由需要启动两个 Kestrel 实例。显然，将上面路径的 /ws 部分替换为您想要用于为后端服务连接 WebSocket 的任何端点。

于 2018-05-25T21:15:41.633 回答