目前任务调用是通过服务器端调用客户端的端口来实现的。但是这样在部署上会有一些麻烦，比如集群部署时要指定多个端口，要配置防火墙等。此外，在容器云/Service Mesh上部署时，需要pod对外暴露端口，是比较麻烦的操作。因而，比较想知道为什么不是实现成客户端长连接请求服务端这样子，这样在部署上比较方便，此外有更加少的安全问题。是否有其他架构上的考虑呢？
Currently, job-scheduling is implemented as server calling clients. However, this pattern causes troubles in client-side deployment. For eaxmple, when I deploy applications as clusters, I have to manage ports and iptables accordingly. Whatsmore, when applications are deployed in pods, it is much more difficult to make pods callable to the server side directly. Thus I want to know why not implementing job-scheduling as clients long-polling the server, which is more friendly for client-side deployment and more secure? Will there be any consideration at the architecture aspect?
5条答案
按热度按时间mqxuamgl1#
我理解定时任务是个相对低频的操作、且任务触发在很多场景下只选择一个节点执行即可；基于这种背景，所有节点与服务端长连是对网络连接的浪费。
如果是在同一个K8S集群内，可以直接使用pod ip访问非容器端口；不用pod对外暴露端口。
92dk7w1h2#
我理解定时任务是个相对低频的操作、且任务触发在很多场景下只选择一个节点执行即可；基于这种背景，所有节点与服务端长连是对网络连接的浪费。 如果是在同一个K8S集群内，可以直接使用pod ip访问非容器端口；不用pod对外暴露端口。
您说的有道理。不过我觉得总的来说，长连接对资源的消耗其实是相对较小的。就端口来说，服务器调客户端的模式要求客户端多暴露一个端口，所以端口的消耗两种模式是一样的。至于连接消耗，对比总流量来说基本可以忽略。此外，我觉得当定时任务频率较高，任务数量较多，或者节点较多时，只选择一个节点进行远程触发还是会遭受压力的。
svmlkihl3#
长连接不是只有一个tcp连接就行，还需要保活，需要心跳报文；
调度器是集群部署的，调度器伸缩，连接数会成倍的变化；
任务路由也有多种策略，只要不是广播任务，多个节点是可以分担压力的；
pbwdgjma4#
长连接不是只有一个tcp连接就行，还需要保活，需要心跳报文； 调度器是集群部署的，调度器伸缩，连接数会成倍的变化； 任务路由也有多种策略，只要不是广播任务，多个节点是可以分担压力的；
j8yoct9x5#
我现在内网调试，还得内网搭建服务器，无法直接使用公网的调度器。如果使用长连接就可以解决我这个问题