大道至简：基于 Docker Swarm 的轻量级容器编排架构深度解析

作者： /

在云原生技术栈中，Kubernetes 凭借其强大的功能和庞大的生态系统，几乎已成为容器编排的事实标准。然而，其陡峭的学习曲线和运维复杂性，对于许多中小型团队或非核心业务系统而言，无异于“用牛刀杀鸡”。本文将回归本源，为寻求高性价比、低心智负担的工程师与架构师，深度剖析一个常被低估的“官方”方案——Docker Swarm。我们将从分布式系统原理出发，深入其网络模型与调度机制，最终给出一套可落地的轻量级容器编排架构演进路径。

现象与问题背景

在容器化早期，我们通常通过编写 Shell 脚本，在多台宿主机上执行 docker run 命令来部署应用。这种“刀耕火种”的方式很快就暴露出了一系列问题：

  • 单点故障（SPOF）： 应用部署在哪台机器上，那台机器就成了单点。一旦宕机，服务便不可用，需要人工介入恢复。

    • – 扩缩容难题： 应对流量高峰时，需要手动登录到新机器、部署容器、并修改上游负载均衡（如 Nginx）的配置。整个过程繁琐、易错且响应缓慢。

    – 服务发现的混乱： 应用间的依赖关系如何维护？通常是把下游服务的 IP 和端口硬编码在配置文件中。当服务实例发生变化（迁移、扩容）时，必须手动更新并重启上游服务，运维成本极高。

    – 状态不一致： 我们无法简单地从一个统一的视图了解整个系统的“期望状态”和“实际状态”是否一致，缺乏有效的自愈能力。

容器编排系统的出现，正是为了解决上述问题。它旨在提供一个统一的抽象层，将底层的多台物理机或虚拟机“池化”成一个巨大的资源池，实现应用的自动化部署、扩缩容、自愈和联网。当我们谈论 Kubernetes 的强大时，其实是在谈论它通过声明式 API、Controller 模式和丰富的插件化接口（CNI, CSI, CRI）对这些问题的全面解答。但对于许多场景，我们需要的或许不是一个“万能的瑞士军刀”，而是一把锋利且易于掌握的“手术刀”。Docker Swarm 正是后者的典型代表。

关键原理拆解

作为一名架构师，理解一个系统的行为必须追溯到其背后的计算机科学基础原理。Docker Swarm 的简洁并非凭空而来，而是建立在几个坚实且高效的分布式理论之上。此时，我们切换到严谨的“大学教授”视角。

  • 分布式共识与 Raft 协议： Swarm 的核心是其 Manager 节点集群。为了保证在多个 Manager 节点之间对集群状态（如服务定义、网络配置、节点信息）达成一致且无冲突的认知，它必须依赖一个分布式共识算法。Swarm 内置并实现了 Raft 协议。Raft 将共识问题分解为领导者选举（Leader Election）、日志复制（Log Replication）和安全性（Safety）三个子问题。集群中的 Manager 节点组成一个 Raft Group，选举出一个 Leader 负责处理所有写操作。任何对集群状态的变更请求，都必须由 Leader 节点作为一条日志条目（Log Entry）写入其本地日志，然后复制到大多数（Quorum）Follower 节点。只有当日志被成功复制到大多数节点后，该变更才被视为“已提交”（Committed），并应用到状态机中。这保证了即使部分 Manager 节点宕机，只要集群中仍有超过半数的 Manager 存活，集群状态就不会丢失或错乱，整个集群的控制平面依然可用。
  • Gossip 协议与状态同步： 虽然 Raft 保证了 Manager 节点间的强一致性，但在一个大规模集群中，让所有 Worker 节点都直接与 Leader 通信，会给 Leader 造成巨大压力。因此，Swarm 采用了一种更去中心化的方式——Gossip 协议，用于部分信息的传播，例如节点成员关系、网络数据库的分发等。Gossip 协议像现实世界中的“流言传播”，每个节点会周期性地、随机地选择其他几个节点，交换自己所知的信息。虽然不能保证信息的强一致性和实时性，但它最终会达到整个网络的“最终一致性”。这种方式极大地降低了中心节点的负载，提高了系统的可扩展性和容错性。
  • Overlay 网络与 VXLAN 封装： 容器化的一大挑战是跨主机容器通信。Swarm 内置了原生的 Overlay 网络解决方案，让处于不同宿主机上的容器感觉就像在同一个二层网络中，可以直接通过容器名进行通信。其底层实现通常是 VXLAN (Virtual Extensible LAN)。当容器 A（在主机 1）要发送数据包给容器 B（在主机 2）时，主机 1 的内核网络栈（具体由 Docker Engine 控制）会将原始的以太网帧（L2 Frame）封装在一个 UDP 数据包中，目标 IP 和端口是主机 2 的 IP 和 VXLAN 端口。主机 2 收到这个 UDP 包后，解开封装，取出原始的以太网帧，再投递给本地的容器 B。这个封装/解封装的过程对容器内的应用是完全透明的，极大地简化了多机部署下的网络复杂性。

