使用Composer对接Fabric BYFN网络启动BNA时遇请求超时错误

我之前也碰到过一模一样的情况，用Composer对接Hyperledger Fabric默认网络时，启动业务网络超时大概率和版本兼容、网络连通性或者卡片配置有关。下面是我亲测有效的排查和解决步骤：

1. 先确认Composer与Fabric的版本兼容性 #

这是最容易踩坑的点！Composer对Fabric的版本有严格的匹配要求，比如Composer v0.20.x对应Fabric 1.3.x，v0.19.x对应Fabric 1.2.x。你可以分别运行这两个命令确认版本：

• 查看Composer版本：composer --version
• 查看Fabric版本（在Fabric samples目录下）：./byfn.sh version
  如果版本不匹配，要么降级/升级Composer，要么重新部署对应版本的Fabric网络，别硬凑版本！

2. 检查Fabric所有节点是否正常运行 #

先运行docker ps看看所有Fabric容器是不是都在正常跑——特别是4个peer节点（peer0.org1.example.com、peer1.org1.example.com、peer0.org2.example.com、peer1.org2.example.com）、orderer节点和ca节点，一个都不能少。
如果有容器退出，用docker logs <容器名称>查错误日志，修复后重新启动网络：./byfn.sh down && ./byfn.sh up。
另外还要检查本地端口有没有被占用，Fabric默认用的7051、7053这些端口，Linux可以用netstat -tulpn | grep 705，Windows用netstat -ano | findstr :7051排查。

3. 验证PeerAdmin卡片的配置是否正确 #

先运行composer card list确认PeerAdmin@hlfv1卡片存在，然后导出卡片检查配置：

composer card export -c PeerAdmin@hlfv1 -f admin.card

解压导出的admin.card文件，打开connection.json：

• 检查每个peer的URL是否正确，比如grpc://localhost:7051、grpc://localhost:7056，要和docker容器映射的端口完全一致；
• 如果Fabric启用了TLS（默认byfn.sh up是开启的），sslTargetNameOverride必须和peer的主机名一致，比如peer0.org1.example.com。
  要是配置有问题，重新运行createPeerAdminCard.sh脚本，确保脚本里的参数和Fabric网络配置匹配。

4. 延长Composer启动命令的超时时间 #

默认的超时时间可能不够完成通道初始化，你可以在启动命令里加--timeout参数延长时间，比如设置成300秒：

composer network start -c PeerAdmin@hlfv1 -n <你的BNA名称> -V <版本号> -A admin -S adminpw --timeout 300

这个参数会让Composer多等一会儿，避免因为网络初始化慢导致的超时。

5. 手动确认所有节点都加入了通道 #

进入peer0.org1的容器：

docker exec -it peer0.org1.example.com bash

运行peer channel list看看节点有没有加入默认通道（byfn的默认通道是mychannel），如果没加入，手动执行：

peer channel join -b /etc/hyperledger/configtx/mychannel.block

对另外3个peer节点重复这个操作，确保所有节点都成功加入通道。

内容的提问来源于stack exchange，提问作者Md Muntasir Mamun Joarder