Question

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

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

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

有[A]＆＃34;纯＆＃34;的可能解决方案和[B]＆＃34; signalR＆＃34; websocket服务器在1个进程内，正在启动多个Kestrel。我试过这个（在Windows和ubuntu上）它似乎运行没有问题。我只使用了@RequestMapping(value = {"/uploadSession"}, method = RequestMethod.GET) protected void GetUploadSession(HttpServletRequest request, HttpServletResponse response) throws IOException { BlobstoreService blobstoreService = BlobstoreServiceFactory.getBlobstoreService(); String redirectAction = blobstoreService.createUploadUrl("/myView"); String json = new Gson().toJson(redirectAction); response.setContentType("application/json"); response.setCharacterEncoding("UTF-8"); response.getWriter().write(json); }数组，然后是Task.Run()。一个带有SignalR的红隼，一个没有，在不同的端口上运行。 注意：我找不到在一个Kestrel中使用多个端口的正确方法，并从一个端口中排除SignalR

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

1 个答案:

答案 0 :(得分：2)

Answer 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部分替换为您要用于连接后端服务的WebSockets的任何端点。

在1个进程中创建多个Kestrel实例是否安全？

1 个答案: