我感兴趣地阅读了fabric proposal on consensus architecture，我对共识服务有疑问。在我看来，这实际上是一种单一服务，可以保证所有对等体按照它所决定的顺序接收块。因此，在任何给定时间，对于给定的链，它看起来必须由单个已识别且受信任的组织运行。它看起来不像服务可以分发。这是正确的，还是我误解了？
这不是一个真正的编程问题：如果这是一个错误的地方提出这个问题，也许有人可以让我知道。
答案 0 :(得分：8)
更新：Kafka Orderer现已投入生产：
个人订购服务（测试）：个人订购服务旨在实现极易部署，非生产订购 服务。它由一个为所有客户服务的流程组成 由于只有一个中央机关，因此不需要达成共识。 相应地没有高可用性或可伸缩性。这个 使solo成为开发和测试的理想选择，但不适合部署。
基于Kafka的订购服务（生产）：基于Kafka的订购服务利用Kafka发布/订阅系统来执行 排序，但将其包含在熟悉的ab.proto定义中，以便这样做 peer orderer客户端代码不是专门为其编写的 卡夫卡。卡夫卡目前是生产的首选 需要高吞吐量和高可用性的部署，但确实如此 不要求拜占庭容错。
PBFT订购服务（待定）： PBFT订购服务将使用Hyperledger Fabric PBFT实施（目前在 开发）以拜占庭容错的方式对消息进行排序。
Hyperledger Fabric中的共识服务是一个可插拔模块。 information约有3个宣布的实施：
Solo Orderer ： 独奏订购者旨在成为非常容易部署的非生产订货人。它由一个服务的单一过程组成 所有客户，因此没有“共识”，因为只有一个 中央。相应地没有高可用性或 可扩展性。这使得solo成为开发和测试的理想选择，但是 不部署。 Solo orderer取决于后备原始分类帐。
Kafka Orderer（待定）： Kafka orderer利用Kafka pubsub系统执行排序，但将其包含在熟悉的ab.proto定义中，以便 peer orderer客户端代码不是专门为其编写的 卡夫卡。在现实世界的部署中，可以预期Kafka 原始服务将在当地绑定，因为Kafka有自己的 强大的线协议。但是，用于测试或新颖部署 在场景中，Kafka订购者可以部署为网络服务。 预计Kafka将成为生产部署的首选 这要求高吞吐量和高可用性但不要求 拜占庭容错。卡夫卡订货人不使用 支持原始分类帐，因为这是由Kafka经纪人处理的。
PBFT Orderer（待定）： PBFT订购者使用超级分层结构PBFT实现以拜占庭容错方式对消息进行排序。因为 正在为超额预算器明确开发实施 结构，ab.proto用于与PBFT的有线通信 订购者。因此，将PBFT订购者绑定到 对等进程虽然可能适合某些部署。 PBFT orderer取决于支持原始分类帐。