企业官网建设流程全解析

• 区块链
• 密码学

导读

Hyperledger Fabric 支持在不重建网络的前提下，向一个已经正常运行的排序服务（Ordering Service）集群中动态加入新的 Orderer 节点，也可以将某个 Orderer 从网络中移除。本文以官方test-network示例为场景，完整演示"将第 5 个 Orderer 扩入由 4 个 Orderer 组成的 Smart BFT（BFT）集群"的每一步：从扩展crypto-config-orderer.yaml与docker-compose-bft编排文件、启动集群，到用osnadminCLI 将新节点加入通道、用configtxlator修改通道配置（Endpoints、BlockValidation 策略、consenter_mapping），再到签名、提交配置更新并验证节点状态；最后给出反向移除 Orderer 的完整流程。读完本文，你将掌握 Fabric 3.x 通道参与模型（Channel Participation）下 Orderer 节点动态扩缩容的完整操作链路，以及其底层 REST API 与状态机的工作原理。

说明：本文所有命令均基于 Hyperledger Fabric 官方示例仓库 fabric-samples 中的test-network目录（本仓库 docs/source/create_channel/add_orderer.md 的原始操作文档即以此为例），并结合当前 fabric 仓库源码（cmd/osnadmin、orderer/common/channelparticipation 等）补充原理性说明。

一、前置知识：Orderer 动态扩容的机制基础

在 Fabric 3.x 中，Orderer 加入通道不再依赖系统通道（system channel）和 genesis block 引导，而是通过Channel Participation API（通道参与 API）完成。每个 Orderer 暴露一个独立的Admin 端点，osnadminCLI 通过 HTTPS 调用该端点，即可让一个 Orderer "加入"某个已存在的通道。

从源码看，该能力由 orderer/common/channelparticipation/restapi.go 中的HTTPHandler提供，路由前缀为/participation/v1/，具体包括：

• POST /participation/v1/channels—— 让 Orderer 加入（join）一个通道；
• GET /participation/v1/channels[/{channelID}]—— 列出已加入的通道/查看单个通道详情；
• DELETE /participation/v1/channels/{channelID}—— 将通道从 Orderer 移除；
• PATCH /participation/v1/channels/{channelID}—— 用配置更新信封更新通道；
• GET /participation/v1/channels/{channelID}/blocks/{blockID}—— 拉取指定区块。

osnadmin命令的本质就是这些 REST 调用的封装。在 cmd/osnadmin/main.go 中可以看到其全局参数：-o, --orderer-address（OSN 的 Admin 端点）、--ca-file、--client-cert、--client-key、--no-status；子命令包括channel join、channel list、channel remove、channel update、channel fetch。

理解 join 之后的两个关键状态字段

当 Orderer 加入一个已存在的通道后，其状态由两个字段描述（定义见 orderer/common/types/channelinfo.go）：

• consensusRelation（与共识集群的关系）：
  • consenter—— Orderer 是通道共识集群中的正式成员（已出现在通道配置的 consenters 集合中）；
  • follower—— Orderer 不在共识集群中，但通过从其他 Orderer 拉取区块来跟随集群；
  • config-tracker—— 不在共识集群中，仅轮询通道最新配置块，等待被加入通道；
  • other—— 运行非集群式共识（如 solo）。
• status（追赶进度）：
  • onboarding—— 正在从其他 Orderer 拉取区块追赶高度（区块高度 ≤ join 块编号）；
  • active—— 已追平集群高度，正常参与共识或跟随；
  • inactive/failed—— 未存储任何块 / 最近一次操作失败。

下文第 4、5 节的输出中你会反复看到follower → consenter、onboarding → active的转换，这正是扩容过程的直观体现。

二、场景搭建：扩展 test-network 支持第 5 个 Orderer

Fabric 支持向现有网络添加新的 Orderer。我们使用test-network示例（来自 Hyperledger Fabric 官方 fabric-samples 仓库）来搭建一个简单但完整的演示场景。

2.1 在crypto-config-orderer.yaml中登记新节点

在test-network目录中，编辑crypto-config-orderer.yaml，新增一个 Hostname 为orderer5的节点条目（SANS 至少包含localhost）：

- Hostname: orderer5 SANS: - localhost

该文件用于cryptogen生成 Orderer 组织example.com的证书与 MSP 目录，新增条目后，会额外生成orderer5.example.com的 msp/tls 材料（organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/），供后续配置卷挂载与osnadmin证书参数使用。

2.2 在docker-compose-bft中定义第 5 个 Orderer 服务

首先在volumes段为数据卷声明一个新卷（用于持久化 Orderer 的生产数据目录）：

volumes: ... orderer5.example.com

然后添加新 Orderer 的服务定义（端口可按需调整）：

orderer5.example.com: container_name: orderer5.example.com image: hyperledger/fabric-orderer:latest labels: service: hyperledger-fabric environment: - FABRIC_LOGGING_SPEC=DEBUG - ORDERER_GENERAL_LISTENADDRESS=0.0.0.0 - ORDERER_GENERAL_LISTENPORT=7060 - ORDERER_GENERAL_LOCALMSPID=OrdererMSP - ORDERER_GENERAL_LOCALMSPDIR=/var/hyperledger/orderer/msp # enabled TLS - ORDERER_GENERAL_TLS_ENABLED=true - 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] - 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] - ORDERER_GENERAL_BOOTSTRAPMETHOD=none - ORDERER_CHANNELPARTICIPATION_ENABLED=true - ORDERER_ADMIN_TLS_ENABLED=true - ORDERER_ADMIN_TLS_CERTIFICATE=/var/hyperledger/orderer/tls/server.crt - ORDERER_ADMIN_TLS_PRIVATEKEY=/var/hyperledger/orderer/tls/server.key - ORDERER_ADMIN_TLS_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt] - ORDERER_ADMIN_TLS_CLIENTROOTCAS=[/var/hyperledger/orderer/tls/ca.crt] - ORDERER_ADMIN_LISTENADDRESS=0.0.0.0:7061 - ORDERER_OPERATIONS_LISTENADDRESS=orderer5.example.com:9450 - ORDERER_METRICS_PROVIDER=prometheus working_dir: /root command: orderer volumes: - ../organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/msp:/var/hyperledger/orderer/msp - ../organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/tls:/var/hyperledger/orderer/tls - orderer5.example.com:/var/hyperledger/production/orderer ports: - 7060:7060 - 7061:7061 - 9450:9450 networks: - test

关键环境变量解读：

关于 TLS 配置：上例中 Orderer 集群 TLS 与 Admin TLS 复用了同一套/var/hyperledger/orderer/tls/下的证书（server.crt/server.key/ca.crt）。实际生产环境通常建议为 Admin 端点单独签发证书。

2.3 在 CLI 容器中挂载 Orderer 管理员的证书

为了让 CLI 容器能以 Orderer 组织管理员身份操作（获取配置块、签名配置更新），还需在 CLI 容器定义中追加如下卷：

volumes: - ../organizations/ordererOrganizations/example.com/users/Admin@example.com/msp:/var/hyperledger/orderer/msp - ../organizations/ordererOrganizations/example.com/users/Admin@example.com/tls:/var/hyperledger/orderer/tls

2.4 启动集群

./network.sh createChannel -bft

该命令将启动由4 个 Orderer + 2 个 Peer + 1 个 CLI组成的 BFT 网络，同时也会启动第 5 个 Orderer（orderer5.example.com）的容器——但此时它并不属于网络，只是处于运行状态等待加入。命令还会创建名为mychannel的通道，4 个 Orderer 与 2 个 Peer 均参与其中。

-bft标志表示使用 Smart BFT 共识（smartbft），它基于拜占庭容错（BFT）模型，支持容忍f = (N-1)/3个故障节点，与 Raft 的容忍度不同，因此下文修改BlockValidation策略时计算阈值的方式与 etcdraft 网络（./network.sh createChannel，不带-bft）也有所差异。

三、用 osnadmin CLI 将新 Orderer 加入测试通道

osnadmin的完整命令参考见 docs/source/commands/osnadminchannel.md（由仓库help_docs.sh生成，与 cmd/osnadmin/main.go 的命令行定义一一对应）。

3.1 获取最新配置块

peer命令通过环境变量确定它运行在哪个组织的上下文中。先将上下文切换到 Peer 组织Org1：

