第三章：核心概念与术语
各位同学，今天我们来聊聊分布式系统里最基础、也最容易混淆的几个概念。说实话，我见过不少做了两三年的工程师，聊起节点、服务、代理这些词，还是各说各话。这其实挺危险的——概念不清，设计出来的系统就容易出问题。
我个人习惯，在开始任何分布式系统设计之前，先把这几个术语的定义敲死。咱们一个一个来。
3.1 节点（Node）
节点，说白了就是一台能干活的计算单元。可以是物理机、虚拟机，也可以是容器。我当年在做一个金融交易系统时，团队里有人把「节点」和「服务器」混着用，结果架构文档写得乱七八糟，后来重构时吃了大亏。
节点有几个关键属性：
- 唯一标识：每个节点必须有全局唯一的 ID，比如 IP+端口，或者 UUID
- 状态：在线、离线、故障、恢复中
- 资源：CPU、内存、磁盘、网络带宽
- 角色：主节点、从节点、协调节点
核心要点：节点是分布式系统的最小物理/虚拟单元。一个节点可以运行多个服务，但一个服务通常部署在多个节点上。
3.2 服务（Service）
服务是什么？是提供特定功能的软件模块。比如用户认证服务、订单处理服务、日志收集服务。我经常跟新人说：节点是硬件视角，服务是软件视角。
举个例子，你有一个订单服务，它可能部署在 3 个节点上。这 3 个节点各自运行着订单服务的实例，对外表现为一个逻辑单元。
服务的关键特征：
- 接口：通过 API 暴露功能，比如 REST、gRPC
- 生命周期：启动、运行、停止、升级
- 依赖：可能依赖数据库、消息队列、其他服务
- 治理：限流、熔断、降级、负载均衡
我的经验：设计服务时，一定要明确它的「边界」。我曾经把一个支付服务和订单服务揉在一起，结果每次改支付逻辑都要重新部署订单模块，运维同学差点跟我翻脸。
3.3 代理（Agent）
代理这个词，在分布式系统里有点特殊。它不是业务逻辑的一部分，而是负责执行管理指令的驻留程序。
你想想看，一个分布式系统可能有几百个节点，你不可能手动去每台机器上执行命令。这时候就需要代理——它常驻在每个节点上，接收来自控制中心的指令，然后在本机执行。
代理的典型职责：
- 采集节点指标（CPU、内存、磁盘）
- 执行任务（启动服务、停止服务、部署代码）
- 上报心跳
- 处理配置变更
注意：代理本身不能太「重」。我见过一个团队把代理做成了全能工具，结果代理自己占用了 20% 的 CPU，这就不对了。代理应该轻量、稳定、低资源消耗。
3.4 任务（Task）
任务是分布式系统里最具体的执行单元。一个任务可以是一次数据备份、一次模型训练、一次日志清理。
任务的生命周期通常包括：
| 状态 | 说明 |
|---|---|
| PENDING | 已创建，等待调度 |
| RUNNING | 正在执行 |
| SUCCEEDED | 执行成功 |
| FAILED | 执行失败 |
| RETRYING | 失败后重试中 |
| CANCELLED | 被取消 |
嗯，这里要注意：任务和服务的区别。服务是长期运行的，比如 Web 服务器；任务是短期执行的，跑完就结束。我遇到过有人把定时任务当成服务来设计，结果资源浪费严重。
3.5 工作流（Workflow）
工作流，就是一组有依赖关系的任务组合。比如你要做一次数据迁移：先备份、再转换、再校验、最后切换。这四个任务之间有先后顺序，有的可以并行，有的必须串行。
工作流的核心要素：
- DAG（有向无环图）：定义任务之间的依赖关系
- 状态机：管理整个工作流的运行状态
- 容错机制：某个任务失败后，是重试、跳过还是终止整个工作流
- 补偿操作：回滚已执行的任务
避坑指南：我曾经设计过一个工作流引擎，没有考虑「超时」问题。结果有个任务卡住了 3 天，后面的任务全在等它。从那以后，我每个任务都强制设置超时时间，并且加上「超时后自动失败」的逻辑。
3.6 概念关系图
下面这张图，是我自己画的概念关系图。每次带新人，我都会先让他们看这张图。
说白了，这五个概念构成了分布式系统的骨架。节点是基础设施，服务是业务能力，代理是管理触手，任务是执行单元，工作流是编排逻辑。你把这个关系理清了，后面学调度、容错、一致性这些内容，就会轻松很多。
我的建议：刚开始接触分布式系统时，别急着看代码。先把这几个概念画在纸上，自己讲一遍。能讲清楚，才算真懂了。
公众号:蓝海资料掘金营，微信deep3321