我已阅读fabric proposal on consensus architecture感兴趣，我对共识服务有疑问。在我看来，这实际上是一种单一的服务，可以确保所有同行按照它所决定的顺序接收数据块。因此，它看起来似乎必须在任何给定的时间内由一个确定且受信任的组织来运行。它看起来不像可以分发服务。这是正确的，还是我误解了？可以分发Hyperledger Fabric Consensus Service吗？
这不是一个真正的编程问题：如果这是一个错误的地方问这个问题，或许有人可以让我知道请。
UPDATE：卡夫卡订货人现在是生产准备：
独奏订购服务（测试）：独奏订购服务旨在成为一个非常易于部署，非生产订单 服务。它由一个为所有客户提供服务的单一流程组成，所以不需要共识，因为只有一个中央机构。 相应地没有高可用性或可伸缩性。这个 非常适合开发和测试，但不适合部署。
基于卡夫卡订购服务（生产）：基于卡夫卡订购服务充分利用了卡夫卡的pub/sub系统执行 排序，但这种包装在熟悉ab.proto定义，以便 同行订货客户代码不会专门为 Kafka编写。卡夫卡是目前生产 部署的首选产品，它要求高吞吐量和高可用性，但不要求拜占庭容错。
PBFT订购服务（待定）：的PBFT订购服务将使用Hyperledger面料PBFT实施（目前正在 发展）在拜占庭容错方式订购信息。在Hyperledger织物
共识服务是一个可插入模块。有information约3日宣布实施：
独奏订货人： 独奏订货的目的是一个非常易于部署，非生产订货。它由一个服务于所有客户的单一流程组成，因此不需要“共识”，因为有一个中央当局。相应地没有高可用性或可扩展性。这使得单独开发和测试的理想选择，但 不部署。独奏订货人依赖于原始分类帐。
卡夫卡订货者（待定）： 卡夫卡订货者利用了卡夫卡发布订阅系统执行顺序，但包装此在熟悉ab.proto定义，以便 对等订货客户机代码并没有被具体地写入为 卡夫卡。在现实世界的部署中，预计Kafka proto服务将在本地进行绑定，因为Kafka拥有自己的 强大的有线协议。然而，对于测试或新颖部署场景，可以将Kafka订户部署为网络服务。 卡夫卡预计将成为首选的生产部署 ，它需要高吞吐量和高可用性，但不需要拜占庭式容错 。 Kafka订货人不使用支付原始分类账的 ，因为这是由卡夫卡经纪人处理的。
PBFT订货者（待定）： 的PBFT订货者使用hyperledger织物PBFT实施拜占庭容错方式订购消息。由于 实现正在针对hyperledger 结构明确开发，因此ab.proto用于与订购者PBFT 进行有线通信。因此，将PBFT订购者绑定到对等进程中是不寻常的，尽管对于某些部署可能是需要的。订货人的PBFT 取决于背面原始分类帐。