我们想知道 Docker 网格使用什么算法将请求路由到容器。原因如下：
我们将应用程序部署到自托管的 docker 集群。我们使用 docker 路由网格将流量引导到各个节点，如下所示：
- 互联网 ->
- 防火墙 ->
- 加载管理器 (nginx) ->
- nginx“最少连接”路由到三个群管理器->
- docker 网格 ->
- 在三个不同的非管理器 Docker 节点上运行的六个应用容器中的任何一个
我们的开发人员怀疑 Docker Mesh 正在循环路由流量，这可能会导致某些应用容器因请求缓慢而过载，而其他容器则未得到充分利用。如果开发人员是对的，我们不应该使用 Docker Mesh，而应该使用负载导向器，使用比循环更智能的算法将流量导向各个容器。
另一方面，如果 docker mesh 跟踪每个容器中有多少请求，并将流量传送到请求最少的容器，那么我们就不需要绕过 docker mesh 的工作了。
问题
docker mesh 使用什么算法将流量引导到可用容器？是简单循环吗？
我们的 nginx 配置
我们的 nginx 从互联网接收流量并将其代理到三个 docker 管理器节点中的任意一个上的 docker 网格：
upstream document_service {
least_conn;
server dockermgr1.nosuchdomain:8402;
server dockermgr2.nosuchdomain:8402;
server dockermgr3.nosuchdomain:8402;
}
server {
...
proxy_pass http://document_service;
我们的 docker-compose 配置
docker-compose 文件将服务配置为在三个 docker runner 节点上有六个副本：
version: "3.4"
services:
documentsservice:
image: ${IMAGE_LOCATION}documents_service/documentsservice:prod-${COMPOSE_BUILD_TAG:-latest}
container_name: documentsservice
ports:
- "8402:80"
...
deploy:
replicas: 6
placement:
constraints: [node.role != manager]
resources:
limits:
memory: 1024MB
update_config:
parallelism: 1
order: start-first
failure_action: continue
版本
- docker-ce 5：19.03.12~3-0~debian-buster
- nginx-full 1.14.2-2+deb10u4
- docker-compose：1.27.4
答案1
网状路由很可能仅采用循环方式
我深入研究了docker 源。我找到了各种路由方法的参考资料，但似乎唯一使用的方法是循环路由。我还在 docker 论坛上发现了一个问题，似乎证实了网状路由仅是循环路由。
检查来源
在供应商/github.com/moby/ipvs/constants.go这是有趣的路由策略列表：
const (
// RoundRobin distributes jobs equally amongst the available
// real servers.
RoundRobin = "rr"
// LeastConnection assigns more jobs to real servers with
// fewer active jobs.
LeastConnection = "lc"
// DestinationHashing assigns jobs to servers through looking
// up a statically assigned hash table by their destination IP
// addresses.
DestinationHashing = "dh"
// SourceHashing assigns jobs to servers through looking up
// a statically assigned hash table by their source IP
// addresses.
SourceHashing = "sh"
// WeightedRoundRobin assigns jobs to real servers proportionally
// to there real servers' weight. Servers with higher weights
// receive new jobs first and get more jobs than servers
// with lower weights. Servers with equal weights get
// an equal distribution of new jobs
WeightedRoundRobin = "wrr"
// WeightedLeastConnection assigns more jobs to servers
// with fewer jobs and relative to the real servers' weight
WeightedLeastConnection = "wlc"
)
然而这些常量中唯一常用的是 RoundRobin：
wayne@treebeard:~/temp/docker-src/moby$ ack 'ipvs\.(RoundRobin|LeastConnection|DestinationHashing|SourceHashing|WeightedRoundRobin|WeightedLeastConnection)'
libnetwork/service_linux.go
117: SchedName: ipvs.RoundRobin,
225: s.SchedName = ipvs.RoundRobin
虽然这只是对源代码的粗略查看，但我发现没有明显的方法可以将路由模式配置为 RoundRobin 以外的其他模式。
Docker 论坛上的相关问题
Docker 论坛上的一个问题似乎证实了网格可用的唯一路由方法是循环：
https://forums.docker.com/t/configure-swarm-mode-routing-mesh-load-balancing-method/75413
我读到过，Swarm 模式路由网格负载均衡器使用循环（https://success.docker.com/article/ucp-service-discovery#externalloadbalancing(swarmmoderoutingmesh)15）。
是否有可能配置群模式路由网格的负载平衡方法（例如（加权）最小连接、源/目标散列……）？
答案是：
swarm 模式路由网格（又名 ingress）作用于第 4 层，并且不知道您要求的那些配置详细信息。文档可在此处找到：https://docs.docker.com/engine/swarm/ingress/45. 您粘贴的链接针对的是“为什么使用联锁代理作为优势”。
如果您拥有企业许可证：您有权使用 Interlock 代理，它是 UCP 的一部分。它是一个第 7 层反向代理/负载均衡器。当我尝试 Interlock 的早期版本时，它有一些限制。从我在更改日志中读到的内容来看，当前版本似乎接近 traefik 能够做的事情。
如果您在 Docker-CE 上运行，您可能需要看看 traefik。