系统架构总览

一个典型的 Docker Swarm 集群由以下几个核心组件构成，我们可以通过文字来描绘这幅架构图：

  • Manager 节点： 集群的大脑。通常部署 3 个或 5 个实例以实现高可用。它们共同维护着基于 Raft 协议的分布式一致性存储（Raft Log），存储了整个集群的所有配置和状态信息。只有 Leader Manager 节点能接受修改集群状态的指令（如 docker service create）。其他 Manager 节点作为热备，随时准备在 Leader 宕机时通过选举成为新的 Leader。
  • Worker 节点： 集群的肌肉。它们不参与管理和决策，唯一的职责就是从 Manager 节点接收指令，运行或停止被分配的“任务”（Task），即容器实例，并向 Manager 汇报任务状态。
  • 服务 (Service)： 这是用户与 Swarm 交互的核心抽象。它是一个声明式的定义，描述了一个应用应该如何运行，包括：使用的镜像、需要运行的副本数（Replicas）、暴露的端口、连接的网络、资源限制等。
  • 任务 (Task)： 服务的一个运行实例。如果一个服务被定义为需要 3 个副本，那么 Swarm 的调度器会在 Worker 节点上创建并运行 3 个任务。任务是 Swarm 中最小的调度单元。
  • 内置 DNS 服务器： Swarm 为每个用户创建的 Overlay 网络都提供一个内置的 DNS 服务。这使得同网络内的容器可以直接通过服务名（例如 my-api）来访问目标服务，Swarm 的 DNS 会将服务名解析为一个虚拟 IP（Virtual IP, VIP）。
  • 路由网格 (Routing Mesh)： 这是 Swarm 的一个标志性特性。当你发布一个端口时（如 -p 8080:80），Swarm 会在集群的每一个节点上都监听 8080 端口。外部流量无论访问到哪个节点的 8080 端口，都会被 Swarm 的内置负载均衡器透明地转发到该服务的一个健康的任务（容器）上，即使那个容器运行在另一台节点上。这极大地简化了外部流量的接入。

核心模块设计与实现

现在，让我们戴上“极客工程师”的帽子，深入代码和实现细节，看看这些机制是如何工作的。

集群初始化与 Raft Group 建立

一切始于 docker swarm init。当你在第一个节点上执行此命令时：


# 在第一个 manager 节点上执行
$ docker swarm init --advertise-addr 192.168.1.101
Swarm initialized: current node (dxn1...) is now a manager.

To add a worker to this swarm, run the following command:
    docker swarm join --token SWMTKN-1-... 192.168.1.101:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

底层发生的事情是：

  1. Docker Engine 在该节点上启动了 SwarmKit，这是 Swarm 模式的核心库。
  2. 创建了一个单节点的 Raft 集群。它会生成集群的根证书，并把自己的状态（节点信息、网络定义等）作为第一条日志写入 Raft Log。
  3. 生成用于 Worker 和 Manager 加入的 Token。这个 Token 实际上包含了 CA 证书的哈希和集群的 ID，用于新节点加入时的身份验证。

当一个新节点使用 docker swarm join 加入时，它会通过 TLS 与指定的 Manager 建立安全连接，验证 Token，并被接纳为集群成员。如果是 Manager 加入，它会被添加进 Raft Group，开始接收并同步 Raft Log。

服务创建与调度器工作流

当我们创建一个服务时，Swarm 的调度器和协调器开始工作。


