📚 课程目录第2章核心概念与术语

2、核心概念与术语：节点、服务、特征、会话、发现机制、连接管理、数据传输通道

好，咱们正式开始啃核心概念。这一章说白了就是分布式软总线的“通用语言”。你不把这些术语搞明白，后面看代码、调问题会非常痛苦。我当年刚接触时，就吃过“特征”和“服务”傻傻分不清的亏，调试了一整天……嗯，咱们一个个来。

2.1 节点（Node）—— 总线上的“人”

节点，就是分布式系统中一个独立的计算单元。可以是一部手机、一台电视、一个智能音箱，甚至是一个传感器。每个节点都有一个唯一的标识符，通常是设备ID或网络地址。

我个人习惯把节点想象成“人”。每个人有自己的名字（ID）、能力（服务）和当前状态（在线/离线）。节点之间通过软总线“对话”，而不是直接物理连线。

  关键属性：
  节点ID：全局唯一，通常由设备硬件信息+随机数生成
节点类型：手机、平板、PC、IoT设备等
节点状态：在线、离线、忙碌、休眠
节点能力：支持的协议、算力等级、电池状态

我的经验：节点ID的生成策略很关键。我曾经在一个项目中直接用MAC地址做ID，结果用户换网卡后设备“变”了，导致会话全部失效。后来改用设备证书+随机数组合，才彻底解决。

2.2 服务（Service）—— 节点能干什么

服务，就是节点对外提供的能力。比如“播放音乐”、“打开摄像头”、“传输文件”。每个服务都有一个服务类型和实例ID。

你想想看，一个节点可以同时提供多个服务。比如你的手机，既能当遥控器（服务A），又能当屏幕投射源（服务B），还能当文件服务器（服务C）。

服务属性	说明	示例
服务类型	服务的功能分类	`media.player`、`file.transfer`
服务实例ID	同一类型下的唯一实例	`player_001`
服务版本	兼容性控制	`v2.1.0`
服务状态	是否可用	`available`、`busy`

避坑指南：服务版本号一定要严格语义化。我曾经见过一个团队，服务版本从v1直接跳到v3，中间v2的兼容层没做，结果老节点发现新服务后直接崩溃。记住：向后兼容是分布式系统的生命线。

2.3 特征（Feature）—— 服务的“身份证”

特征，是描述服务具体能力的元数据。说白了，就是服务的详细说明书。比如一个“播放器”服务，它的特征可能包括：支持哪些格式、最大分辨率、是否支持字幕等。

特征通常以键值对的形式存在：

{
  "service_type": "media.player",
  "features": {
    "supported_formats": ["mp4", "mkv", "avi"],
    "max_resolution": "4K",
    "subtitle_support": true,
    "audio_channels": 5.1
  }
}

为什么需要特征？因为发现机制要靠它来精确匹配。你想想看，如果只是广播“我有播放服务”，但不知道它能播什么格式，那调用方还得再问一次，效率太低了。

  特征 vs 服务：
  服务：回答“我能干什么”
特征：回答“我干得怎么样、能干哪些具体活”

2.4 会话（Session）—— 一次完整的对话

会话，是两个节点之间一次完整的交互过程。从建立连接开始，到数据传输结束，最后关闭连接。会话有生命周期，通常包含：

创建：双方协商参数，分配资源
维持：心跳检测，保活机制
传输：实际数据交换
销毁：释放资源，清理状态

我记得有一次线上事故，就是因为会话销毁时没有正确释放端口，导致节点端口耗尽，所有新连接都被拒绝。从那以后，我特别强调会话的“有始有终”。

会话ID生成：建议使用UUID或Snowflake算法。不要用自增ID，分布式环境下自增ID冲突概率太高。

2.5 发现机制（Discovery）—— 怎么找到对方

发现机制，是分布式软总线的“雷达”。节点上线后，需要让其他节点知道自己存在；调用方需要找到提供目标服务的节点。

常见的发现方式有两种：

方式	原理	优点	缺点
广播发现	节点上线后广播“我来了”	实现简单，无需中心节点	网络开销大，不适合大规模集群
中心化发现	所有节点向注册中心注册	可控性强，支持ACL	单点故障风险
分布式哈希表	基于DHT的P2P发现	去中心化，扩展性好	实现复杂，延迟较高

我个人在实际项目中，小规模局域网（<50节点）用广播发现，简单粗暴；大规模场景用中心化发现+缓存降级，兼顾性能和可靠性。

2.6 连接管理（Connection Management）—— 把线牵好

发现对方之后，就要建立连接了。连接管理负责：

建立连接：三次握手、TLS协商、认证鉴权
维持连接：心跳包、超时重传、流量控制
断开连接：优雅关闭、资源回收
重连机制：断线后自动恢复

我曾经踩过的坑：连接超时时间设得太短（3秒），结果在弱网环境下频繁断连重连，反而加重了网络负担。后来调整为“指数退避+初始5秒”，效果好了很多。

连接状态机大概是这样的：

CLOSED → SYN_SENT → ESTABLISHED → DATA_TRANSFER → CLOSE_WAIT → CLOSED
         ↑              ↓
         └── RETRY ─────┘

2.7 数据传输通道（Data Channel）—— 数据的高速公路

连接建立后，数据怎么传？这就是数据传输通道的事。通道可以基于不同的底层协议：

通道类型	底层协议	适用场景
消息通道	TCP/UDP	小数据量、实时性要求高
流通道	QUIC/WebRTC	音视频、大文件传输
共享内存通道	本地IPC	同设备进程间通信

通道还支持多路复用——一条物理连接上跑多个逻辑通道。这样就不用为每个服务单独建连接，节省资源。

  通道的核心参数：
  带宽：最大传输速率
延迟：数据从发送到接收的时间
可靠性：是否保证送达、顺序
安全性：是否加密传输

2.8 知识体系总览

下面这张图把本章的核心概念串起来了。你可以看到，从节点到通道，每一步都有明确的职责和关系。

2.9 小结

这一章的概念比较多，但它们是整个分布式软总线的基石。我建议你对照上面的SVG图，自己画一遍流程，把每个术语的职责和关系理清楚。

记住一句话：节点是主体，服务是能力，特征是细节，会话是过程，发现是找路，连接是搭桥，通道是跑车。