等待API服务器中的响应

问题描述：

我有一个Netty HTTP服务器用作API服务器。用户将事件发送到API服务器，并使用执行器服务或并发框架（如Akka）在同一服务器上的其他线程上处理事件。我有两个答案选项;当我将事件发送到另一个线程时，我可以等待响应并将其写入套接字或将确认消息写回套接字。等待API服务器中的响应

当我等待响应时，http请求的延迟增加，服务器可以处理的请求数减少。另一方面，不能控制背压，所以我们不知道服务器何时处理事件，并且我不能通知用户服务器处理了事件。但是，服务器可以处理的http请求数量会增加，因为几乎所有请求的延迟都很低。

public void channelRead(ChannelHandlerContext ctx, Object msg) { 
    if (msg instanceof HttpRequest) { 
     executor.submit(new Event(msg)); 
     // do not wait for the response 
     ctx.write(new DefaultFullHttpResponse(HTTP_1_1, OK)); 
    } 
} 

public void channelRead(ChannelHandlerContext ctx, Object msg) { 
    if (msg instanceof HttpRequest) { 
     Future<Object> future = executor.submit(new Event(msg)); 
     future.after(x -> ctx.write(new DefaultFullHttpResponse(HTTP_1_1, OK))); 
    } 
}

因为它是一个API服务器，我没有等待，以便通知被处理事件的用户的响应，因为它只是一个写请求不返回响应。那么对于http服务器来说哪种方式最为方便，您认为第二种方式值得其性能受益吗？

那么问题是什么？ – biziclop 2014-10-26 18:31:12

我更新了问题@biziclop – Boyolame 2014-10-26 19:01:57

答

我认为答案取决于您的要求。一般而言，遵循的一个好哲学是保持简单。这可能意味着需要完成最少量的工作，这可能意味着留下可扩展空间。如果您的用例不提供状态是有意义的，那么您会这样做的原因是什么？然而，通常在简单和提供足够的系统可视性之间进行权衡。这听起来像你不确定什么是和不是必需的？

问问你自己以下问题：

的客户端可以使用返回状态做一些有意义的事？你的客户没有这种身份可以做什么？
您是否可以预见客户需要在未来发生变化以要求回复后处理？（即退货状态，退货正文，错误代码等）
您的服务器是否需要跟踪从获取客户端请求到将服务器转换为服务器所发生的一切？
您的可见度和调试问题的能力是什么？
添加功能所需的额外复杂性和开销是多少？这可以接受吗？

这些只是在这种情况下你应该问自己的许多问题中的几个。根据您提供的信息，我不确定是否有可能向您提供“您应该做X”或“您应该做Y”的答案。我认为最好的办法是重新评估你的要求，然后问自己一些像上面列出的问题。

等待API服务器中的响应

相关推荐