$ docker service create \
  --name redis-server \
  --replicas 3 \
  --network my-overlay-net \
  --publish published=6379,target=6379 \
  redis:latest

这个简单的命令触发了一系列内部动作：

  1. API 请求： Docker Client 将该指令发送给 Leader Manager 节点的 API Server。
  2. 状态写入 Raft： Leader Manager 将这个服务定义（期望状态）作为一个新的条目写入 Raft Log，并复制给 Follower。
  3. 状态应用： 一旦日志被提交，Leader 的协调器（Reconciler）会对比期望状态和当前实际状态。它发现需要创建 3 个 redis-server 的任务，但当前一个都没有。
  4. 调度决策： 调度器（Scheduler）介入。它会根据默认的“spread”策略，在满足资源要求的 Worker 节点中，选择 3 个最空闲的节点来分布这 3 个任务，以提高可用性。
  5. 任务分发： Leader Manager 通过加密的 gRPC 连接，向被选中的 3 个 Worker 节点发送指令，要求它们分别启动一个基于 redis:latest 镜像的容器。
  6. 状态回报： Worker 节点在启动容器后，会向 Manager 汇报任务的当前状态（如 RUNNING, FAILED）。

这个过程是一个持续的协调循环。如果某个 Worker 节点宕机，Manager 会在一段时间后检测到该节点上的任务状态为不可达，协调器会再次触发调度，在其他健康的 Worker 节点上重新创建一个任务，以始终维持 replicas=3 的期望状态。

服务发现与负载均衡的内核魔法

Swarm 最为人称道的就是其开箱即用的服务发现和负载均衡。假设我们有一个 api-gateway 服务和一个 user-service 服务，它们都在同一个 Overlay 网络中。


// 在 api-gateway 容器内部的代码
// 无需关心 user-service 的 IP 地址
// 直接使用服务名
resp, err := http.Get("http://user-service:8080/users")

这是如何工作的？

  • 内置 DNS： 当 api-gateway 容器发起 DNS 请求解析 user-service 时，请求被 Swarm 内置的 DNS 服务器截获。DNS 服务器不会返回某个具体容器的 IP，而是返回该服务在 Overlay 网络中的虚拟 IP (VIP)。
  • IPVS 介入： 当 api-gateway 容器向这个 VIP 发送 TCP/IP 包时，数据包到达其所在宿主机的内核网络栈。Linux 内核中的 IPVS (IP Virtual Server，LVS 的一部分) 规则早已被 Docker Engine 配置好。IPVS 发现目标 IP 是一个它所管理的 VIP，就会根据预设的负载均衡算法（如轮询），从后端真实的容器 IP 地址列表中选择一个，然后通过 DNAT (Destination Network Address Translation) 将数据包的目标 IP 修改为该容器的真实 IP，再将数据包转发出去。

而对于外部流量的路由网格 (Routing Mesh)，原理非常相似。当服务端口被发布时，集群中所有节点都会利用 IPVS 创建一个监听规则。外部流量进入任意一个节点的发布端口，IPVS 都会将其负载均衡到服务对应的所有健康容器上，无论这些容器分布在哪个节点。这一切都发生在内核态，效率非常高。

性能优化与高可用设计

