感谢FISCO BCOS社区贡献者——刘海锋，贡献此文。
贡献无大小，分享永留传。谢谢你们的每一次贡献。最后，如果你也想成为Mr.FISCO BCOS，一起干出点改变世界，到老了可以跟孙辈们吹吹牛的事，欢迎加入社区。
经过尝试，我按以下操作顺序执行，成功部署了一个符合此场景描述（点击直达）的联盟链。
1，联盟委员会自建链证书
FISCO BCOS企业级部署工具提供了自建联盟链证书的功能，如下：
cd generator
#创建一个专用于放置证书的目录(该目录位置及名称均可自定义，只要保证后续使用企业级部署工具需要提供证书目录时，目录路径正确即可)
mkdir key_crt_dir
#在generator/key_crt_dir/chain下生成普通版链证书：
./generator --generate_chain_certificate ./key_crt_dir/chain
#在generator/key_crt_dir/chain-g下生成普通版链证书：
./generator --generate_chain_certificate ./key_crt_dir/chain-g -g
#-g参数表示国密
#按照企业级部署工具的使用要求将证书放在generator/meta/目录下
cp ./key_crt_dir/chain-g/gmca.crt ./meta/gmca.crt
cp ./key_crt_dir/chain/ca.crt ./meta/ca.crt
2，机构向联盟委员会申请机构证书
将第2步的 generator 文件夹(里面已经包含了链证书)复制为同级目录 generator-A、 generator-B、 generator-C 、 generator-D (以下简称为目录generator-A、generator-B、generator-C、generator-D)分别用于模拟联盟委员会为ABCD四家机构颁发自建证书的操作：
cd rc3-test-BCOS
cp -r generator generator-A && cp -r generator generator-B && cp -r generator generator-C && cp -r generator generator-D
企业级部署工具提供了颁发联盟委员会自建机构证书的功能：颁发联盟委员会自建机构证书。
模拟联盟委员会为机构A颁发证书：
cd generator-A
#在generator-A/key_crt_dir/agencyA_key_crt_dir下生成机构A的普通版证书
./generator --generate_agency_certificate ./key_crt_dir/agencyA_key_crt_dir ./key_crt_dir/chain test-agencyA
#在generator-A/key_crt_dir/agencyA-g_key_crt_dir下生成机构A的国密版证书
./generator --generate_agency_certificate ./key_crt_dir/agencyA-g_key_crt_dir ./key_crt_dir/chain-g test-agencyA -g
#按照企业级部署工具的使用要求将证书放在generator-A/meta/目录下
cp ./key_crt_dir/agencyA_key_crt_dir/test-agencyA/agency.crt ./key_crt_dir/agencyA_key_crt_dir/test-agencyA/agency.key ./meta/
cp ./key_crt_dir/agencyA-g_key_crt_dir/test-agencyA/gmagency.crt ./key_crt_dir/agencyA-g_key_crt_dir/test-agencyA/gmagency.key ./meta/
模拟联盟委员会为机构B颁发证书：
cd generator-B
#在generator-B/key_crt_dir/agencyB_key_crt_dir下生成机构B的普通版证书
./generator --generate_agency_certificate ./key_crt_dir/agencyB_key_crt_dir ./key_crt_dir/chain test-agencyB
#在generator-B/key_crt_dir/agencyB-g_key_crt_dir下生成机构B的国密版证书
./generator --generate_agency_certificate ./key_crt_dir/agencyB-g_key_crt_dir ./key_crt_dir/chain-g test-agencyB -g
#按照企业级部署工具的使用要求将证书放在generator-B/meta/目录下
cp ./key_crt_dir/agencyB_key_crt_dir/test-agencyB/agency.crt ./key_crt_dir/agencyB_key_crt_dir/test-agencyB/agency.key ./meta/
cp ./key_crt_dir/agencyB-g_key_crt_dir/test-agencyB/gmagency.crt ./key_crt_dir/agencyB-g_key_crt_dir/test-agencyB/gmagency.key ./meta/
模拟联盟委员会为机构C颁发证书：
cd generator-C
#在generator-C/key_crt_dir/agencyC_key_crt_dir下生成机构B的普通版证书
./generator --generate_agency_certificate ./key_crt_dir/agencyC_key_crt_dir ./key_crt_dir/chain test-agencyC
#在generator-C/key_crt_dir/agencyC-g_key_crt_dir下生成机构B的国密版证书
./generator --generate_agency_certificate ./key_crt_dir/agencyC-g_key_crt_dir ./key_crt_dir/chain-g test-agencyC -g
#按照企业级部署工具的使用要求将证书放在generator-C/meta/目录下
cp ./key_crt_dir/agencyC_key_crt_dir/test-agencyC/agency.crt ./key_crt_dir/agencyC_key_crt_dir/test-agencyC/agency.key ./meta/
cp ./key_crt_dir/agencyC-g_key_crt_dir/test-agencyC/gmagency.crt ./key_crt_dir/agencyC-g_key_crt_dir/test-agencyC/gmagency.key ./meta/
模拟联盟委员会为机构D颁发证书：
cd generator-D
#在generator-D/key_crt_dir/agencyD_key_crt_dir下生成机构D的普通版证书
./generator --generate_agency_certificate ./key_crt_dir/agencyD_key_crt_dir ./key_crt_dir/chain test-agencyD
#在generator-D/key_crt_dir/agencyD-g_key_crt_dir下生成机构D的国密版证书
./generator --generate_agency_certificate ./key_crt_dir/agencyD-g_key_crt_dir ./key_crt_dir/chain-g test-agencyD -g
#按照企业级部署工具的使用要求将证书放在generator-D/meta/目录下
cp ./key_crt_dir/agencyD_key_crt_dir/test-agencyD/agency.crt ./key_crt_dir/agencyD_key_crt_dir/test-agencyD/agency.key ./meta/
cp ./key_crt_dir/agencyD-g_key_crt_dir/test-agencyD/gmagency.crt ./key_crt_dir/agencyD-g_key_crt_dir/test-agencyD/gmagency.key ./meta/
3，机构ABCD颁发下属节点自建证书
企业级部署工具提供了机构颁发自建节点证书的功能。机构在颁发下属节点的证书时，会同时生成该机构下属节点的p2p连接信息，该信息用于在机构生成每个下属节点的部署程序时，告知每个节点程序去群组内其它节点的连接地址。机构生成下属节点的节点证书和p2p连接信息依靠企业级部署工具的generator/conf/node_deployment.ini文件内容。
-
机构A自建颁发下属节点的节点证书，并生成机构A下属节点的所有p2p连接信息。
修改
generator-A/conf/node_deployment.ini文件如下：[group] group_id=1
[node0] p2p_ip=127.0.0.1 rpc_ip=127.0.0.1 p2p_listen_port=30300 channel_listen_port=20200 jsonrpc_listen_port=8545
[node1] p2p_ip=127.0.0.1 rpc_ip=127.0.0.1 p2p_listen_port=30301 channel_listen_port=20201 jsonrpc_listen_port=8546
[node2] p2p_ip=127.0.0.1 rpc_ip=127.0.0.1 p2p_listen_port=30302 channel_listen_port=20202 jsonrpc_listen_port=8547
生成机构A下属节点的节点证书和p2p连接信息：
cd generator-A #根据generator-A/conf/node_deployment.ini文件的内容，在generator-A/node_cert_p2p下生成机构A的下属节点证书和p2p连接信息 ./generator --generate_all_certificates ./node_cert_p2p -ggenerator-A/node_cert_p2p/peers.txt内容如下：127.0.0.1:30300 127.0.0.1:30301 127.0.0.1:30302
-
机构B颁发下属节点的证书，并生成下属节点的所有p2p连接信息。
修改
generator-B/conf/node_deployment.ini文件如下：[group] group_id=1
[node0] p2p_ip=127.0.0.1 rpc_ip=127.0.0.1 p2p_listen_port=30303 channel_listen_port=20203 jsonrpc_listen_port=8548
生成机构B下属节点的证书和p2p连接信息：
cd generator-B #根据generator-B/conf/node_deployment.ini文件的内容，在generator-B/node_cert_p2p下生成机构A的下属节点证书和p2p连接信息 ./generator --generate_all_certificates ./node_cert_p2p -ggenerator-B/node_cert_p2p/peers.txt内容如下：127.0.0.1:30303
-
机构C颁发下属节点的证书，并生成下属节点的所有p2p连接信息。
修改
generator-C/conf/node_deployment.ini文件如下：[group] group_id=2
[node0] p2p_ip=127.0.0.1 rpc_ip=127.0.0.1 p2p_listen_port=30304 channel_listen_port=20204 jsonrpc_listen_port=8549
生成机构C下属节点的证书和p2p连接信息：
cd generator-C #根据generator-C/conf/node_deployment.ini文件的内容，在generator-C/node_cert_p2p下生成机构A的下属节点证书和p2p连接信息 ./generator --generate_all_certificates ./node_cert_p2p -ggenerator-C/node_cert_p2p/peers.txt内容如下：127.0.0.1:30304
4，群组1各机构生成下属节点部署程序
群组1的组建
节点部署程序的生成，依赖于节点所属群组的群组创世区块。
假设群组1成员机构确认由机构A生成群组1创世区块。
-
说明：创世区块文件和证书文件一样，需要放到
generator/meta下。企业级部署工具生成群组创世区块，依赖于企业级部署工具的generator/conf/group_genesis.ini文件，该文件内容大致如下(示例)：[group] group_id=1
[nodes] node1=127.0.0.1:30301 node0=127.0.0.1:30300
[group]表示群组的ID(数字，唯一)，[nodes]表示群组初始创建时的下属所有节点的p2p连接信息。生成创世区块，还需要提供[nodes]下配置的所有节点的节点证书，所以，负责生成创世区块的机构，需要在群组组网初始时，收集群组内所有节点的节点证书和p2p连接信息。群组组成之后，已有节点的退出和新节点的加入都不要再修改创世区块(创世区块一经创建不可再修改)。
机构A收集群组1所有节点的节点证书(格式：gmcert_p2pIp_p2pPort.crt)，此过程使用拷贝指令cp模拟：
cd /usr/local/rc3-test-BCOS/
#机构A获取群组1除机构A之外的其它所有机构下属节点的节点证书
cp ./generator-B/node_cert_p2p/gmcert*.crt ./generator-A/meta/
机构A收集群组1所有节点的节点连接信息：
cd /usr/local/rc3-test-BCOS/
#机构A获取群组1除机构A之外的其它所有机构下属节点的p2p连接信息
cp ./generator-B/node_cert_p2p/peers.txt ./generator-A/meta/group1-peers-all-without-A.txt
强调：如果群组1除了机构A和机构B之外还有别的机构X，机构A也需要获取机构X下属节点的节点证书和节点连接信息。这里不做延伸。最终，机构A会拿到群组内所有节点的p2p连接信息和证书。
生成群组1创世区块
由于企业级部署工具生成群组创世区块依赖于generator/conf/group_genesis.ini文件的内容，所以机构A讲自己的企业级部署工具的generator-A/conf/group_genesis.ini文件修改如下：
[group] group_id=1
[nodes] node0=127.0.0.1:30300 node1=127.0.0.1:30301 node2=127.0.0.1:30302 node3=127.0.0.1:30303
注意：[nodes]下配置的信息来源于上面机构A收集群组1所有节点的节点连接信息而获得的。
机构A生成群组1创世区块，并分发给群组1的其它机构(使用拷贝指令模拟)：
cd generator-A
#将群组1的创世区块生成到generator-A/group1_genesis下(同时也在generator-A/meta下放置了一份)
./generator --create_group_genesis ./group1_genesis -g
#机构A将群组1创世区块分发给群组1其它机构(直接放置在其他机构企业级部署工具的meta/文件夹下)
cd /usr/local/rc3-test-BCOS/
cp ./generator-A/group1_genesis/group.1.genesis ./generator-B/meta/
生成群组1节点部署程序
企业级部署工具提供了生成节点部署程序的功能，机构可一次生成下属所有节点的部署程序。该功能需要提供群组内除本机构外其它所有机构的所有下属节点的p2p连接信息(需要放置在generator/meta下)。
-
机构A生成下属节点的部署程序。上面的操作，机构A已经拿到了群组内除了机构A之外其它群组的节点p2p连接信息。
cd generator-A #机构A在generator-A/agencyA_node下生成了机构A的下属节点部署程序 ./generator --build_install_package ./meta/group1-peers-all-without-A.txt ./agencyA_node -g -
机构B生成下属节点的部署程序。上面的操作，机构A已经把群组1的创世区块文件分发给了机构B，并放置在了
generator-B/meta/下。按照企业级部署工具生成机构下属节点部署程序的条件，机构B还需要知道群组1内除机构B外其它所有机构的所有下属节点的p2p连接信息，且需要放置在需要放置在generator/meta下。节点连接信息的收集过程，实际部署的时候，由负责生成群组创世区块的机构分发给群组的下属机构比较好，因为在生成群组创世区块的时候就收集了这些信息，避免了群组的机构之间冗余的交流成本。cd /usr/local/rc3-test-BCOS/ #机构B先收集群组内除了机构B之外其它群组的节点p2p连接信息，本次测试只有机构A。 cp ./generator-A/node_cert_p2p/peers.txt ./generator-B/meta/group1-peers-all-without-B.txt cd generator-B #机构B在generator-B/agencyB_node下生成了机构A的下属节点部署程序 ./generator --build_install_package ./meta/group1-peers-all-without-B.txt ./agencyB_node -g -
注意：这时候还没有启动任何节点。
群组2的组建
假设群组2成员机构确认由机构C生成群组2创世区块。
机构C收集群组2所有节点的节点证书和节点连接信息，此过程使用拷贝指令cp模拟：
cd /usr/local/rc3-test-BCOS/
#机构C获取群组2除机构C之外的其它机构下属节点的节点证书
cp ./generator-B/node_cert_p2p/gmcert*.crt ./generator-C/meta/
#机构C获取群组2除机构C之外的其它机构下属节点p2p连接信息
cp ./generator-B/node_cert_p2p/peers.txt ./generator-C/meta/group2-peers-all-without-C.txt
生成群组2创世区块
机构C修改generator-C/conf/group_genesis.ini文件如下：
[group] group_id=2
[nodes] node3=127.0.0.1:30303 node2=127.0.0.1:30304
机构C生成群组2创世区块，并分发给群组2的其它机构(使用拷贝指令模拟)：
cd generator-C
#将群组2的创世区块生成到generator-C/group2_genesis下(同时也在generator-C/meta下放置了一份)
./generator --create_group_genesis ./group2_genesis -g
cd /usr/local/rc3-test-BCOS/
#机构C将群组2创世区块分发给群组2其它机构
cp ./generator-C/group2_genesis/group.2.genesis ./generator-B/meta/
生成群组2节点部署程序
上面的操作中，负责生成群组2创世区块的机构C已经获取到了群组2的其它成员机构下属节点的连接信息，所以，机构C使用企业级部署工具生成机构C下属节点部署程序的条件满足。
- 机构C生成下属节点的部署程序。
cd generator-C
#机构C在generator-C/agencyC_node下生成了机构C的下属节点部署程序
./generator --build_install_package ./meta/group2-peers-all-without-C.txt ./agencyC_node -g
- 机构B加入群组2。机构B的下属节点部署程序在创建群组1时已生成，所以现在只需要把群组2的信息加入机构B已经生成的节点部署程序即可(此时机构B的下属节点部署程序还都没有部署和启动)。机构B使用企业级部署工具提供的指令add_group、add_peers，给定参数，即可配置加入群组2：
将群组2的群组信息加入机构B的下属节点部署程序中(机构B已经拿到了机构C生成和分发的群组2创世区块)：
cd generator-B
#机构B注册群组2创世区块
./generator --add_group ./meta/group.2.genesis ./agencyB_node
机构B收集群组2其它节点p2p连接信息，并配置到已有的节点部署程序中：
cd /usr/local/rc3-test-BCOS/
#机构B收集群组2其它节点的p2p连接信息
cp ./generator-C/node_cert_p2p/peers.txt ./generator-B/meta/group2-peers-all-without-B.txt
#机构B下属所有节点加入群组2
cd generator-B
./generator --add_peers ./meta/group2-peers-all-without-B.txt ./agencyB_node
- 修改群组2默认的共识算法为raft。
机构B修改generator-B/agencyB_node/node_127.0.0.1_30303/conf/group.2.genesis文件(如果有多个节点，则所有节点的该文件都需要修改)；
机构C修改generator-C/agencyC_node/node_127.0.0.1_30304/conf/group.2.genesis文件(如果有多个节点，则所有节点的该文件都需要修改)。相关配置项如下(修改共识机制和群组id)：
[consensus] consensus_type = raft
[group] id = 2
至此，
机构A下属的节点部署程序位于generator-A/agencyA_node/node*文件夹下。 机构B下属的节点部署程序位于generator-B/agencyB_node/node*文件夹下。 机构C下属的节点部署程序位于generator-C/agencyC_node/node*文件夹下。
注意：现在还没有启动任何节点，也没有启动联盟链。
5，启动联盟链
创建/usr/local/rc3-test-BCOS/test-chain文件夹，模拟节点部署服务器，以下简称为目录test-chain。
cd /usr/local/rc3-test-BCOS/
mkdir test-chain
联盟所有机构部署并启动下属节点程序，启动联盟链。
机构A部署将下属节点程序(使用拷贝指令模拟)：
cd /usr/local/rc3-test-BCOS/
cp -r ./generator-A/agencyA_node/node* ./test-chain/
机构B部署将下属节点程序(使用拷贝指令模拟)：
cd /usr/local/rc3-test-BCOS/
cp -r ./generator-B/agencyB_node/node* ./test-chain/
机构C部署将下属节点程序(使用拷贝指令模拟)：
cd /usr/local/rc3-test-BCOS/
cp -r ./generator-C/agencyC_node/node* ./test-chain/
各机构节点分别启动，以节点0为例：
cd /usr/local/rc3-test-BCOS/test-chain/node_127.0.0.1_30300/
#启动
./start.sh
查看节点启动状态：
##实际项目中需要进入节点服务器命令行
ps -ef | grep -v grep | grep fisco-bcos
#会查到至少一个FISCO-bcos进程
6，控制台的配置和使用
控制台是FISCO BCOS提供的服务器工具，可查看联盟链的运行状态及区块和交易信息，同时提供了智能合约的编译功能。控制台官方详细说明在这里。
控制台的下载(rc3版的企业级部署工具提供了下载控制台的指令，参考官网)：
cd /usr/local/rc3-test-BCOS/
#下载控制台，该命令意为下载并执行链接中的shell脚本，运行的结果是在/usr/local/rc3-test-BCOS/目录下载了控制台程序的压缩包，并解压为/usr/local/rc3-test-BCOS/console/文件夹
bash <(curl -s https://raw.githubusercontent.com/FISCO-BCOS/console/master/tools/download_console.sh)
控制台下载结束，得到/usr/local/rc3-test-BCOS/console/目录，以下简称为目录console。控制台默认提供的智能合约编译jar包是普通版的，国密版的联盟链则需要使用国密版的合约编译jar包。国密版jar包的配置操作如下：
cd /usr/local/rc3-test-BCOS/console/
#将国密版合约编译包下载到/usr/local/rc3-test-BCOS/console/目录下
curl -LO https://github.com/FISCO-BCOS/LargeFiles/raw/master/tools/solcj/solcJ-all-0.4.25-gm.jar
#将默认的合约编译包替换为国密版编译包
./replace_solc_jar.sh solcJ-all-0.4.25-gm.jar
控制台提供了示例配置文件console/conf/applicationContext-sample.xml，本次测试使用示例的配置文件格式，我们将其拷贝一份使用：
cd /usr/local/rc3-test-BCOS/console/
#将控制台示例配置文件复制为控制台要求的配置文件名称
cp conf/applicationContext-sample.xml conf/applicationContext.xml
控制台的配置
本次测试为机构A-节点0:127.0.0.1:30300、机构B-节点3:127.0.0.1:30303、机构C-节点4:127.0.0.1:30304三个节点配置控制台，各节点的控制台安装使用拷贝指令，将上面下载的控制台目录分别复制给节点0、节点3、节点4：
cd /usr/local/rc3-test-BCOS/
cp -r console/ test-chain/node_127.0.0.1_30300/console
cp -r console/ test-chain/node_127.0.0.1_30303/console
cp -r console/ test-chain/node_127.0.0.1_30304/console
实际部署控制台时，不一定要将控制台放在节点的部署程序里，控制台程序的目录位置不受限制，甚至可以部署在非节点服务器上，只要将控制台的配置文件中的节点channel连接地址配置正确，保证控制台能连接到链即可。
为控制台配置sdk证书
控制台在某种意义上也是一种节点，是可以查看和操作链的节点，控制台本身不参与链的运行，但是连接链也需要认证(事实上FISCO BCOS系统中所有连接链的行为都需要认证，如使用web3sdk的业务系统等)，即sdk证书。sdk证书在证书链中与节点证书是同一级别的证书，都是由机构颁发，因此联盟各成员机构经过联盟委员会同意后实际控制着联盟链的准入(注意：sdk证书在FISCO BCOS链中标志着身份，同一个证书理论上可以被不同场景使用，如控制台，web3sdk项目等，但是FISCO BCOS会认为是同一个身份，所以sdk证书最好不要复用)。本次测试，各机构模拟颁发sdk证书(均是自建的证书)的操作如下：
- 机构A颁发sdk证书
cd generator-A
#在generator-A/key_crt_dir/dir_sdk_ca/目录下生成sdk证书
./generator --generate_sdk_certificate ./key_crt_dir/dir_sdk_ca ./key_crt_dir/agencyA_key_crt_dir/test-agencyA
机构A为节点0控制台配置sdk证书：
cd /usr/local/rc3-test-BCOS/
#把机构A生成的sdk证书复制到节点0的控制台配置目录
cp generator-A/key_crt_dir/dir_sdk_ca/sdk/* test-chain/node_127.0.0.1_30300/console/conf/
- 机构B颁发sdk证书
cd generator-B
#在generator-B/key_crt_dir/dir_sdk_ca/目录下生成sdk证书
./generator --generate_sdk_certificate ./key_crt_dir/dir_sdk_ca ./key_crt_dir/agencyB_key_crt_dir/test-agencyB
机构B为节点3控制台配置sdk证书：
cd /usr/local/rc3-test-BCOS/
#把机构B生成的sdk证书复制到节点3的控制台配置目录
cp generator-B/key_crt_dir/dir_sdk_ca/sdk/* test-chain/node_127.0.0.1_30303/console/conf/
- 机构C颁发sdk证书
cd generator-C
#在generator-C/key_crt_dir/dir_sdk_ca/目录下生成sdk证书
./generator --generate_sdk_certificate ./key_crt_dir/dir_sdk_ca ./key_crt_dir/agencyC_key_crt_dir/test-agencyC
机构C为节点4控制台配置sdk证书：
cd /usr/local/rc3-test-BCOS/
#把机构C生成的sdk证书复制到节点4的控制台配置目录
cp generator-C/key_crt_dir/dir_sdk_ca/sdk/* test-chain/node_127.0.0.1_30304/console/conf/
修改控制台配置信息
控制台的配置，主要是修改控制台的配置文件console/conf/applicationContext.xml，因此，节点0、节点3、节点4都需要根据节点的群组和连接信息修改：
test-chain/node_127.0.0.1_30300/console/conf/applicationContext.xml
test-chain/node_127.0.0.1_30303/console/conf/applicationContext.xml
test-chain/node_127.0.0.1_30304/console/conf/applicationContext.xml
文件，着重修改国密开关、群组信息、channel连接地址等，官方参考信息。
启动控制台
#例如启动节点0上配置的控制台
cd /usr/local/rc3-test-BCOS/test-chain/
bash node_127.0.0.1_30300/console/start.sh
如果控制台配置正确(主要是配置文件的配置项国密开关、群组信息、channel连接地址等)，启动控制台效果如下：
控制台常用指令如下(更多指令参考官方说明)：
#查看控制台版本
getNodeVersion
#获取当前节点所有p2p连接信息
getPeers
#获取当前群组下属的节点id列表
getGroupPeers
#获取当前群组的区块的高度
getBlockNumber
#查看当前节点所在群组的共识节点列表
getSealerList
#查看当前节点所在群组的观察节点列表
getObserverList
#切换当前节点从属的群组
switch [groupId]
#获取当前群组共识信息
getConsensusStatus
#获取当前节点从属的所有群组的群组id列表
getGroupList
#获取当前节点控制台当前群组部署的合约信息
getDeployLog
#退出控制台
quit
如获取控制台版本：
所以，本次测试使用的是2.0.0-rc3 gm版本的控制台。
7，组网变动
机构A组网变动
进入机构A的节点0:127.0.0.1:30300控制台，执行：getPeers，查看节点0在群组1中连接的其它节点信息(不包括节点0自身信息)：
可以看到节点的NodeID：
节点1：09557505930aa98b661e30648df01e1ee3a72408a772600eb1aeb33888b5838e6c8428632bcdecf87705d95e32cdfc7ba2632e35963939f022c3a8ab864b679b
节点2：e63b4edccd6902bb3ebda75c0b0527c8a6fa6bfdd6fb1fe3f0d70b507e76e2e9c595bf5f2e0655d6f841a267eee15c0f0abd74bcb4b1ee6f2335f0ef52d6fc6b
查看此时群组1的共识节点，执行getSealerList：
可以看到当前群组1总共有四个共识节点。从群组1移除节点2：
[group:1]> removeNode e63b4edccd6902bb3ebda75c0b0527c8a6fa6bfdd6fb1fe3f0d70b507e76e2e9c595bf5f2e0655d6f841a267eee15c0f0abd74bcb4b1ee6f2335f0ef52d6fc6b
结果：
将节点1设置为观察节点：
[group:1]> addObserver 09557505930aa98b661e30648df01e1ee3a72408a772600eb1aeb33888b5838e6c8428632bcdecf87705d95e32cdfc7ba2632e35963939f022c3a8ab864b679b
结果：
再次执行getSealerList，查看群组1的共识节点：
可以看到群组1的共识节点已经变为两个。
执行getObserverList，查看群组1的观察节点：
可以看到，观察节点只有一个了，也就是被设置为观察节点的节点1。至此，机构A组网变动操作结束，节点类型的操作参考官方说明。
机构D组网变动
第一，机构D加入群组2。
机构D为下属节点5颁发自建证书
机构D下属节点证书和节点连接信息的生成，依赖于generator-D/conf/node_deployment.ini文件，机构D修改该文件如下：
[group] group_id=2
[node0] p2p_ip=127.0.0.1 rpc_ip=127.0.0.1 p2p_listen_port=30305 channel_listen_port=20205 jsonrpc_listen_port=8550
执行：
cd generator-D
#根据generator-D/conf/node_deployment.ini文件的内容，在generator-D/node_cert_p2p下生成机构D的下属节点证书和p2p连接信息
./generator --generate_all_certificates ./node_cert_p2p -g
群组2现已组建且正在运行，机构D的下属节点5要加入群组2，需要知道节点5加入群组2之后，要与哪些节点连接，所以机构D需要收集现已运行的群组2的节点连接信息，此过程必须是联盟委员会同意的。使用拷贝指令模拟如下：
cd /usr/local/rc3-test-BCOS/
#机构D收集群组2所属机构B下属节点的所有p2p连接信息
cp ./generator-B/node_cert_p2p/peers.txt ./generator-D/meta/peersB.txt
#机构D收集群组2所属机构C下属节点的所有p2p连接信息
cp ./generator-C/node_cert_p2p/peers.txt ./generator-D/meta/peersC.txt
机构D收集完p2p连接信息之后，需要手动将所有收集到的p2p连接信息文件合并，假设合并为generator-D/meta/group2-peers-all-without-D.txt。
新节点(节点5)加入群组2，除了知道要连接哪些节点外，还需要知道群组2的创世区块。假设经过联盟委员会同意，由机构C将群组2的创世区块交给机构D。此过程使用拷贝指令模拟：
cd /usr/local/rc3-test-BCOS/
cp ./generator-C/group2_genesis/group.2.genesis ./generator-D/meta/
机构D生成节点部署程序
cd generator-D
#机构D在generator-D/agencyD_node下生成了机构D的下属节点部署程序
./generator --build_install_package ./meta/group2-peers-all-without-D.txt ./agencyD_node -g
确认和修改generator-D/agencyD_node/node_127.0.0.1_30305/conf/group.2.genesis文件的配置必须和群组2的相关配置一致(如共识机制，群组id等)。
机构D部署下属节点5
此过程使用拷贝指令模拟：
cd /usr/local/rc3-test-BCOS/
cp -r ./generator-D/agencyD_node/node* ./test-chain/
启动节点5：
cd /usr/local/rc3-test-BCOS/test-chain/node_127.0.0.1_30305/
./start.sh
启动节点3的控制台，查看此时节点3连接其它节点的信息：
因为节点3同属群组1和群组2，所以可以看到机构A的节点。可以看到节点5的NodeID：
节点5
6fe7dd6558a09ec1d7ee17145555a9d3526b6bfeea2f7d90b0055a883e24173e28c98fc7f3b3ac6ab86155330ffb8d354219460a4dedcb828b7bade39faca2bb
再查看此时群组2的共识节点：
里面并没有节点5的NodeID。这时，节点5已经作为观察节点加入群组2。
假设由群组2原有机构成员机构C把机构D的新节点注册为群组2的共识节点，此过程需要机构D将节点5的NodeID交给节点C，节点5的NodeID在/usr/local/rc3-test-BCOS/generator-D/agencyD_node/node_127.0.0.1_30305/conf/gmnode.nodeid。
机构C的节点4进入控制台发送指令，将节点5加入为到群组2的共识节点：
#进入节点4控制台
cd /usr/local/rc3-test-BCOS/test-chain/node_127.0.0.1_30304/console/
#启动控制台
./start.sh
再次查看群组2的共识节点：
节点5参与群组2共识成功。到此为止，机构D加入群组2操作结束。
第二，机构D的节点5与机构B的节点3组成群组3。
假设由机构B生成群组3的创世区块文件，机构B收集将要组建的群组3的下属节点3和节点5的证书和p2p连接信息，收集过程使用拷贝指令模拟(上面的操作，各机构均已生成下属节点的节点证书和p2p连接信息，所以不需要重复操作)：
cd /usr/local/rc3-test-BCOS/
#机构B收集群组3其它节点(节点5)的节点证书
cp ./generator-D/node_cert_p2p/gmcert_127.0.0.1_30305.crt ./generator-B/meta/
#机构B收集群组3其它节点(节点5)的p2p连接信息
cp ./generator-D/node_cert_p2p/peers.txt ./generator-B/meta/group3-peers-all-without-B.txt
机构B生成群组3创世区块，创世区块文件的生成依赖于generator-B/conf/group_genesis.ini文件的内容，修改该文件的内容如下：
[group] group_id=3
[nodes] node0=127.0.0.1:30303 node1=127.0.0.1:30305
注意：[nodes]配置项的内容为群组3初始创建时所有下属节点的连接信息，除了群组3的机构B下属的127.0.0.1:30303外，还包括机构B从机构D收集来的机构D下属节点127.0.0.1:30305的连接信息。
机构B生成群组3创世区块：
cd generator-B
#在generator-B/group3_genesis/文件夹下生成的便是群组3的创世区块
./generator --create_group_genesis ./group3_genesis -g
机构B向群组3其它机构(机构D)分发群组3创世区块，此过程使用拷贝指令模拟：
cd /usr/local/rc3-test-BCOS/
cp -r generator-B/group3_genesis generator-D/
注意：此时节点3和节点5都已在运行，所以分发给机构D的创世区块文件不需要放在企业级部署工具的meta文件夹下，而是需要机构B和机构D直接将群组的创世区块文件直接配置到已运行的节点3和节点5中。
机构B和机构D将群组3创世区块文件(group.3.genesis和group.3.ini)配置到已经部署的节点3和节点5服务器程序中，此过程使用拷贝指令模拟：
cd /usr/local/rc3-test-BCOS/
#机构B在下属节点3上配置群组3的创世区块
cp generator-B/group3_genesis/group.3* test-chain/node_127.0.0.1_30303/conf/
#机构D在下属节点5上配置群组3的创世区块
cp generator-D/group3_genesis/group.3* test-chain/node_127.0.0.1_30305/conf/
重启节点3和节点5。以重启节点3为例：
cd /usr/local/rc3-test-BCOS/test-chain/node_127.0.0.1_30303/
#先停止运行节点3
./stop.sh
#再启动节点3
./start.sh
说明：节点的重启其实是杀掉节点服务器中已经运行的节点fisco-bcos进程，然后再次启动，这也是stop.sh和start.sh脚本所做的事，实际情况中完全可以手动查找节点服务器的fisco-bcos进程并kill掉，以此停止节点的运行：
#进入节点的部署服务器命令行执行，查看fisco-bcos进程id
ps -ef | grep -v grep | grep fisco-bcos
kill -9 [上一步查出来的进程id]
再次修改节点3的控制台配置，将群组3的配置信息添加进去，启动控制台，就可以查到群组3的节点信息：
#进入节点3控制台
cd /usr/local/rc3-test-BCOS/test-chain/node_127.0.0.1_30303/console/
#启动控制台
./start.sh
至此，机构D的组网变动操作结束，整个场景描述的所有行为均已结束。
注：
建议此文和背景描述https://mp.weixin.qq.com/s/_V30KGDXjFC-zFCpVXPqWg一起阅读。
FISCO BCOS是完全开源的联盟区块链底层技术平台，由金融区块链合作联盟(深圳)(简称金链盟)成立开源工作组通力打造。开源工作组成员包括博彦科技、华为、深证通、神州数码、四方精创、腾讯、微众银行、亦笔科技和越秀金科等金链盟成员机构。
我们鼓励机构成员、开发者等社区伙伴参与开源共建事业，有你在一起，会更了不起。多样参与方式：
1 进入微信社群，随时随地与圈内最活跃、最顶尖的团队畅聊技术话题（进群请添加小助手微信，微信ID：fiscobcosfan）；
2 订阅我们的公众号：“FISCO BCOS开源社区”，我们为你准备了开发资料库、最新FISCO BCOS动态、活动、大赛等信息；
3 来Meetup与开发团队面对面交流，FISCO BCOS正在全国举办巡回Meetup，深圳、北京、上海、成都……欢迎您公众号在菜单栏【找活动】中找到附近的Meetup，前往结识技术大咖，畅聊硬核技术；
4 参与代码贡献，您可以在Github提交Issue进行问题交流，欢迎向FISCO BCOS提交Pull Request，包括但不限于文档修改、修复发现的bug、提交新的功能特性。
代码贡献指引：
https://github.com/FISCO-BCOS/FISCO-BCOS/blob/master/docs/CONTRIBUTING_CN.md
