能否不为Orderer单独创建组织，而为每个Organization配置独立Orderer？

Absolutely feasible! This is a perfectly valid pattern in Hyperledger Fabric—many teams opt for this setup to distribute control of the ordering service across their participating organizations, rather than concentrating it in a dedicated, separate OrdererOrg. Here's a step-by-step breakdown of how to pull this off:

First, you’ll need to adjust your configtx.yaml to define each organization as both a peer organization and an orderer organization. Instead of having a standalone OrdererOrg entry, add OrdererEndpoints to each of your peer organizations, and include those organizations in the Orderer section’s Organizations list.

Example snippet:

Organizations:
  - &Org1
    Name: Org1MSP
    ID: Org1MSP
    MSPDir: ../organizations/peerOrganizations/org1.example.com/msp
    # Add orderer endpoint for this org
    OrdererEndpoints:
      - orderer.org1.example.com:7050
    # Keep existing peer-related config
    PeerEndpoints:
      - peer0.org1.example.com:7051
    AdminPrincipal: Role.MEMBER
    ...

  - &Org2
    Name: Org2MSP
    ID: Org2MSP
    MSPDir: ../organizations/peerOrganizations/org2.example.com/msp
    OrdererEndpoints:
      - orderer.org2.example.com:7050
    PeerEndpoints:
      - peer0.org2.example.com:7051
    AdminPrincipal: Role.MEMBER
    ...

Orderer:
  # Include your peer orgs here instead of a dedicated OrdererOrg
  Organizations:
    - *Org1
    - *Org2
  # Retain other orderer config (BatchTimeout, BatchSize, ConsensusType, etc.)
  BatchTimeout: 2s
  BatchSize:
    MaxMessageCount: 10
    AbsoluteMaxBytes: 99 MB
    PreferredMaxBytes: 512 KB
  ConsensusType: raft

Use cryptogen or Fabric CA to generate TLS and MSP certificates for each organization’s orderer node. If using cryptogen, update your crypto-config.yaml to include orderer nodes under each peer org:

Example snippet:

PeerOrgs:
  - Name: Org1
    Domain: org1.example.com
    EnableNodeOUs: true
    Template:
      Count: 1
    Users:
      Count: 1
    # Add orderer node definition for Org1
    OrdererNodes:
      - Name: orderer
        Hostname: orderer

  - Name: Org2
    Domain: org2.example.com
    EnableNodeOUs: true
    Template:
      Count: 1
    Users:
      Count: 1
    OrdererNodes:
      - Name: orderer
        Hostname: orderer

Run cryptogen generate --config=./crypto-config.yaml to generate all certificates—this will create orderer-specific certs under each org’s directory (e.g., organizations/peerOrganizations/org1.example.com/orderers/).

Each orderer node must be configured to use its parent organization’s MSP. For example, Org1’s orderer node orderer.yaml would look like this:

General:
  LedgerType: file
  ListenAddress: 0.0.0.0
  ListenPort: 7050
  TLS:
    Enabled: true
    PrivateKey: /var/hyperledger/orderer/tls/server.key
    Certificate: /var/hyperledger/orderer/tls/server.crt
    RootCAs:
      - /var/hyperledger/orderer/tls/ca.crt
  # Point to Org1's MSP directory and ID
  LocalMSPDir: /var/hyperledger/orderer/msp
  LocalMSPID: Org1MSP
  Cluster:
    ListenAddress: orderer.org1.example.com:7053
    ClientCertificate: /var/hyperledger/orderer/tls/server.crt
    ClientPrivateKey: /var/hyperledger/orderer/tls/server.key
    RootCAs:
      - /var/hyperledger/orderer/tls/ca.crt
  # Other configs like FileLedger path, LogLevel, etc.

Repeat this for each organization’s orderer node, updating LocalMSPDir and LocalMSPID to match the respective org.

Use configtxgen to generate the system channel genesis block using your updated profile (the one that includes peer orgs as orderer orgs):

configtxgen -profile TwoOrgsOrdererGenesis -channelID system-channel -outputBlock ./system-genesis-block/genesis.block

Replace TwoOrgsOrdererGenesis with the name of your profile in configtx.yaml.

Use Docker Compose or your orchestration tool of choice to deploy each organization’s orderer and peer nodes. Here’s a sample Docker Compose snippet for Org1’s services:

services:
  orderer.org1.example.com:
    image: hyperledger/fabric-orderer:latest
    environment:
      - ORDERER_GENERAL_LOGLEVEL=info
      - ORDERER_GENERAL_LISTENADDRESS=0.0.0.0
      - ORDERER_GENERAL_GENESISMETHOD=file
      - ORDERER_GENERAL_GENESISFILE=/var/hyperledger/orderer/genesis.block
      - ORDERER_GENERAL_LOCALMSPID=Org1MSP
      - ORDERER_GENERAL_LOCALMSPDIR=/var/hyperledger/orderer/msp
      - 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_CLUSTER_LISTENADDRESS=0.0.0.0:7053
      - ORDERER_CLUSTER_CLIENTCERTIFICATE=/var/hyperledger/orderer/tls/server.crt
      - ORDERER_CLUSTER_CLIENTPRIVATEKEY=/var/hyperledger/orderer/tls/server.key
      - ORDERER_CLUSTER_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt]
    volumes:
      - ./system-genesis-block/genesis.block:/var/hyperledger/orderer/genesis.block
      - ../organizations/peerOrganizations/org1.example.com/orderers/orderer.org1.example.com/msp:/var/hyperledger/orderer/msp
      - ../organizations/peerOrganizations/org1.example.com/orderers/orderer.org1.example.com/tls:/var/hyperledger/orderer/tls
    ports:
      - 7050:7050
      - 7053:7053

  peer0.org1.example.com:
    image: hyperledger/fabric-peer:latest
    environment:
      - CORE_PEER_ID=peer0.org1.example.com
      - CORE_PEER_ADDRESS=peer0.org1.example.com:7051
      - CORE_PEER_LOCALMSPID=Org1MSP
      - CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/fabric/msp
      # Other peer configs...
    volumes:
      - ../organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/fabric/msp
      - ../organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls:/etc/hyperledger/fabric/tls
    ports:
      - 7051:7051

Repeat this for Org2’s orderer and peer nodes, updating the domain names and paths accordingly.

• Consensus Compatibility: This pattern works best with Raft consensus (the recommended consensus type for production), as it supports multi-organization orderer clusters.
• Cluster Communication: Ensure all orderer nodes can reach each other (for Raft replication) by configuring the Cluster section in orderer.yaml and exposing the necessary ports.
• Permissions: Update channel policies to define which organizations have control over orderer operations (e.g., adding new orderer nodes, modifying batch settings). You can adjust these policies in configtx.yaml under the Policy sections.
• Scalability: You can add multiple orderer nodes per organization later by updating the system channel configuration and deploying new nodes.

内容的提问来源于stack exchange，提问作者co.blocks office