export CORE_PEER_LOCALMSPID=Org1MSP export CORE_PEER_TLS_ROOTCERT_FILE=$PEER0_ORG1_CA export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp export CORE_PEER_ADDRESS=localhost:7051 export ORDERER_CA=${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

然后从现有 Orderer（orderer.example.com:7050）拉取mychannel的最新配置块：

peer channel fetch config config_block.pb -o orderer.example.com:7050 --ordererTLSHostnameOverride orderer.example.com -c mychannel --tls --cafile "$ORDERER_CA"

--ordererTLSHostnameOverride用于在 TLS 握手时以该主机名覆盖连接地址进行证书校验（容器网络内主机名与实际监听地址不同时必用）；-c mychannel指定通道；--cafile指向 Orderer 组织的 TLS CA 根证书。得到的config_block.pb是后续所有配置修改与osnadmin channel join的输入。

3.2 将新 Orderer 加入通道

切换环境变量到新 Orderer（第 5 个节点）的管理上下文，然后执行 join：

export OSN_TLS_CA_ROOT_CERT=${PWD}/organizations/ordererOrganizations/example.com/tlsca/tlsca.example.com-cert.pem export ADMIN_TLS_SIGN_CERT=${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/tls/server.crt export ADMIN_TLS_PRIVATE_KEY=${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/tls/server.key osnadmin channel join --channelID [CHANNEL_NAME] --config-block [CHANNEL_CONFIG_BLOCK] -o [ORDERER_ADMIN_LISTENADDRESS] --ca-file $OSN_TLS_CA_ROOT_CERT --client-cert $ADMIN_TLS_SIGN_CERT --client-key $ADMIN_TLS_PRIVATE_KEY

各占位符的替换规则：

• CHANNEL_NAME—— 通道名称（此处为mychannel）；
• CHANNEL_CONFIG_BLOCK—— 最新配置块的路径与文件名（即上一步的config_block.pb）；
• ORDERER_ADMIN_LISTENADDRESS—— 目标 Orderer 的Orderer.Admin.ListenAddress（对应orderer.yaml中的配置，此处为localhost:7061）；
• OSN_TLS_CA_ROOT_CERT—— Orderer 组织 TLS CA 根证书路径（若使用中间 TLS CA，需同时包含中间证书）；
• ADMIN_TLS_SIGN_CERT/ADMIN_TLS_PRIVATE_KEY—— 由 TLS CA 签发的管理员客户端证书与私钥。

例如：

osnadmin channel join --channelID mychannel --config-block config_block.pb -o localhost:7061 --ca-file "$OSN_TLS_CA_ROOT_CERT" --client-cert "$ADMIN_TLS_SIGN_CERT" --client-key "$ADMIN_TLS_PRIVATE_KEY"

注意：osnadmin与 Orderer 之间的连接要求双向 TLS（mutual TLS），因此每条osnadmin命令都必须同时传入--client-cert与--client-key（分别对应管理员客户端证书与私钥，均由管理员 TLS CA 签发）。

从 cmd/osnadmin/main.go 的源码可以看到，只要指定了--ca-file，客户端就会以https://前缀访问-o指定的 Admin 端点，并用tls.LoadX509KeyPair加载--client-cert/--client-key建立 mTLS；同时 join 前还会调用validateBlockChannelID（main.go#L210-L229），校验配置块中携带的通道 ID 与--channelID一致，防止加入错误的通道。

命令成功后的输出类似：

Status: 201 { "name": "mychannel", "url": "/participation/v1/channels/mychannel", "consensusRelation": "follower", "status": "onboarding", "height": 0 }

此时该 Orderer 与通道的关系为follower、状态为onboarding：它已接收配置块，正在从集群其他节点拉取区块追赶高度，但尚未成为共识集群成员（因为通道配置中还没有它的身份信息）。

四、修改通道配置：把新 Orderer 写入共识集群

以下命令需要在CLI 容器中执行（或把相关文件拷入 CLI 容器）。核心思路是：把最新配置块解码为 JSON → 修改 4 处 → 重新编码 → 用configtxlator计算配置更新（config update）→ 封装成信封 → 签名并提交。

4.1 将配置块转换为 JSON

使用上一节拉取的config_block.pb：

configtxlator proto_decode --input config_block.pb --type common.Block --output config_block.json

从 JSON 块中提取 config 部分：

jq .data.data[0].payload.data.config config_block.json > original_config.json

4.2 四步修改配置

本阶段的产物是一个配置更新交易（update TX）。你可以在 CLI 容器中直接计算，也可以把original_config.json复制到本地机器上完成全部修改，最后再将生成的 TX 拷回 CLI 容器。先创建副本：

cp original_config.json modified_config.json

然后对modified_config.json做以下4 处修改：

修改 1：加入已知端点（Endpoints）

导航到channel_group → groups → Orderer → groups → OrdererOrg → values → Endpoints → value → addresses，追加新 Orderer 的端点：

[ "orderer.example.com:7050", "orderer2.example.com:7052", "orderer3.example.com:7056", "orderer4.example.com:7058", "orderer5.example.com:7060" ]

该列表是客户端（Peer/SDK）用于发现排序节点的 "已知端点"。

修改 2：加入已知身份（identities）

导航到channel_group → groups → Orderer → policies → BlockValidation → policy → value → identities，加入新 Orderer 身份证书的 Base64 编码（路径请按实际情况修正）：

{ "principal": { "id_bytes": ".../test-network/organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/msp/signcerts/orderer5.example.com-cert.pem", "mspid": "OrdererMSP" }, "principal_classification": "IDENTITY" }

BlockValidation策略规定了哪些 Orderer 的签名能构成一个合法区块（Peer 校验区块时依据它）。更多背景可参考仓库中该策略的配置示例 orderer/common/cluster/testdata/blockverification/configtx.yaml。

修改 3：更新策略规则（rule）

导航到channel_group → groups → Orderer → policies → BlockValidation → policy → value → rule，根据节点总数重新计算阈值：

# Given that the new number of nodes in cluster is num_of_nodes: f = int((num_of_nodes - 1) / 3) n = ceil((num_of_nodes + f + 1) / 2)

并为新 Orderer 追加一个signed_by对象（5 节点 BFT 集群，n = 4）：

{ "n_out_of": { "n": 4, "rules": [ { "signed_by": 0 }, { "signed_by": 1 }, { "signed_by": 2 }, { "signed_by": 3 }, { "signed_by": 4 } ] } }

这里的signed_by: 0..4分别对应 identities 数组中下标为 0～4 的身份；n表示"区块至少需要多少个 Orderer 签名"：对 5 节点 BFT 集群，f = (5-1)/3 = 1，n = ceil((5+1+1)/2) = ceil(3.5) = 4，即任一合法区块需满足 4-of-5 的签名规则。

修改 4：加入 consenter_mapping

导航到channel_group → groups → Orderer → values → Orderers → value → consenter_mapping，加入新 Orderer 的身份证书、客户端 TLS 证书与服务端 TLS 证书（均为 Base64 编码，路径按需修正）：

{ "client_tls_cert": ".../test-network/organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/msp/tlscacerts/tlsca.example.com-cert.pem", "host": "orderer5.example.com", "id": 5, "identity": ".../test-network/organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/msp/signcerts/orderer5.example.com-cert.pem", "msp_id": "OrdererMSP", "port": 7060, "server_tls_cert": ".../test-network/organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/msp/tlscacerts/tlsca.example.com-cert.pem" }

consenter_mapping定义了每个共识集群成员（consenter）的节点标识id、host、port、MSP ID 及三张证书。它是集群节点间建立互信与通信的"通讯录"，也是共识协议识别"谁是集群成员"的依据。id必须唯一且与集群内其他节点不同（此处为 5）。

4.3 使用 Python 脚本自动完成上述 4 处修改

为简化这一繁琐过程，官方提供了一个 Python 脚本（位于 fabric-samples 仓库test-network/scripts目录下的add_new_orderer_to_config.py），可自动完成步骤 1～4。用法示例：

python3 scripts/add_new_orderer_to_config.py original_config.json modified_config.json \ -a orderer5.example.com:7060 \ -i ./organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/msp/signcerts/orderer5.example.com-cert.pem \ -s ./organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/msp/tlscacerts/tlsca.example.com-cert.pem \ -c ./organizations/ordererOrganizations/example.com/orderers/orderer5.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

其中-a指定端点（host:port）、-i指定身份证书、-s指定服务端 TLS 证书、-c指定客户端 TLS 证书。

4.4 计算配置更新 TX

configtxlator proto_encode --input original_config.json --type common.Config --output original_config.pb configtxlator proto_encode --input modified_config.json --type common.Config --output modified_config.pb configtxlator compute_update --channel_id mychannel --original original_config.pb --updated modified_config.pb --output config_update.pb configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate --output config_update.json echo '{"payload":{"header":{"channel_header":{"channel_id":"mychannel", "type":2}},"data":{"config_update":'$(cat config_update.json)'}}}' | jq . >config_update_in_envelope.json configtxlator proto_encode --input config_update_in_envelope.json --type common.Envelope --output envelope.pb

得到的envelope.pb即配置更新交易（config update TX）。注意它不包含任何文件路径信息，若是在本地机器上生成的，需要将其复制到 CLI 容器内再继续。

五、签名并提交配置更新

5.1 用 Peer 组织签名

配置更新交易必须同时获得 Peer 组织与 Orderer 组织的签名。当前上下文是 Peer 组织Org1，直接签名：

peer channel signconfigtx -f envelope.pb

5.2 切换到 Orderer 组织并提交

切换到 Orderer 组织Orderer的上下文：

export CORE_PEER_TLS_ENABLED=true export CORE_PEER_LOCALMSPID=OrdererMSP export CORE_PEER_TLS_ROOTCERT_FILE=/var/hyperledger/orderer/tls/ca.crt export CORE_PEER_MSPCONFIGPATH=/var/hyperledger/orderer/msp export CORE_PEER_ADDRESS=localhost:7050

提交更新：

peer channel update -o orderer.example.com:7050 --ordererTLSHostnameOverride orderer.example.com -c mychannel -f envelope.pb --tls --cafile "$ORDERER_CA"

成功的输出类似：

INFO [channelCmd] InitCmdFactory -> Endorser and orderer connections initialized INFO [channelCmd] update -> Successfully submitted channel update

5.3 验证新 Orderer 已变为 consenter

用osnadmin channel list查看指定通道详情：

osnadmin channel list --channelID mychannel -o localhost:7061 --ca-file "$OSN_TLS_CA_ROOT_CERT" --client-cert "$ADMIN_TLS_SIGN_CERT" --client-key "$ADMIN_TLS_PRIVATE_KEY"

输出中consensusRelation应自动从follower变为consenter，status从onboarding变为active：

{ "name": "mychannel", "url": "/participation/v1/channels/mychannel", "consensusRelation": "consenter", "status": "active", "height": 4 }

这个状态转换正好对应 orderer/common/types/channelinfo.go 中定义的两种枚举：加入配置后，该 Orderer 进入了通道的 consenters 集合（consenter），且区块高度已追平集群（active）。

新 Orderer 的日志中也会出现 Smart BFT 共识的心跳与区块消息，例如：

DEBU [orderer.consensus.smartbft.consensus] ProcessMessages -> 5 got message from 1: <HeartBeat with view: 0, seq: 7 channel=mychannel DEBU [orderer.consensus.smartbft.consensus] handleHeartBeat -> Received heartbeat from 1, last heartbeat was 5.995614586s ago channel=mychannel DEBU [orderer.consensus.smartbft.consensus] followerTick -> Last heartbeat from 1 was 1.000437542s ago channel=mychannel DEBU [orderer.consensus.smartbft.consensus] followerTick -> Last heartbeat from 1 was 2.003549876s ago channel=mychannel DEBU [orderer.consensus.smartbft.consensus] followerTick -> Last heartbeat from 1 was 3.00110746s ago channel=mychannel DEBU [orderer.consensus.smartbft.consensus] followerTick -> Last heartbeat from 1 was 3.99966021s ago channel=mychannel DEBU [orderer.consensus.smartbft.consensus] followerTick -> Last heartbeat from 1 was 5.000054669s ago channel=mychannel DEBU [orderer.consensus.smartbft.consensus] followerTick -> Last heartbeat from 1 was 5.999811586s ago channel=mychannel

这些日志表明新节点已与集群中的其他节点（编号 1）建立心跳并同步了视图（view: 0），正式成为共识集群一员。Smart BFT 共识实现位于 orderer/consensus/smartbft，其 follower/leader 状态机与区块复制逻辑正是上述日志的来源。

六、反向操作：从现有网络中移除一个 Orderer

移除流程是添加流程的逆过程：先从通道配置中移除该节点（4 处修改的逆操作），提交配置更新，再用osnadmin channel remove让该 Orderer 退出通道。

6.1 准备配置更新

切换到 Peer 组织上下文：

export CORE_PEER_TLS_ENABLED=true export CORE_PEER_LOCALMSPID=Org1MSP export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/organizations/peerOrganizations/org1.example.com/tlsca/tlsca.org1.example.com-cert.pem export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp export CORE_PEER_ADDRESS=localhost:7051

拉取最新配置块并转换为 JSON：

peer channel fetch config config_block.pb -o orderer.example.com:7050 --ordererTLSHostnameOverride orderer.example.com -c mychannel --tls --cafile "$ORDERER_CA" configtxlator proto_decode --input config_block.pb --type common.Block --output config_block.json jq .data.data[0].payload.data.config config_block.json > original_config.json

按照上一节4 处修改的逆序，把待移除的 Orderer（即第 5 个）从 JSON 中删除，保存为modified_config.json（即：从 consenter_mapping 删除其条目、恢复 BlockValidation 的 identities/rule、从 Endpoints 删除其端点）。

计算更新：

configtxlator proto_encode --input original_config.json --type common.Config --output original_config.pb configtxlator proto_encode --input modified_config.json --type common.Config --output modified_config.pb configtxlator compute_update --channel_id mychannel --original original_config.pb --updated modified_config.pb --output config_update.pb configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate --output config_update.json echo '{"payload":{"header":{"channel_header":{"channel_id":"mychannel", "type":2}},"data":{"config_update":'$(cat config_update.json)'}}}' | jq . >config_update_in_envelope.json configtxlator proto_encode --input config_update_in_envelope.json --type common.Envelope --output envelope.pb

用 Peer 组织签名：

peer channel signconfigtx -f envelope.pb

6.2 提交移除配置更新

切换到 Orderer 组织并提交：

export CORE_PEER_TLS_ENABLED=true export CORE_PEER_LOCALMSPID=OrdererMSP export CORE_PEER_TLS_ROOTCERT_FILE=/var/hyperledger/orderer/tls/ca.crt export CORE_PEER_MSPCONFIGPATH=/var/hyperledger/orderer/msp export CORE_PEER_ADDRESS=localhost:7050 peer channel update -o orderer.example.com:7050 --ordererTLSHostnameOverride orderer.example.com -c mychannel -f envelope.pb --tls --cafile "$ORDERER_CA"

预期输出：

INFO [channelCmd] InitCmdFactory -> Endorser and orderer connections initialized INFO [channelCmd] update -> Successfully submitted channel update

6.3 从 Orderer 移除通道

osnadmin channel remove -o localhost:7061 --ca-file "$ORDERER_CA" --client-cert "$ORDERER_ADMIN_TLS_SIGN_CERT" --client-key "$ORDERER_ADMIN_TLS_PRIVATE_KEY" --channelID mychannel

预期输出为Status: 204（对应 restapi.go 中serveRemove返回的 204 状态码，表示成功移除）。此时被移除的 Orderer 日志会显示通道关闭与退出：

INFO [orderer.consensus.smartbft.chain] Halt -> Shutting down chain channel=mychannel INFO [orderer.consensus.smartbft.consensus] func1 -> Exiting channel=mychannel INFO [orderer.consensus.smartbft.consensus] func1 -> Exiting channel=mychannel INFO [orderer.common.multichannel] removeMember -> Removed channel: mychannel

七、总结与扩展阅读

本文完整覆盖了 Fabric 3.x 下 Orderer 动态扩缩容的两条关键链路：

1. 节点侧（本地）：osnadmin channel join/channel remove通过 Channel Participation API（orderer/common/channelparticipation/restapi.go）让单个 Orderer 加入/退出通道，其状态由consensusRelation（follower/consenter等）与status（onboarding/active等）描述（orderer/common/types/channelinfo.go）；
2. 配置侧（全网）：通过configtxlator修改通道配置（Endpoints、BlockValidationidentities 与 rule、consenter_mapping），把新节点写入共识集群，使follower → consenter；移除时按逆序操作即可。

osnadmin channel的完整子命令（join/list/remove/update/fetch）与全部参数可查阅 docs/source/commands/osnadminchannel.md；orderer.yaml中Orderer.Admin.ListenAddress、Orderer.ChannelParticipation.Enabled等基础配置见 sampleconfig/orderer.yaml。通道参与机制更广泛的介绍（含"如何把第一个 Orderer 加入新通道"）可参考仓库内同目录的 docs/source/create_channel/create_channel_participation.md 与 docs/source/create_channel/create_channel_test_net.md。

需要提醒的是：动态扩容是一个有风险的管理操作，生产环境务必先在测试网络验证配置修改、策略阈值计算（BFT 的n/f公式）与证书材料，并确保所有参与签名的组织（Peer 组织与 Orderer 组织）都完整执行签名流程，否则配置更新将因策略不满足而被拒绝。

• 区块链
• 密码学