这不是一个编程问题:如果这不是问这个问题的正确地方,请让我知道。
更新:Kafka Orderer现已可用于生产环境:
Solo ordering服务(测试): Solo ordering服务旨在成为一种非常易于部署、非生产ordering服务。它由一个单一进程提供服务给所有客户端,因此不需要共识,因为有一个中央权威。相应地,没有高可用性或可扩展性。这使得Solo非常适合开发和测试,但不适合部署。
Kafka-based ordering服务(生产): 基于Kafka的ordering服务利用Kafka pub/sub系统执行ordering,但将其包装在熟悉的ab.proto定义中,以便对等orderer客户端代码不必专门编写Kafka。Kafka目前是生产部署的首选选择,要求高吞吐量和高可用性,但不要求拜占庭容错。
PBFT ordering服务(待定): PBFT ordering服务将使用Hyperledger Fabric PBFT实现(目前正在开发中)以拜占庭容错的方式排序消息。
Hyperledger Fabric中的共识服务是一个可插拔的模块。有关3个公布的实现的信息。
Solo Orderer: Solo orderer旨在成为一种非常易于部署的非生产orderer。它由一个单独的进程组成,为所有客户端提供服务,因此不需要“共识”,因为有一个中央机构。相应地,没有高可用性或可扩展性。这使得Solo非常适合开发和测试,但不适合部署。Solo orderer依赖于备份原始分类帐。
Kafka Orderer (pending): Kafka orderer利用Kafka pubsub系统执行订购,但将其包装在熟悉的ab.proto定义中,以便对等orderer客户端代码不必专门针对Kafka编写。在现实世界的部署中,预计Kafka proto服务将在本地进程中限制,因为Kafka具有自己的强大的线路协议。但是,对于测试或新颖的部署场景,Kafka orderer可以作为网络服务部署。Kafka预计将成为优选的选择,用于要求高吞吐量和高可用性但不需要拜占庭容错的生产部署。Kafka orderer不使用备份原始分类帐,因为这由Kafka代理处理。
PBFT Orderer (pending): PBFT orderer使用超级账本PBFT实现以拜占庭容错的方式对消息进行排序。由于该实现是专门为超级账本而开发的,因此使用ab.proto进行线路通信到PBFT orderer。因此,将PBFT orderer绑定到peer进程中是不寻常的,但某些部署可能会有所需。PBFT orderer依赖于备份原始分类帐。