在 Kubernetes (K8s) 成为容器编排事实标准的今天，我们是否陷入了一种“为了编排而编排”的思维定势？对于中小型团队或非核心业务系统，K8s 陡峭的学习曲线和高昂的运维成本，往往成为技术债务的温床。本文旨在回归本源，深入剖析 Docker Swarm 这一“被遗忘的角落”，从其架构设计、核心原理（Raft、Gossip、Overlay网络）到工程实践，探讨一种更轻量、更易于掌控的容器编排方案。本文面向的是那些正在为技术选型而挣扎，寻求在复杂性与功能性之间找到最佳平衡点的中高级工程师和架构师。
现象与问题背景
我们经常看到这样的场景：一个不足十人的研发团队，维护着十几个微服务，却选择了一套完整的 K8s 全家桶。很快，团队的精力就被各种 YAML 配置、RBAC 权限、CRD 扩展、Service Mesh、Ingress Controller 等复杂概念所吞噬。工程师不再是业务价值的创造者，而变成了 K8s 的“配置运维工程师”。原本为了提升效率而引入的容器编排技术，反而成了效率的瓶颈。
这个问题的核心在于技术选型与业务规模、团队能力的失配。K8s 设计之初是为了解决谷歌级别的大规模、高复杂度问题，它提供了无与伦比的灵活性和扩展性，但这份“能力”是有成本的。对于许多场景，例如公司内部的后台管理系统、CI/CD 环境、中等规模的电商后端等，它们需要的是：
- 高可用性：服务不能单点，能够自动故障转移。
- 弹性伸缩：能够根据负载快速增减服务实例。
- 简单的服务发现与负载均衡：服务之间能够通过一个稳定的名称互相访问。
- 简化的部署与更新：能够轻松地进行蓝绿或滚动发布。
- 低心智负担：团队成员能够快速上手，而不是需要专门的 SRE 团队来维护。
在这种背景下，强行上马 K8s 就像用一门巨炮去打一只蚊子，不仅浪费弹药，还可能把墙打穿。Docker Swarm 作为 Docker 引擎原生内置的编排工具，提供了一个截然不同的答案：它只专注于做好容器编排的核心功能，力求以最简单的方式解决 80% 的常见问题。
关键原理拆解
要理解 Swarm 的轻量级设计哲学，我们必须深入其底层依赖的几个计算机科学基础原理。这部分，我们将以严谨的学术视角，剖析其架构的基石。
1. 分布式一致性：内置的 Raft 协议
任何一个分布式系统，其控制平面的核心都是一个高可用的状态存储。K8s 选择了外部的 etcd（其内部同样基于 Raft 协议），而 Swarm 则选择将 Raft 协议直接内置到 Manager 节点中。这是一个关键的设计决策。从原理上看，Raft 是一种用于管理复制日志（Replicated Log）的一致性算法。它将 Server 分为 Leader、Follower 和 Candidate 三种角色。所有状态变更的请求（如创建一个服务、删除一个网络）都必须由 Leader 处理。Leader 将变更作为一条日志条目，复制到大多数 Follower 节点，然后才将该条目“提交”（Commit），并应用到状态机。这个过程保证了即使在部分 Manager 节点宕机的情况下（只要存活的 Manager 数量超过半数，即满足 Quorum），整个集群的状态依然是一致且可用的。Swarm 的做法避免了独立部署和维护 etcd 集群的复杂性，极大地降低了运维门槛。
2. 服务发现与网络状态同步：Gossip 协议
Swarm 集群的节点之间如何发现彼此？网络拓扑和容器状态等信息是如何同步的？这里 Swarm 引入了 Gossip 协议。Gossip，顾名思义，就像办公室里的八卦传播。每个节点会周期性地、随机地选择几个其他节点，交换自己所知的集群状态信息。这种“病毒式”的传播方式，虽然不是强一致性的，但具备极高的容错性和最终一致性。一个节点的状态变化，会在很短的时间内传播到整个集群。这使得 Swarm 的网络层能够动态地感知到新节点的加入、节点的离开以及容器的漂移，为 Overlay 网络和负载均衡提供了基础数据。
3. 跨主机容器通信：VXLAN Overlay 网络
在 Swarm 中，你可以创建一个跨越所有节点的虚拟网络，让不同主机上的容器像在同一个局域网内一样通信。这是通过 Overlay 网络技术实现的，具体来说是 VXLAN (Virtual Extensible LAN)。其核心思想是封装。当 Host A 上的 Container A 要发送一个数据包给 Host B 上的 Container B 时，流程如下：
- 内核中的 VXLAN 驱动捕获这个 L2 帧。
- 驱动查询一个分布式的控制平面数据库（由 Raft 保证一致性），找到 Container B 所在的 Host B 的物理 IP 地址。
- 驱动将原始的 L2 帧封装在一个新的 UDP 包里，这个 UDP 包的目的 IP 就是 Host B 的物理 IP。
- 这个 UDP 包通过底层的物理网络被路由到 Host B。
- Host B 的内核接收到这个 UDP 包，发现它是一个 VXLAN 包，于是进行解封装，将内部的原始 L2 帧提取出来，并投递给目标 Container B。
整个过程对容器内的应用是完全透明的。Swarm 通过内置的 IPAM (IP Address Management) 模块为每个容器分配唯一的 IP，并通过 Raft 和 Gossip 协议维护容器 IP 与其所在主机的映射关系，从而构建起一个简单而高效的虚拟网络。
4. 服务负载均衡：内核态的 IPVS
当你在 Swarm 中创建一个拥有 3 个副本的服务 `my-api` 时，Swarm 会为这个服务分配一个虚拟 IP (VIP)。任何一个容器访问 `my-api` 这个域名时，Swarm 内置的 DNS 会将其解析到这个 VIP。关键在于，流量到达 VIP 后如何被分发到后端健康的 3 个容器实例？Swarm 在这里利用了 Linux 内核中的 IPVS (IP Virtual Server)，它是 Netfilter 框架的一部分，一个工作在 L4 的高性能负载均衡器。
当数据包到达节点的内核，目标地址是服务的 VIP 时，IPVS 会根据预设的负载均衡规则（如轮询），直接在内核空间修改数据包的目标 IP 和端口，将其DNAT（Destination NAT）到后端某个具体容器的 IP 地址，然后转发出去。因为整个过程完全在内核态完成，避免了用户态与内核态之间的数据拷贝和上下文切换，其性能远高于基于用户态代理（如 Nginx 或 HAProxy）的方案。这是 Swarm 网络性能的一大亮点。
系统架构总览
基于以上原理，一个典型的 Docker Swarm 集群架构非常简洁明了，主要由以下几个部分组成：
- Manager 节点：集群的大脑。它们运行着 Raft 协议，维护着整个集群的一致性状态（包括服务定义、网络配置、节点信息等）。其中一个 Manager 会被选举为 Leader，负责接收 API 请求和做出调度决策。为了实现高可用，生产环境通常部署 3 个或 5 个 Manager 节点。
- Worker 节点：集群的劳动力。它们只负责接收来自 Manager 的指令，运行和管理容器（在 Swarm 中称为 Task）。Worker 节点不参与 Raft 一致性协商，因此可以任意水平扩展。
- 内置 KV Store：每个 Manager 节点内部都包含一个基于 Raft 的分布式键值存储。这是 Swarm 设计的精髓，它将集群状态存储内聚在 Manager 节点中，无需像 K8s 那样依赖外部的 etcd。
- Ingress Routing Mesh：这是一个内置的、覆盖整个集群的 L4 负载均衡网络。当你发布一个服务并暴露端口时（例如 `ports: “8080:80″`），Swarm 会在每一个节点上监听 8080 端口。无论外部流量从哪个节点的 8080 端口进入，Routing Mesh 都会通过 IPVS 和 VXLAN，将流量智能地路由到承载该服务的某个健康容器上，即便这个容器位于另一个节点。这极大地简化了外部流量的接入。
从架构上看，Swarm 遵循了“内置与简化”的原则。它将分布式一致性、服务发现、负载均衡、Overlay 网络等核心功能全部内置，并提供了一个与 `docker-compose` 语法高度兼容的声明式 API，让开发者可以平滑过渡。
核心模块设计与实现
理论终究要落地。我们来看一下在实际工程中，如何使用 Swarm 定义和部署一个典型的微服务应用。这里我们用一个包含 Go Web 后端和 Redis 缓存的简单应用作为例子。
服务定义 (Stack File)
在 Swarm 中，我们使用一个 `docker-compose.yml` 文件来定义一组相互关联的服务，这组服务被称为一个 Stack。这个文件与标准的 `docker-compose` 文件几乎完全兼容，只是增加了一个 `deploy` 关键字，用于定义服务的部署、伸缩和更新策略。这部分，我们的极客工程师声音会告诉你每个配置背后的坑点。
version: '3.8'
services:
api:
image: my-company/my-go-api:1.2.0
networks:
- backend-net
deploy:
replicas: 3
update_config:
parallelism: 1
delay: 10s
order: start-first
failure_action: rollback
placement:
constraints:
- "node.role == worker"
resources:
limits:
cpus: '0.50'
memory: 256M
reservations:
cpus: '0.25'
memory: 128M
redis:
image: redis:6.2-alpine
networks:
- backend-net
deploy:
replicas: 1
placement:
constraints:
- "node.labels.storage == ssd"
networks:
backend-net:
driver: overlay
attachable: true
代码解读与工程坑点：
- `deploy` 关键字：这是 Swarm 的核心。不要再用 `docker-compose up -d –scale api=3` 这种老旧的命令式方法了。`deploy` 才是声明式的终极形态。
- `update_config`：滚动更新的精髓。`parallelism: 1` 意味着一次只更新一个副本，这是最稳妥的方式。`order: start-first` 表示先启动新版本容器，等它健康后再关闭旧版本。这会短暂地占用更多资源，但能保证服务在更新期间零中断。对于无状态服务，这是最佳实践。如果你的应用启动很慢，或者端口有冲突，可以考虑 `stop-first`。
- `placement.constraints`：调度策略。`node.role == worker` 是个好习惯，避免把业务应用调度到宝贵的 Manager 节点上。`node.labels.storage == ssd` 则展示了更高级的用法，你可以给节点打上自定义标签（`docker node update –label-add storage=ssd my-node-1`），从而将需要高性能 I/O 的服务（如这里的 Redis）精确地调度到装有 SSD 的机器上。
- `resources`：资源管理。`limits` 是硬上限，容器使用的资源绝不会超过它，否则可能被 OOM killer 干掉。`reservations` 则是 Docker 会为你的容器预留的资源。这是一个承诺，即使系统资源紧张，你的容器也能保证获得这部分资源。关键坑点：永远不要只设 `limits` 不设 `reservations`。如果没有 `reservations`，你的服务可能被调度到一个看似空闲但实际上已被其他容器预留满资源的节点上，导致启动时无法获得所需资源而失败。
- `networks`：`driver: overlay` 明确告诉 Swarm 创建一个跨主机的 VXLAN 网络。`attachable: true` 是一个调试时非常有用的选项，它允许你手动启动一个容器并附加到这个网络中，方便进行网络连通性测试。
服务发现与通信实现
在上面的 `api` 服务中，如果需要连接 Redis，代码会异常简单。
package main
import (
"context"
"fmt"
"net/http"
"github.com/go-redis/redis/v8"
)
var ctx = context.Background()
func main() {
// 这里是关键：直接使用服务名 "redis" 作为主机名。
// Swarm 内置的 DNS 会将其解析为 Redis 服务的 VIP。
// 客户端发起的 TCP 连接首先到达这个 VIP，
// 然后被节点内核的 IPVS 负载均衡到后端的 Redis 容器实例。
rdb := redis.NewClient(&redis.Options{
Addr: "redis:6379", // "redis" is the service name
Password: "",
DB: 0,
})
http.HandleFunc("/get", func(w http.ResponseWriter, r *http.Request) {
key := r.URL.Query().Get("key")
val, err := rdb.Get(ctx, key).Result()
if err != nil {
http.Error(w, "Failed to get from redis", http.StatusInternalServerError)
return
}
fmt.Fprintf(w, "Value: %s", val)
})
http.ListenAndServe(":8080", nil)
}
这段代码无需任何复杂的配置。开发者只需要关心服务名 `redis`，而底层的服务发现、VIP 分配、负载均衡等所有复杂工作都由 Swarm 自动完成。这种简洁性正是轻量级编排的核心价值所在。
性能优化与高可用设计
尽管 Swarm 很简单，但在生产环境中依然需要关注其性能和可用性。以下是一些实战中的关键考量点。
控制平面高可用
Manager 节点的高可用是整个集群稳定的基石。基于 Raft 协议，一个包含 `N` 个 Manager 的集群能够容忍 `(N-1)/2` 个节点的失效。这意味着：
- 3 Managers: 能容忍 1 个 Manager 失效。这是生产环境的最低配置。
- 5 Managers: 能容忍 2 个 Manager 失效。适用于对控制平面可用性要求更高的场景。
极客TIPS：永远不要部署偶数个 Manager。一个 4 Manager 的集群，其容错能力和 3 Manager 完全一样（都只能容忍 1 个失效），但却多了一个潜在的故障点和资源开销。
数据平面与控制平面的分离
一个重要的认知是：即使所有 Manager 节点全部宕机，已经运行的容器和网络通信（数据平面）将继续正常工作。服务会继续处理请求，容器间的通信也不会中断。此时你只是失去了管理能力（控制平面），无法进行部署、伸缩等操作。这为灾难恢复提供了宝贵的缓冲时间。
Ingress Mesh 的性能权衡
Ingress Routing Mesh 非常方便，但也引入了额外的网络封装和转发。对于需要极端低延迟的场景（如高频交易、实时游戏服务器），每一微秒都至关重要。此时，你可以选择绕过 Ingress Mesh，使用 `mode: host` 的端口映射：
ports:
- target: 80
published: 8080
protocol: tcp
mode: host
`mode: host` 会将容器的 80 端口直接绑定到其所在节点的 8080 端口，流量直接进入容器，没有任何中间层。Trade-off：你失去了内置的跨节点负载均衡能力。流量必须直接打到运行着容器的那个节点的 IP。这通常需要配合外部负载均衡器（如 Nginx、HAProxy 或云厂商的 LB），由外部 LB 来发现和管理后端节点。这是一个用便利性换取极致性能的典型案例。
处理有状态服务
这是 Swarm 相对 K8s 的最大短板。Swarm 没有像 K8s `StatefulSet` 那样强大的原生支持。在 Swarm 中处理数据库等有状态服务，通常有两种策略：
- 最佳策略：服务外置。将数据库、消息队列等部署在 Swarm 集群之外，使用云厂商的 RDS、ElastiCache 等托管服务，或者在独立的虚拟机上手动部署。让 Swarm 专注于运行无状态应用，这是最稳妥、最简单的架构。
- 次优策略：卷挂载 + 节点亲和性。如果你必须在 Swarm 中运行，可以使用 `volumes` 将数据持久化到节点的本地磁盘，并结合 `placement.constraints` 将该服务的容器永远调度到同一个节点上。这能工作，但节点的故障恢复将变得非常棘手，需要手动介入。
架构演进与落地路径
采用 Docker Swarm 并不意味着一步到位，一个务实的演进路径如下：
阶段一：单机 `docker-compose` 起步
在开发和测试阶段，使用标准的 `docker-compose` 在单机上模拟多服务环境。这是所有团队最熟悉的起点。
阶段二：基础 Swarm 集群
搭建一个最小化的生产级 Swarm 集群（3 Manager + N Worker）。将无状态应用通过 Stack 文件部署上去，利用 Ingress Mesh 处理外部流量。数据库等有状态服务全部外置。这个阶段能满足 80% 的中小型应用场景，运维成本极低。
阶段三：完善可观测性与流量管理
在集群中引入监控（Prometheus + cAdvisor + Node Exporter）和日志（EFK 或 Loki 栈）方案。在 Swarm 集群之前架设一个专业的 L7 负载均衡器或 API Gateway（如 Traefik、Nginx），实现更复杂的路由规则、TLS 卸载、认证等高级功能。此时，Swarm 的 Ingress Mesh 仍然可以作为 L4 负载均衡器与前端的 L7 网关配合工作。
阶段四：评估临界点
随着业务的极度复杂化，你可能会遇到 Swarm 的天花板。如果你发现团队有以下迫切需求，那么可能是时候考虑迁移到 K8s 了：
- 需要通过 CRD 对平台进行深度定制和扩展。
- 需要 Service Mesh (如 Istio) 来进行精细化的流量控制和可观测性。
- 需要复杂的有状态应用编排和存储卷管理。
- 需要严格的多租户隔离和基于命名空间的资源配额。
此时，由于你的应用已经完全容器化，并且遵循了十二要素（Twelve-Factor App）原则，从 Swarm 迁移到 K8s 的过程将远比从传统部署迁移要平滑。Swarm 在这个演进路径中，扮演了一个完美的“上云预科班”角色，它帮助团队以最小的成本完成了容器化和微服务化的初步改造，为未来可能的进一步演进奠定了坚实的基础。
总而言之，技术选型没有绝对的优劣，只有是否适合。Docker Swarm 凭借其简洁的设计、极低的认知成本和与 Docker 生态的无缝集成，在被 K8s 光芒掩盖的角落里，依然为追求务实、高效的工程团队提供了一个极具吸引力的选择。
延伸阅读与相关资源
-
想系统性规划股票、期货、外汇或数字币等多资产的交易系统建设，可以参考我们的
交易系统整体解决方案。 -
如果你正在评估撮合引擎、风控系统、清结算、账户体系等模块的落地方式，可以浏览
产品与服务
中关于交易系统搭建与定制开发的介绍。 -
需要针对现有架构做评估、重构或从零规划，可以通过
联系我们
和架构顾问沟通细节，获取定制化的技术方案建议。