在严肃的生产环境中，我们必须对架构的 Trade-off 有清醒的认识。

  • Swarm vs. Kubernetes：简洁性与复杂性的权衡。 这是最核心的权衡。Swarm 的学习曲线平缓，运维简单，核心功能内置，非常适合资源有限、追求快速交付的团队。而 Kubernetes 提供了无与伦比的灵活性、可扩展性（CRD, Operator）和庞大的社区生态，但代价是极高的复杂性。选择 Swarm 意味着你放弃了 K8s 生态中的某些高级功能（如 Istio 服务网格的精细化流量控制、强大的存储卷编排等），换取了更低的运维成本和心智负担。
  • Manager 节点高可用： 生产环境必须部署奇数个（3 或 5 个）Manager 节点。3 个 Manager 允许 1 个节点失效，5 个 Manager 允许 2 个节点失效。这是由 Raft 协议的 Quorum 机制决定的。务必将 Manager 节点分散部署在不同的物理机、机架甚至可用区，以避免单点物理故障。
  • 路由网格的性能考量： Routing Mesh 虽然方便，但它引入了额外的网络跳数和 NAT 开销。对于需要极致低延迟的场景（如实时交易系统），这个开销可能无法接受。此时，你可以选择绕过它：
    • DNS Round Robin (DNSRR) 模式： 在创建服务时使用 --endpoint-mode dnsrr。这样，DNS 查询服务名会直接返回所有健康容器的真实 IP 列表，由客户端自己选择一个进行连接。这减少了内核的转发开销，但需要客户端有相应的负载均衡和重试逻辑。
    • Host 模式网络： 使用 --publish mode=host，容器将直接占用宿主机的端口。这提供了最高的网络性能，但失去了端口冲突检测和灵活性，一个端口只能被一个容器实例占用。
  • 有状态服务的挑战： Swarm 对有状态服务的支持相对薄弱。虽然可以通过卷插件（Volume Plugin）对接外部存储（如 Ceph, GlusterFS），但其编排能力远不如 Kubernetes 的 StatefulSet 和 PersistentVolume/PersistentVolumeClaim 体系成熟。对于数据库、消息队列等核心有状态应用，更稳妥的方案是将其部署在 Swarm 集群之外，例如使用云厂商的 RDS 或自建高可用集群，Swarm 内的无状态应用通过网络连接它们。

架构演进与落地路径

一个务实的架构演进路径，可以帮助团队平滑地从传统部署迁移到 Swarm 容器编排。

  1. 第一阶段：标准化与单机 Swarm。 首先在开发和测试环境，使用 Docker Compose v3 格式来定义所有应用栈。然后，在单台服务器上启用 Swarm 模式（docker swarm init），使用 docker stack deploy -c docker-compose.yml myapp 进行部署。这个阶段的目标是让团队熟悉声明式的部署方式，统一交付产物，即使只有一个节点，也能享受到服务定义和滚动更新带来的便利。
  2. 第二阶段：最小化高可用集群。 搭建一个由 3 个 Manager 节点和若干 Worker 节点组成的生产集群。将无状态应用（如 Web 服务器、API 网关、微服务业务逻辑）迁移到 Swarm 上。充分利用内置的 Overlay 网络进行服务间通信，使用 Routing Mesh 统一流量入口。数据库等有状态服务暂时保留在集群外。
  3. 第三阶段：完善监控与日志。 任何生产系统都离不开可观测性。集成 Prometheus + Grafana 进行监控。可以使用 Node Exporter 收集主机指标，cAdvisor 收集容器指标。对于日志，部署一个集中的日志栈，如 EFK (Elasticsearch, Fluentd, Kibana) 或更轻量的 Loki + Promtail 组合，通过 Docker 的日志驱动（Logging Driver）将所有容器日志发送到中心位置。
  4. 第四阶段：探索有状态服务与高级部署。 当团队对 Swarm 的运维已经非常熟练后，可以开始尝试将一些对性能要求不那么苛刻的有状态应用（如内部缓存 Redis、配置中心）容器化。研究并测试 Docker Volume Plugin，为这些服务提供持久化存储。同时，深入利用服务定义的更多高级特性，如滚动更新策略（--update-delay, --update-parallelism），为关键应用实现更平滑的发布流程。

总而言之，Docker Swarm 并非 Kubernetes 的“失败竞品”，而是在特定生态位上一个极其优秀的选择。它精准地把握了“简洁”与“够用”的平衡点，为那些希望拥抱容器编排优势，但又被 K8s 复杂性劝退的团队，提供了一条清晰、务实且高效的路径。对于架构师而言，选择最合适的工具，而非最强大的工具，永远是技术决策的第一要义。

延伸阅读与相关资源

  • 想系统性规划股票、期货、外汇或数字币等多资产的交易系统建设，可以参考我们的
    交易系统整体解决方案。
  • 如果你正在评估撮合引擎、风控系统、清结算、账户体系等模块的落地方式，可以浏览
    产品与服务
    中关于交易系统搭建与定制开发的介绍。
  • 需要针对现有架构做评估、重构或从零规划，可以通过
    联系我们
    和架构顾问沟通细节，获取定制化的技术方案建议。
滚动至顶部