我需要一些有网络经验的人的建议。
我已经创建了一个系统，用于监控由自动调度程序或操作员启动的用 Java 编写的一些任务（5-30）。这些任务用于银行或保险领域的系统。
该系统由一个客户类，来自多线程服务器并从Web应用程序。任务将使用客户端与服务器进行通信，并且 Web 应用程序也会执行相同操作来监视服务器上注册的任务的性能，并且 Web 应用程序也可能向任务发送一些命令，例如“停止”或“暂停”。
任务[1-n]<--->服务器<--->web应用程序
由于 Web 应用程序必须能够向批处理发送命令，因此问题就在这里。我找到了 2 个解决方案：
1）无连接；双方之间不保持打开的连接，客户端定期向服务器发送状态并询问服务器是否有命令给他，周期应该是几秒钟，每个请求以类似于 http 协议的方式打开然后关闭套接字连接。
2）Connectionfull；双方之间保持主动连接。此时，任务可以与服务器通信，服务器与任务之间无需轮询。例如，每次 Web 应用程序向服务器请求任务的状态时，他都会询问由谁提供该任务的客户端。
暂时我采用了解决方案1，在模拟测试环境中，它运行良好。
问题是，从资源使用和灵活性的角度来看，两者之间是否存在一个绝对更好的解决方案，如果有，哪一个？
如果您有关于该主题的具体讨论的链接，欢迎与我们联系。
谢谢再见。
答案1
这个问题可能与 Server Fault 无关。它当然是基于观点的。
适合您软件的架构取决于应用程序使用环境的网络和安全架构。它还取决于组件之间所需的通信频率以及轮询与持久连接可能使用的带宽量。
如果这是一个用于转售的产品，我会让它尽可能灵活，并且可能会尝试利用多种架构。
例如，如果客户端和服务器组件在同一个安全“区域”中运行，那么您可以考虑一种架构，其中任一组件都可以启动与另一组件的通信（实际上在某种程度上使两个组件都成为“服务器”）。这将最大限度地减少延迟并消除轮询。
或者，如果客户端被隔离，使得服务器无法与客户端建立任意连接（例如，如果客户端位于防火墙的内部，防火墙将两者分隔开），那么轮询或来自客户端的持久连接可能是可行的方法。如果轮询频率很高，轮询可能过于“昂贵”（从带宽利用率的角度来看），但持久连接需要定期的“心跳”来保持它们在状态过滤设备之间“活跃”。
不存在一种万能的解决方案。