Fabric 2.0 EtcdRaft分布式集群部署实战指南

发布时间:2026/9/19 9:16:52
Fabric 2.0 EtcdRaft分布式集群部署实战指南 简介本资源是一份面向区块链开发工程师与联盟链部署实践者的 Hyperledger Fabric 2.0 分布式集群部署实战指南聚焦企业级生产环境落地痛点系统解决多节点协同、共识配置简化与链码生命周期管理等核心问题。文档为单个PDF文件554KB内容结构完整涵盖Fabric 2.0四大关键升级模块化链码生命周期打包→安装→批准→提交→升级、基于EtcdRaft的轻量共识机制、智能合约去中心化治理流程以及Alpine镜像带来的资源优化同时提供从CentOS基础环境搭建Docker/Go/Git/fabric-binaries、三节点分布式拓扑规划orderer0/peer0.org1等IP映射与防火墙配置到证书生成、通道创建及网络启停的全流程实操细节。目前已有6482人学习下载适合具备Linux与容器基础、正开展Fabric联盟链POC或生产部署的技术人员深度参考。1. 为什么 Fabric 2.0 分布式集群必须用 EtcdRaft而不是“先搭起来再说”很多团队在部署 Hyperledger Fabric 时习惯性复用 1.x 的 Solo 或 Kafka 模式——结果在生产环境一上线就卡在共识延迟、节点失联、证书校验失败三连击。Fabric 2.0 的核心转折点不是功能堆叠而是共识层彻底重构EtcdRaft 不再依赖外部消息中间件所有排序节点orderer自带 Raft 日志复制与 Leader 选举能力节点间通过 TLS 双向认证直连通信。这意味着你不再需要单独维护 Kafka 集群、ZooKeeper 服务和复杂的 ACL 策略三台物理机即可构成高可用排序服务且故障恢复时间从分钟级压缩到秒级。本文实操的 3 节点集群192.168.137.100/101/102正是基于这一设计范式orderer0–2 构成 Raft 共识组peer0.org1 和 peer0.org2、peer1.org2 分属两个组织全部启用 mTLS 双向验证。它不适用于 PoW 公链场景但对供应链溯源、跨境贸易单证、医疗数据共享等联盟链高频写入强一致性要求的业务是当前最轻量、最可控、最易审计的 Fabric 生产部署形态。2. Fabric 2.0 分布式集群的底层支撑Docker EtcdRaft mTLS 三位一体Fabric 2.0 分布式集群不是“把容器跑起来就行”而是三个技术层深度咬合的结果Docker 提供隔离运行时EtcdRaft 定义节点协作逻辑mTLS 则是所有通信的准入凭证。任何一层配置偏差都会导致connection refused、x509: certificate signed by unknown authority或context deadline exceeded这类典型错误。下面从环境准备开始逐层拆解关键动作与参数含义。2.1 基础环境统一CentOS Docker 24.0.7 Go 1.14 docker-compose 1.22.0Fabric 对基础组件版本有硬性约束Go 必须 ≥1.13因 Fabric 2.0 使用 modules 机制Docker 推荐 ≥20.10避免 overlay2 驱动兼容问题docker-compose 必须 ≥1.21支持extra_hosts在多节点间解析 host 映射。以下命令在三台服务器上逐条执行并验证输出# 关闭防火墙生产环境应开放特定端口非直接禁用 sudo systemctl stop firewalld sudo systemctl disable firewalld # 更新 yum 并安装基础工具 sudo yum update -y sudo yum install -y yum-utils device-mapper-persistent-data lvm2 # 添加 Docker 官方源注意使用阿里云镜像源可加速 sudo yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo # 安装指定版本 Docker避免自动升级破坏兼容性 sudo yum install -y docker-ce-24.0.7 docker-ce-cli-24.0.7 containerd.io # 启动并设为开机自启 sudo systemctl start docker sudo systemctl enable docker # 验证 Docker 版本及 daemon 状态 docker version | grep Version: systemctl is-active docker # 应返回 active提示若docker version报错Cannot connect to the Docker daemon检查是否遗漏sudo systemctl start docker若docker info显示WARNING: No swap limit support属 CentOS 内核限制不影响 Fabric 运行可忽略。接着安装 Go 1.14Fabric 2.0 编译链码和二进制工具链必需# 下载并解压 Go使用国内镜像加速 wget https://golang.google.cn/dl/go1.14.linux-amd64.tar.gz sudo tar -C /usr/local -xzf go1.14.linux-amd64.tar.gz # 配置全局环境变量写入 /etc/profile 保证所有用户生效 echo export PATH$PATH:/usr/local/go/bin | sudo tee -a /etc/profile echo export GOROOT/usr/local/go | sudo tee -a /etc/profile echo export GOPATH/root/go | sudo tee -a /etc/profile # 生效配置并验证 source /etc/profile go version # 应输出 go version go1.14 linux/amd64最后安装 docker-compose 1.22.0注意Fabric 官方脚本bootstrap.sh依赖此版本解析 YAML 中的extra_hosts# 下载指定版本避免使用 pip install 导致权限混乱 sudo curl -L https://github.com/docker/compose/releases/download/1.22.0/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose sudo chmod x /usr/local/bin/docker-compose docker-compose --version # 应输出 docker-compose version 1.22.02.2 Fabric 二进制与镜像拉取bootstrap.sh 的真实作用与替代方案Fabric 官方bootstrap.sh脚本本质是自动化下载三类资源fabric-samples含first-network、test-network等示例目录提供crypto-config.yaml和configtx.yaml模板fabric binariesconfigtxgen、cryptogen、peer、orderer等可执行文件存于fabric-samples/scripts目录Docker imageshyperledger/fabric-peer、hyperledger/fabric-orderer、hyperledger/fabric-tools等镜像标签为2.0.0或latest。但实际部署中直接运行./bootstrap.sh存在两大风险一是网络不稳定导致镜像拉取中断尤其在国内二是latest标签可能指向非预期版本。更可靠的做法是分步控制# 创建标准工作目录结构 mkdir -p ~/fabric-cluster/{channel-artifacts,crypto-config,scripts} cd ~/fabric-cluster # 手动下载 fabric-samplesGitHub Release 页面获取稳定版 wget https://github.com/hyperledger/fabric/archive/refs/tags/v2.0.0.tar.gz tar -xzf v2.0.0.tar.gz mv fabric-2.0.0/scripts ./scripts mv fabric-2.0.0/test-network ./test-network # 备用参考 # 下载并校验二进制文件官方 SHA256 列表见 fabric GitHub release cd scripts curl -O https://raw.githubusercontent.com/hyperledger/fabric/v2.0.0/scripts/bootstrap.sh chmod x bootstrap.sh # 修改 bootstrap.sh注释掉镜像拉取部分第 152 行起保留二进制下载 sed -i 152,170s/^/#/ bootstrap.sh # 执行仅下载二进制跳过耗时的 docker pull ./bootstrap.sh -s -d -t 2.0.0 # 将二进制复制到系统路径便于全局调用 sudo cp ../scripts/* /usr/local/bin/注意-s参数跳过 samples 下载已手动获取-d跳过 docker 镜像拉取-t 2.0.0指定版本。执行后/usr/local/bin/下应存在configtxgen、cryptogen等可执行文件且configtxgen --version输出Fabric 2.0.0。2.3 EtcdRaft 共识配置的核心configtx.yaml 中 Consenters 字段的语义与校验Fabric 2.0 的configtx.yaml文件中Profiles.SampleMultiNodeEtcdRaft.EtcdRaft.Consenters是集群心跳的命脉。它不是简单罗列 IP而是定义每个 orderer 节点的身份锚点Host必须与/etc/hosts中解析的域名一致Port必须与容器内监听端口匹配ClientTLSCert和ServerTLSCert必须指向该节点生成的 TLS 证书路径由cryptogen产出。任何一项不一致Raft 组建即失败。以orderer0.example.com为例其Consenters条目如下- Host: orderer0.example.com Port: 7050 ClientTLSCert: crypto-config/ordererOrganizations/example.com/orderers/orderer0.example.com/tls/server.crt ServerTLSCert: crypto-config/ordererOrganizations/example.com/orderers/orderer0.example.com/tls/server.crt对应地/etc/hosts必须包含192.168.137.100 orderer0.example.com 192.168.137.101 orderer1.example.com 192.168.137.102 orderer2.example.com且crypto-config/目录下证书路径必须真实存在# 在 192.168.137.100 上验证 ls -l crypto-config/ordererOrganizations/example.com/orderers/orderer0.example.com/tls/server.crt # 应输出类似-r--r--r--. 1 root root 1120 Mar 8 14:22 server.crt关键逻辑说明ClientTLSCert用于 orderer 向其他 orderer 发起连接时证明身份ServerTLSCert用于接收连接时被对方校验。二者必须为同一证书Fabric 默认复用 server.crt且server.crt的 Subject Common NameCN必须等于Host字段值即orderer0.example.com。可通过openssl x509 -in server.crt -text -noout | grep CN验证。3. 三节点分布式集群实战证书生成、创世区块构建与跨主机服务编排Fabric 分布式集群的本质是“证书驱动的网络拓扑”。所有节点启动前必须完成① 用cryptogen生成全网统一的 MSP 证书体系② 用configtxgen构建包含 Raft 成员信息的创世区块③ 将证书与配置文件同步至各主机④ 编写适配各节点角色的docker-compose.yaml。这四步缺一不可且顺序严格。3.1 证书体系生成crypto-config.yaml 的组织拓扑与 Count 参数含义crypto-config.yaml定义了 Fabric 网络的 PKI 结构。本文集群包含 1 个 Orderer 组织3 个 orderer 节点和 2 个 Peer 组织Org1 含 1 个 peerOrg2 含 2 个 peers对应配置如下OrdererOrgs: - Name: Orderer Domain: example.com Specs: - Hostname: orderer0 - Hostname: orderer1 - Hostname: orderer2 PeerOrgs: - Name: Org1 Domain: org1.example.com Template: Count: 1 # 生成 1 个 peerpeer0.org1.example.com Users: Count: 1 # 生成 1 个普通用户User1org1.example.com - Name: Org2 Domain: org2.example.com Template: Count: 2 # 生成 2 个 peerspeer0.org2.example.com, peer1.org2.example.com Users: Count: 1执行cryptogen generate --config./crypto-config.yaml后生成的目录结构为crypto-config/ ├── ordererOrganizations/ │ └── example.com/ │ ├── orderers/ │ │ ├── orderer0.example.com/ # 含 msp、tls 目录 │ │ ├── orderer1.example.com/ │ │ └── orderer2.example.com/ │ └── users/ ├── peerOrganizations/ │ ├── org1.example.com/ │ │ └── peers/ │ │ └── peer0.org1.example.com/ # 含 msp、tls 目录 │ └── org2.example.com/ │ └── peers/ │ ├── peer0.org2.example.com/ │ └── peer1.org2.example.com/参数说明Template.Count决定同组织下 peer 节点数量每个节点生成独立的msp含私钥、签名证书和tls含 server.crt/server.key/ca.crt目录Users.Count决定该组织下注册用户的数量用于后续链码调用的身份认证。切勿将 Count 设为 0否则peer容器启动时因缺失 MSP 目录报错failed to load local MSP。3.2 创世区块与通道配置configtxgen 的 profile 选择与输出路径Fabric 2.0 引入SampleMultiNodeEtcdRaftprofile 专门适配多 orderer Raft 集群。它与旧版SampleInsecureSolo的根本区别在于前者在Orderer.EtcdRaft.Consenters中显式声明所有共识节点后者仅配置单点ORDERER_GENERAL_ORDERERTYPEsolo。生成步骤如下# 生成创世区块-profile 指定 Raft 模式-outputBlock 指定输出路径 configtxgen -profile SampleMultiNodeEtcdRaft \ -channelID fabric-cluster-channel \ -outputBlock ./channel-artifacts/genesis.block # 生成通道创建交易-profile 使用 TwoOrgsChannel-outputCreateChannelTx 指定路径 configtxgen -profile TwoOrgsChannel \ -outputCreateChannelTx ./channel-artifacts/channel.tx \ -channelID mychannel # 为 Org1 生成锚节点更新交易-asOrg 指定组织名-outputAnchorPeersUpdate 指定输出 configtxgen -profile TwoOrgsChannel \ -outputAnchorPeersUpdate ./channel-artifacts/Org1MSPanchors.tx \ -channelID mychannel \ -asOrg Org1MSP # 为 Org2 生成锚节点更新交易 configtxgen -profile TwoOrgsChannel \ -outputAnchorPeersUpdate ./channel-artifacts/Org2MSPanchors.tx \ -channelID mychannel \ -asOrg Org2MSP生成的channel-artifacts/目录内容必须完整文件名用途验证命令genesis.block排序服务启动所需的创世区块configtxgen -inspectBlock genesis.block | head -n 5channel.tx创建应用通道的交易文件configtxgen -inspectChannelCreateTx channel.tx | grep channel_idOrg1MSPanchors.txOrg1 锚节点配置更新configtxgen -inspectChannelCreateTx Org1MSPanchors.tx | grep anchor_peers逻辑说明genesis.block包含 Raft 共识组初始成员列表即Consenterschannel.tx定义通道成员Org1Org2和策略OrgXMSPancho.rs.tx则指定该组织在通道中的代表节点如peer0.org1.example.com。三者共同构成 Fabric 网络的“宪法”。3.3 跨主机文件同步与 docker-compose 角色拆分为什么不能共用同一份 compose 文件Fabric 分布式集群中每台服务器只运行部分节点192.168.137.100orderer0.example.compeer0.org1.example.com192.168.137.101orderer1.example.compeer0.org2.example.com192.168.137.102orderer2.example.compeer1.org2.example.com因此docker-compose.yaml必须按节点角色拆分。以192.168.137.100为例其docker-compose-up.yaml仅定义orderer0和peer0.org1version: 2 services: orderer0.example.com: container_name: orderer0.example.com image: hyperledger/fabric-orderer:2.0.0 environment: - ORDERER_GENERAL_LISTENADDRESS0.0.0.0 - ORDERER_GENERAL_BOOTSTRAPFILE/var/hyperledger/orderer/orderer.genesis.block - ORDERER_GENERAL_LOCALMSPIDOrdererMSP - ORDERER_GENERAL_LOCALMSPDIR/var/hyperledger/orderer/msp - ORDERER_GENERAL_TLS_ENABLEDtrue - ORDERER_GENERAL_TLS_PRIVATEKEY/var/hyperledger/orderer/tls/server.key - ORDERER_GENERAL_TLS_CERTIFICATE/var/hyperledger/orderer/tls/server.crt - ORDERER_GENERAL_TLS_ROOTCAS[/var/hyperledger/orderer/tls/ca.crt] # Raft 集群必需参数 - ORDERER_GENERAL_CLUSTER_CLIENTCERTIFICATE/var/hyperledger/orderer/tls/server.crt - ORDERER_GENERAL_CLUSTER_CLIENTPRIVATEKEY/var/hyperledger/orderer/tls/server.key - ORDERER_GENERAL_CLUSTER_ROOTCAS[/var/hyperledger/orderer/tls/ca.crt] volumes: - ./channel-artifacts/genesis.block:/var/hyperledger/orderer/orderer.genesis.block - ./crypto-config/ordererOrganizations/example.com/orderers/orderer0.example.com/msp:/var/hyperledger/orderer/msp - ./crypto-config/ordererOrganizations/example.com/orderers/orderer0.example.com/tls:/var/hyperledger/orderer/tls ports: - 7050:7050 extra_hosts: - orderer0.example.com:192.168.137.100 - orderer1.example.com:192.168.137.101 - orderer2.example.com:192.168.137.102 peer0.org1.example.com: container_name: peer0.org1.example.com image: hyperledger/fabric-peer:2.0.0 environment: - CORE_PEER_IDpeer0.org1.example.com - CORE_PEER_ADDRESSpeer0.org1.example.com:7051 - CORE_PEER_LISTENADDRESS0.0.0.0:7051 - CORE_PEER_CHAINCODEADDRESSpeer0.org1.example.com:7052 - CORE_PEER_GOSSIP_BOOTSTRAPpeer0.org1.example.com:7051 - CORE_PEER_GOSSIP_EXTERNALENDPOINTpeer0.org1.example.com:7051 - CORE_PEER_LOCALMSPIDOrg1MSP - CORE_PEER_TLS_ENABLEDtrue - CORE_PEER_TLS_CERT_FILE/etc/hyperledger/fabric/tls/server.crt - CORE_PEER_TLS_KEY_FILE/etc/hyperledger/fabric/tls/server.key - CORE_PEER_TLS_ROOTCERT_FILE/etc/hyperledger/fabric/tls/ca.crt volumes: - ./crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/fabric/msp - ./crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls:/etc/hyperledger/fabric/tls ports: - 7051:7051 - 7052:7052 - 7053:7053 extra_hosts: - orderer0.example.com:192.168.137.100 - orderer1.example.com:192.168.137.101 - orderer2.example.com:192.168.137.102同步命令需在192.168.137.100上执行# 将证书和通道文件推送到其他两台机器 scp -r channel-artifacts/ root192.168.137.101:/root/fabric-cluster/ scp -r channel-artifacts/ root192.168.137.102:/root/fabric-cluster/ scp -r crypto-config/ root192.168.137.101:/root/fabric-cluster/ scp -r crypto-config/ root192.168.137.102:/root/fabric-cluster/ # 在目标机器上创建各自 compose 文件以 101 为例 ssh root192.168.137.101 cat /root/fabric-cluster/docker-compose-up.yaml EOF # 此处粘贴 orderer1 peer0.org2 的 service 定义 EOF关键点extra_hosts确保容器内 DNS 解析正确volumes映射路径必须与crypto-config.yaml生成的实际路径一致image标签必须显式指定:2.0.0避免拉取latest导致版本不一致。4. 集群启动与状态验证从 docker-compose up 到 peer channel list 的全流程诊断启动 Fabric 分布式集群不是执行一条docker-compose up -d就能完事。由于涉及多节点 TLS 握手、Raft Leader 选举、Gossip 网络发现必须分阶段验证每个环节是否就绪。以下是经过生产环境验证的标准流程。4.1 分阶段启动与日志观察为什么不能所有节点同时启动Raft 共识要求至少(N/2)1个节点在线才能形成多数派quorum。对于 3 节点集群需至少 2 个 orderer 启动成功后第三个才能加入。因此推荐启动顺序先启动orderer0和orderer1在 100 和 101 上分别执行cd ~/fabric-cluster docker-compose -f docker-compose-up.yaml up -d orderer0.example.com # 等待 30 秒确认无 crash docker logs orderer0.example.com 21 | grep Raft leader is再启动orderer2在 102 上docker-compose -f docker-compose-up.yaml up -d orderer2.example.com # 观察日志是否出现 joined raft cluster 和 became leader docker logs orderer2.example.com 21 | grep -E (joined|leader)最后启动所有 peer 节点100/101/102 同时执行# 在各自机器上 docker-compose -f docker-compose-up.yaml up -d peer0.org1.example.com docker-compose -f docker-compose-up.yaml up -d peer0.org2.example.com docker-compose -f docker-compose-up.yaml up -d peer1.org2.example.com典型错误定位若docker logs orderer0.example.com持续输出failed to dial ... context deadline exceeded检查extra_hosts是否缺失orderer1.example.com解析若出现x509: certificate is valid for orderer1.example.com, not orderer0.example.com说明server.crt的 CN 与Host字段不匹配。4.2 CLI 容器接入与通道操作使用 tools 镜像执行 peer 命令Fabric 未提供跨节点的统一管理界面所有通道操作必须通过hyperledger/fabric-tools容器完成。该容器需挂载所有组织的 MSP 和 TLS 证书并配置正确的环境变量# 在 192.168.137.100 上创建 CLI 容器复用 peer0.org1 的证书 docker run -it --rm \ --network host \ -v $(pwd)/crypto-config:/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto \ -e CORE_PEER_TLS_ENABLEDtrue \ -e CORE_PEER_LOCALMSPIDOrg1MSP \ -e CORE_PEER_MSPCONFIGPATH/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Adminorg1.example.com/msp \ -e CORE_PEER_ADDRESSpeer0.org1.example.com:7051 \ -e CORE_PEER_TLS_ROOTCERT_FILE/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt \ -e CORE_PEER_TLS_CERT_FILE/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.crt \ -e CORE_PEER_TLS_KEY_FILE/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.key \ hyperledger/fabric-tools:2.0.0 \ peer channel create -c mychannel -f ./channel-artifacts/channel.tx -o orderer0.example.com:7050 --outputBlock ./channel-artifacts/mychannel.block成功后mychannel.block生成且docker logs orderer0.example.com应出现Received block [0]。接着加入 peer 节点# 加入 Org1 的 peer peer channel join -b ./channel-artifacts/mychannel.block # 加入 Org2 的 peer需切换到 Org2 的 MSP 路径 CORE_PEER_LOCALMSPIDOrg2MSP \ CORE_PEER_MSPCONFIGPATH/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Adminorg2.example.com/msp \ CORE_PEER_ADDRESSpeer0.org2.example.com:7051 \ CORE_PEER_TLS_ROOTCERT_FILE/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt \ peer channel join -b ./channel-artifacts/mychannel.block4.3 最终状态验证表5 个关键命令及其预期输出命令执行位置预期输出失败含义docker ps | grep -E (ordererpeer)所有三台机器每台显示 2 个 UP 容器docker logs orderer0.example.com | grep Raft leader is100Raft leader is orderer0.example.com:7050Raft 未选举出 leaderpeer channel listCLI 容器Channels:mychannelpeer 未加入通道peer channel getinfo -c mychannelCLI 容器height:1currentBlockHash通道未初始化成功peer chaincode list --installedCLI 容器Package ID:Label:链码未安装或路径错误验证技巧若peer channel list返回空检查CORE_PEER_ADDRESS是否指向本机 peer如peer0.org1.example.com:7051且该 peer 容器确实在运行若getinfo报错error getting endorser client确认CORE_PEER_TLS_*路径下的证书文件存在且可读ls -l检查权限。5. Fabric 2.0 链码生命周期实战从打包、安装到批准提交的七步闭环Fabric 2.0 最大变革是链码智能合约管理去中心化不再由单一管理员部署而是通过package → install → approve → commit四步实现多组织协同治理。这要求每个组织独立安装链码再共同批准版本最后由足够多组织提交生效。整个过程需精确控制--peerAddresses和--signature-policy参数否则approve会因签名不足失败。5.1 链码打包与安装packager 与 install 命令的参数组合以fabcar链码为例位于fabric-samples/chaincode/fabcar/go在 CLI 容器中执行# 1. 打包链码生成 .tar.gz含 metadata.json 和 code peer lifecycle chaincode package fabcar.tar.gz \ --path github.com/hyperledger/fabric-samples/chaincode/fabcar/go \ --lang golang \ --label fabcar_1.0 # 2. Org1 安装--peerAddresses 指向本组织 peer peer lifecycle chaincode install fabcar.tar.gz \ --peerAddresses peer0.org1.example.com:7051 # 3. Org2 安装需切换环境变量指向 Org2 peer CORE_PEER_LOCALMSPIDOrg2MSP \ CORE_PEER_MSPCONFIGPATH/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Adminorg2.example.com/msp \ CORE_PEER_ADDRESSpeer0.org2.example.com:7051 \ CORE_PEER_TLS_ROOTCERT_FILE/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt \ peer lifecycle chaincode install fabcar.tar.gz参数说明--path是链码源码路径相对 GOPATH--label是链码唯一标识后续 approve 时引用--peerAddresses必须是本组织已加入通道的 peer 地址。安装成功后peer lifecycle chaincode queryinstalled会返回Package ID如cc123...该 ID 在 approve 阶段必须完全一致。5.2 批准与提交背书策略与 Majority 规则的强制执行Fabric 2.0 要求至少MAJORITY组织批准后才能提交。本集群含 Org1 和 Org2故需两者都 approve# 4. Org1 批准--sequence 1 表示首个版本--version 1.0 peer lifecycle chaincode approveformyorg \ -o orderer0.example.com:7050 \ --ordererResponseTimeout 30s \ --channelID mychannel \ --name fabcar \ --version 1.0 \ --package-id cc123... \ --sequence 1 \ --waitForEvent \ --signature-policy AND(Org1MSP.peer,Org2MSP.peer) \ --peerAddresses peer0.org1.example.com:7051 # 5. Org2 批准同样参数仅改 peer 地址 CORE_PEER_LOCALMSPIDOrg2MSP \ CORE_PEER_MSPCONFIGPATH/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Adminorg2.example.com/msp \ CORE_PEER_ADDRESSpeer0.org2.example.com:7051 \ CORE_PEER_TLS_ROOTCERT_FILE/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt \ peer lifecycle chaincode approveformyorg \ -o orderer0.example.com:7050 \ --channelID mychannel \ --name fabcar \ --version 1.0 \ --package-id cc123... \ --sequence 1 \ --signature-policy AND(Org1MSP.peer,Org2MSP.peer) \ --peerAddresses peer0.org2.example.com:7051 # 6. 查询批准状态确认两者都为 true peer lifecycle chaincode checkcommitreadiness \ --channelID mychannel \ --name fabcar \ --version 1.0 \ --sequence 1 \ --output json # 输出应含 Org1MSP: {Approve: true}, Org2MSP: {Approve: true} # 7. 提交链码由任一组织执行需指定所有批准组织 peer lifecycle chaincode commit \ -o orderer0.example.com:7050 \ --channelID mychannel \ --name fabcar \ --version 1.0 \ --sequence 1 \ --peerAddresses peer0.org1.example.com:7051 \ --peerAddresses peer0.org2.example.com:7051 \ --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt \ --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt关键逻辑--signature-policy定义链码调用时的背书策略此处要求 Org1 和 Org2 的 peer 共同签名checkcommitreadiness是提交前的强制校验commit命令中的--peerAddresses必须列出所有已 approve 的组织 peer且--tlsRootCertFiles需提供对应组织的 CA 证书。提交成功后peer lifecycle chaincode querycommitted --channelID mychannel --name fabcar本文还有配套的精品资源点击获取