Hyperledger Fabric Consensus Service 可以分布式吗？
Can the Hyperledger Fabric Consensus Service be distributed?
我感兴趣地阅读了fabric proposal on consensus architecture，我对共识服务有疑问。在我看来，这实际上是一项单一服务，可以保证所有节点按照它决定的顺序接收区块。因此，对于给定链，它看起来必须在任何给定时间由单个已识别和受信任的组织运行。看起来该服务无法分发。是这样吗，还是我理解错了？
这不是一个真正的编程问题：如果这是问这个问题的错误地方，也许有人可以让我知道。
更新： Kafka Orderer 现在可以生产了：
Solo ordering service (testing): The solo ordering service is intended to be an extremely easy to deploy, non-production ordering
service. It consists of a single process which serves all clients, so
consensus is not required as there is a single central authority.
There is correspondingly no high availability or scalability. This
makes solo ideal for development and testing, but not for deployment.
Kafka-based ordering service (production): The Kafka-based ordering service leverages the Kafka pub/sub system to perform the
ordering, but wraps this in the familiar ab.proto definition so that
the peer orderer client code does not to be written specifically for
Kafka. Kafka is currently the preferred choice for production
deployments which demand high throughput and high availability, but do
not require byzantine fault tolerance.
PBFT ordering service (pending): The PBFT ordering service will use the Hyperledger Fabric PBFT implementation (currently under
development) to order messages in a byzantine fault tolerant way.
Hyperledger Fabric 中的共识服务是一个可插拔模块。有 information 大约 3 个已公布的实现：
Solo Orderer:
The solo orderer is intended to be an extremely easy to deploy, non-production orderer. It consists of a single process which serves
all clients, so no `consensus' is required as there is a single
central authority. There is correspondingly no high availability or
scalability. This makes solo ideal for development and testing, but
not deployment. The Solo orderer depends on a backing raw ledger.
Kafka Orderer (pending):
The Kafka orderer leverages the Kafka pubsub system to perform the ordering, but wraps this in the familiar ab.proto definition so that
the peer orderer client code does not to be written specifically for
Kafka. In real world deployments, it would be expected that the Kafka
proto service would bound locally in process, as Kafka has its own
robust wire protocol. However, for testing or novel deployment
scenarios, the Kafka orderer may be deployed as a network service.
Kafka is anticipated to be the preferred choice production deployments
which demand high throughput and high availability but do not require
byzantine fault tolerance. The Kafka orderer does not utilize a
backing raw ledger because this is handled by the Kafka brokers.
PBFT Orderer (pending):
The PBFT orderer uses the hyperledger fabric PBFT implementation to order messages in a byzantine fault tolerant way. Because the
implementation is being developed expressly for the hyperledger
fabric, the ab.proto is used for wireline communication to the PBFT
orderer. Therefore it is unusual to bind the PBFT orderer into the
peer process, though might be desirable for some deployments. The PBFT
orderer depends on a backing raw ledger.
- 对于单独订购者（现在可用），声明 "have to be run by a single identified and trusted organization" 是正确的。
- Kafka orderer（开发中）- 应该可以分布式部署。
- PBFT Orderer - 没有找到关于此实现的信息。
我感兴趣地阅读了fabric proposal on consensus architecture，我对共识服务有疑问。在我看来，这实际上是一项单一服务，可以保证所有节点按照它决定的顺序接收区块。因此，对于给定链，它看起来必须在任何给定时间由单个已识别和受信任的组织运行。看起来该服务无法分发。是这样吗，还是我理解错了？
这不是一个真正的编程问题：如果这是问这个问题的错误地方，也许有人可以让我知道。
更新： Kafka Orderer 现在可以生产了：
Solo ordering service (testing): The solo ordering service is intended to be an extremely easy to deploy, non-production ordering service. It consists of a single process which serves all clients, so consensus is not required as there is a single central authority. There is correspondingly no high availability or scalability. This makes solo ideal for development and testing, but not for deployment.
Kafka-based ordering service (production): The Kafka-based ordering service leverages the Kafka pub/sub system to perform the ordering, but wraps this in the familiar ab.proto definition so that the peer orderer client code does not to be written specifically for Kafka. Kafka is currently the preferred choice for production deployments which demand high throughput and high availability, but do not require byzantine fault tolerance.
PBFT ordering service (pending): The PBFT ordering service will use the Hyperledger Fabric PBFT implementation (currently under development) to order messages in a byzantine fault tolerant way.
Hyperledger Fabric 中的共识服务是一个可插拔模块。有 information 大约 3 个已公布的实现：
Solo Orderer: The solo orderer is intended to be an extremely easy to deploy, non-production orderer. It consists of a single process which serves all clients, so no `consensus' is required as there is a single central authority. There is correspondingly no high availability or scalability. This makes solo ideal for development and testing, but not deployment. The Solo orderer depends on a backing raw ledger.
Kafka Orderer (pending): The Kafka orderer leverages the Kafka pubsub system to perform the ordering, but wraps this in the familiar ab.proto definition so that the peer orderer client code does not to be written specifically for Kafka. In real world deployments, it would be expected that the Kafka proto service would bound locally in process, as Kafka has its own robust wire protocol. However, for testing or novel deployment scenarios, the Kafka orderer may be deployed as a network service. Kafka is anticipated to be the preferred choice production deployments which demand high throughput and high availability but do not require byzantine fault tolerance. The Kafka orderer does not utilize a backing raw ledger because this is handled by the Kafka brokers.
PBFT Orderer (pending): The PBFT orderer uses the hyperledger fabric PBFT implementation to order messages in a byzantine fault tolerant way. Because the implementation is being developed expressly for the hyperledger fabric, the ab.proto is used for wireline communication to the PBFT orderer. Therefore it is unusual to bind the PBFT orderer into the peer process, though might be desirable for some deployments. The PBFT orderer depends on a backing raw ledger.
- 对于单独订购者（现在可用），声明 "have to be run by a single identified and trusted organization" 是正确的。
- Kafka orderer（开发中）- 应该可以分布式部署。
- PBFT Orderer - 没有找到关于此实现的信息。