刚好对Hyperledger Fabric的Orderer节点部署这块熟得很，咱们直接把你的问题拆成几个关键点来解答：

一、不同组织的Orderer节点是否会通信？ #

这得分两种部署模式来看：

1. 跨组织共享的Ordering Service（联盟级共享集群） #

这种模式下，不同组织的Orderer节点是会通信的——它们同属一个Ordering Service集群，必须协作完成共识、区块生成和分发的核心工作，节点间通过gRPC协议同步状态、传递共识消息（比如Raft的日志复制请求）。

2. 各组织独立的Ordering Service #

如果每个组织都部署自己独立的Ordering Service集群，那不同组织的Orderer节点完全不会通信，彼此是隔离的，各自处理自己组织（或私有子联盟）的交易排序需求。

二、跨组织共享Orderer集群的配置与共识运作 #

如果选择共享集群模式，配置和共识逻辑是这样的：

配置步骤 #

• 定义多组织Orderer节点：在configtx.yaml里的OrdererOrgs字段中，把所有参与共享集群的组织及其Orderer节点信息都加进去，示例如下：

  OrdererOrgs:
    - Name: Org1Orderer
      ID: Org1OrdererMSP
      MSPDir: crypto-config/ordererOrganizations/org1.com/msp
      Specs:
        - Hostname: orderer0.org1.com
    - Name: Org2Orderer
      ID: Org2OrdererMSP
      MSPDir: crypto-config/ordererOrganizations/org2.com/msp
      Specs:
        - Hostname: orderer0.org2.com
  

• 生成包含多组织MSP的创世块：用configtxgen工具生成创世块时，要确保创世块里包含所有Orderer组织的MSP信息，这样节点之间才能互相完成身份认证。
• 配置集群节点列表：每个Orderer节点的orderer.yaml配置文件中，要指定共识类型（比如推荐的Raft），并列出集群内所有节点的地址。以Raft为例：

  Consensus:
    Type: raft
    Raft:
      Options:
        Peers:
          - Address: orderer0.org1.com:7050
          - Address: orderer0.org2.com:7050
  

共识运作逻辑 #

目前Fabric推荐用Raft共识机制，跨组织的Orderer节点会组成一个Raft集群，遵循标准Raft协议：

• 集群会自动选举出一个leader节点，负责接收客户端的交易提案，将交易排序后写入日志。
• Leader会把日志复制给集群内的follower节点，当超过半数的节点确认日志已同步后，就会生成合法的区块，并分发给全网的Peer节点。
• 所有Orderer节点的身份由所属组织的MSP验证，确保只有合法节点能加入集群参与共识，避免恶意节点混入。

三、独立Ordering Service的适用场景 #

如果每个组织都部署独立的Ordering Service，通常是以下情况：

• 企业需要完全掌控自己的交易排序流程，不想依赖其他组织的节点。
• 不同组织之间没有共享交易的需求，各自运营独立的区块链网络。
• 合规要求严格，必须将交易排序环节完全隔离在组织内部。

这种模式下，每个组织的Orderer集群配置完全独立，自己生成创世块、配置共识参数，和其他组织的集群没有任何交互。

总结选择建议 #

• 如果是多组织组成的联盟，需要统一的交易一致性和全网共享的区块，优先选跨组织共享的Orderer集群。
• 如果组织需要绝对的控制权或独立运营需求，就选独立的Ordering Service。

内容的提问来源于stack exchange，提问作者Krupakar