【问题标题】:Is it safe to create multiple Kestrel instances inside 1 process?在 1 个进程中创建多个 Kestrel 实例是否安全?
【发布时间】:2018-05-26 05:15:41
【问题描述】:

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

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

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 信号处理?

【问题讨论】:

    标签: asp.net .net-core dotnetify


    【解决方案1】:

    您可以像往常一样使用 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 的任何端点。

    【讨论】:

    • 你的回答很有道理,谢谢发布。我们确实考虑了这条路线,但希望为流程的门户部分提供一个专用端口。这增加了隔离并简化了安全性。我暂时不回答这个问题,因为我们想知道主题问题的答案。 +1。 FWIW:到目前为止,我们在一个进程中运行多个 Kestrel 没有遇到任何问题。但我们希望得到比我们更有权威的人的反馈。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2021-12-25
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多