9
目前任务调用是通过服务器端调用客户端的端口来实现的。但是这样在部署上会有一些麻烦，比如集群部署时要指定多个端口，要配置防火墙等。此外，在容器云/Service Mesh上部署时，需要pod对外暴露端口，是比较麻烦的操作。因而，比较想知道为什么不是实现成客户端长连接请求服务端这样子，这样在部署上比较方便，此外有更加少的安全问题。是否有其他架构上的考虑呢？
Q
[xuxueli/xxl-job]为什么任务调用不是做成客户端长连接请求服务器这样子呢？
A
回答
7
我理解定时任务是个相对低频的操作、且任务触发在很多场景下只选择一个节点执行即可；基于这种背景，所有节点与服务端长连是对网络连接的浪费。 如果是在同一个K8S集群内，可以直接使用pod ip访问非容器端口；不用pod对外暴露端口。
9
您说的有道理。不过我觉得总的来说，长连接对资源的消耗其实是相对较小的。就端口来说，服务器调客户端的模式要求客户端多暴露一个端口，所以端口的消耗两种模式是一样的。至于连接消耗，对比总流量来说基本可以忽略。此外，我觉得当定时任务频率较高，任务数量较多，或者节点较多时，只选择一个节点进行远程触发还是会遭受压力的。
9
长连接不是只有一个tcp连接就行，还需要保活，需要心跳报文； 调度器是集群部署的，调度器伸缩，连接数会成倍的变化； 任务路由也有多种策略，只要不是广播任务，多个节点是可以分担压力的；
6
- 这里的长连接本来是指1min左右的长连接，不是数据库那种一直保持的。不过无论哪种，这种消耗都不高，这也是为什么隔壁直接让应用连接zk，本质是一样的。
- 连接数会成倍的变化这里其实是假设了每个客户端连接每个服务器，这其实并不是必要的，通过技术手段，每个客户端连接一个服务器即可。
- 这里目前不是很懂，可能对xxl-job代码还没有完全了解。
8
我现在内网调试，还得内网搭建服务器，无法直接使用公网的调度器。如果使用长连接就可以解决我这个问题
4
你好，逻辑整体和 @KoneZJ 一致，基于调度业务特性以及成本考虑。