3. Fabric网络核心概念：Peer节点、Orderer节点、CA、通道、链码
好，咱们进入正题。这一章要聊的，是Fabric网络里最核心的几个概念。说白了，你搭建智能家居的Fabric网络，本质上就是在跟这几个东西打交道。
我记得刚接触Fabric那会儿，看了半天文档，Peer、Orderer、CA、Channel、Chaincode……这些词堆在一起，确实有点懵。但后来我发现，只要搞懂它们各自扮演什么角色，整个网络就清晰了。
咱们一个一个来拆解。
3.1 Peer节点：账本的“保管员”与“执行者”
Peer节点，你可以把它理解成区块链网络里的“节点服务器”。它干两件核心的事：保管账本和执行链码。
- 保管账本：每个Peer节点都保存着一份或多份账本的副本。你想想看，智能家居里，你家空调的开关记录、门锁的授权记录，这些数据最终都会存在Peer节点的账本里。
- 执行链码：当你要查询或更新数据时，请求会先发到Peer节点，由它调用链码（也就是智能合约）来执行具体的业务逻辑。
这里有个关键点：Peer节点不负责“排序”和“出块”。它只负责验证交易、维护账本。我在项目里见过有人把Peer当Orderer用，结果网络乱成一锅粥。千万别这么干。
Peer节点的两种角色
- 背书节点（Endorsing Peer）：收到交易提案后，模拟执行链码，并返回“背书结果”。
- 提交节点（Committing Peer）：接收Orderer节点打包好的区块，验证后追加到本地账本。
一个Peer可以同时扮演这两种角色。我个人习惯把核心的Peer都设为背书节点，这样能提高交易处理的灵活性。
3.2 Orderer节点：交易的“排序员”与“打包工”
Orderer节点，它的职责非常纯粹：给交易排好顺序，然后打包成区块。
你可能会问：“为什么需要单独一个角色来干这个？”
原因很简单：去中心化网络里，谁来决定交易的先后顺序？如果每个Peer自己决定，那账本肯定对不上。Orderer就是那个“裁判”，它接收所有经过背书的交易，按时间（或某种策略）排好序，然后打包成区块，广播给所有Peer。
我曾经在一个项目中，Orderer节点配置了单节点（solo模式），结果生产环境一上线就扛不住了。后来换成了Kafka（现在叫Raft）共识，才稳定下来。所以，生产环境千万别用solo模式，至少用Raft共识，3个Orderer起步。
避坑指南：Orderer节点不保存业务数据，它只保存“区块元数据”和“通道配置”。所以，Orderer的存储压力远小于Peer。但它的网络和CPU压力很大，尤其是交易量大的时候。
3.3 CA（证书颁发机构）：网络的“身份证中心”
Fabric是一个许可制的区块链网络。什么意思？就是不是谁都能进来。每个节点、每个用户、每个管理员，都得有合法的“身份证”。这个身份证，就是CA颁发的数字证书。
CA的核心功能就两个：
- 注册：给新成员（Peer、Orderer、用户）创建身份。
- 颁发证书：生成公钥和私钥，确保通信加密和签名验证。
在智能家居场景里，你家智能门锁的固件、手机App、甚至云端的控制服务，都需要有自己的证书。没有证书，连网络都进不去。
Fabric官方提供了Fabric-CA组件，但我在实际项目中，更倾向于用企业级的CA（比如EJBCA），或者直接用OpenSSL手动生成证书。Fabric-CA在管理大量动态身份时，确实方便，但如果你网络规模不大，手动生成反而更可控。
注意：私钥一旦泄露，就等于你的身份被盗用了。所以，私钥的存储一定要用硬件安全模块（HSM）或者至少加密存储。我曾经见过有人把私钥明文放在配置文件里……嗯，后果很严重。
3.4 通道：数据的“隔离舱”
通道，是Fabric里实现数据隔离的核心机制。你可以把它理解成一个独立的“子网络”。
每个通道里，有自己独立的账本、独立的链码、独立的成员列表。通道外的节点，看不到通道内的任何数据。
举个例子：
- 你家智能门锁的数据，放在“门锁通道”里。
- 智能空调的数据，放在“空调通道”里。
- 两个通道的数据完全隔离，互不干扰。
这样做的好处很明显：隐私保护。你不想让空调厂商知道你门锁的开锁记录吧？通道就是干这个的。
我建议，每个业务场景建一个独立的通道。别把所有业务塞到一个通道里，那样既没有隐私，性能也会下降。
3.5 链码：业务的“逻辑引擎”
链码，就是Fabric里的智能合约。它是一段运行在Peer节点上的程序，定义了业务逻辑。
在智能家居里，链码可以干这些事：
- 授权管理：谁可以控制哪个设备。
- 状态记录：记录设备的开关状态、温度设定等。
- 规则执行：比如“当温度超过30度时，自动开启空调”。
链码的编写语言，官方支持Go、Node.js、Java。我个人强烈推荐Go语言，性能好，部署简单，而且Fabric的底层也是Go写的，兼容性最好。
这里有个常见的误区：链码不是数据库。它不能直接执行复杂的SQL查询。链码操作的是世界状态（World State），本质上是一个键值对数据库（LevelDB或CouchDB）。所以，设计链码时，要考虑好数据的存储结构。
链码的生命周期
- 打包：将链码代码打包成tar.gz文件。
- 安装：将包安装到指定的Peer节点上。
- 审批：通道内的组织对链码定义进行审批。
- 提交：审批通过后，将链码定义提交到通道，链码正式生效。
记住：链码安装和链码定义提交是两回事。安装只是把代码放到Peer上，提交才是让它“跑起来”。
3.6 核心关系一览
说了这么多，咱们用一张图来总结一下这几个核心概念的关系。
从这张图可以看得很清楚：CA是信任的起点，它给Peer和Orderer颁发身份；Peer和Orderer是网络的骨架，它们通过通道连接在一起；而链码，则是跑在通道里的业务逻辑。
这五个概念，就是Fabric网络的基石。你搭建智能家居网络时，每一步都会跟它们打交道。搞懂了它们，后面的实战就会顺畅很多。