Hyperledger Composer技术咨询：区块链构建与部署相关疑问

嘿，别担心问题表述的事儿——大家刚接触区块链的时候都这样，咱们一个个把你的问题说清楚：

1. 使用Hyperledger Composer构建的是真实区块链还是仅为模拟环境？ #

这得看你用Composer的方式：

• 模拟环境: Composer自带一个叫「Composer Playground」的沙箱工具，要么在浏览器里直接运行，要么通过Docker本地启动，不需要完整的Hyperledger Fabric集群。用来快速测试业务逻辑、资产模型和交易流程特别合适，不用折腾真实分布式网络的搭建。
• 真实区块链: 当你把Composer业务网络部署到运行中的Hyperledger Fabric集群（本地、自建或云托管都行）时，你就是在和真实的许可制区块链交互了。Composer只是Fabric之上的高层抽象层，所有交易都会被写入Fabric节点维护的分布式账本里。

2. 使用Composer时的peer或节点指的是什么？存在多个还是仅单个？该如何选择？ #

首先得明确：Peer节点是Hyperledger Fabric的核心组件，不是Composer本身的——Composer只是和它们交互来部署、运行你的业务网络。

• Peer节点是什么？它负责存储区块链账本的副本、执行链码（智能合约）、验证交易，是Fabric网络的核心工作节点。
• 节点数量的选择：
  • POC或开发阶段: 单个Peer节点完全够用。能让你快速测试业务逻辑，不用承担分布式网络的额外开销。
  • 模拟生产场景: 你需要多个Peer节点，通常每个组织至少一个。这样可以测试多方共识、跨组织交易、账本分布式复制这些真实区块链的核心特性。
• 怎么选？先从单个Peer开始做你的初始POC，等你准备好测试多组织流程或分布式账本行为时，再在Fabric集群里新增Peer节点就行（只要网络连接配置正确，Composer会自动和它们交互）。

3. Hyperledger Fabric的默认共识机制是什么？和访问控制有关吗？ #

这个问题问得很好，咱们把边界划清楚：

• 共识机制是Fabric层面的配置，不能通过Composer直接定义。如果你用的是Composer开发工具自带的默认Fabric实例（比如运行composer network start时用的预配置Fabric环境），默认的共识机制是Raft。Raft是一种容错共识协议，比旧版的Kafka共识更容易部署，也是现在Fabric的推荐默认选项。
• 共识机制和访问控制（ACLs）完全无关：Composer的ACLs是用来定义「谁能执行哪些操作」的业务规则（比如「只有供应商能更新订单状态」），属于业务逻辑层的控制，和底层的共识机制（节点如何达成账本状态一致）没有关系。要修改共识机制，你需要调整Fabric排序节点的配置，而不是Composer的ACL规则。

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