问题描述
在Hyperledger Fabric中，当所有订购者节点都关闭时，对等体的预期行为是什么？ 对等也应该关闭，还是停止服务于客户端的请求，还是继续服务于查询请求？
在我们的测试中，停止订购者后，对等方继续写入“无法建立与订购者的连接”日志。当我们通过调用链码查询键时，将返回值。
您能否帮助您确定这是否是预期的行为。谢谢。
解决方法
我正在研究分布式超级账本结构网络。我建议订购木筏共识https://hyperledger-fabric.readthedocs.io/en/release-2.2/orderer/ordering_service.html#ordering-service-implementations。 我已经解决了这一问题，以我为例，我有三个分别在不同环境上运行的订购器。 如果我将所有这些订购者都当掉了，对等容器将继续在网络的其他参与者上运行。如您所说，他们无法进行任何交易。 如果我的订购者之一崩溃了，在达成共识后还算不错，那么容器将继续运行。如果另一个失败，则无法进行任何事务。在这种情况下，我让同伴继续检查订购者是否再次可用。
您描述的行为可以归结为以下事实：同级从账本中请求值，而他不需要订购者。 https://hyperledger.github.io/fabric-chaincode-node/master/api/fabric-shim.ChaincodeStub.html#getState
,请阅读以下内容：https://github.com/hyperledger/fabric/blob/master/docs/source/peers/peers.md这是我发现的有关系统工作方式的最佳文档，并且在回购单上的docs目录中有更多有关订购器的信息，等等。
我的理解是：同行们在那里签署（认可）交易建议。订购者可以订购，验证，打包交易并将其分发给同级。同行还可以通过八卦渠道发布他们对已验证交易的了解。
如果所有订购者都失败，则不会验证/打包/分配交易，因此直到订购者恢复之前，区块链将无法工作。
当我们通过调用链码查询密钥时，将返回值。
对等方仍将保持工作状态并准备签署/认可交易建议，并且查询对等方所持有的区块链仍然有效。链码由对等方托管。订购者不托管链码。
也可以在此处https://github.com/hyperledger/fabric/blob/master/docs/source/orderer/ordering_service.md#ordering-service-implementations中查看订购者可以在哪些模式下运行：筏模式，Kafka订购，独奏订购。
,我认为当前的观察行为是可以预期的，并且我认为这很好。
让我们检查订购者的目的吗？
- 订购交易
- 在满足条件（最小txn /大小或时间）的情况下，剪切块并将其分配到组织中。
这还意味着，当您的Fabric网络正在处理那些打算将数据写入分类账的交易时，需要订购者，不是吗？而且查询不是写入账本的事务。因此，它不需要订购者。为了进行查询，它将从对等方的本地数据库中提取数据。
因此，我认为可以做的是，当您的应用程序检测到订购者节点故障（带有一些运行状况检查？）时，向生产支持发送警报。并且在建立订购者网络时，您的应用程序会显示一条容量减少/限制的操作消息，系统仍然可以为搜索查询提供服务。
在我看来，这简直太棒了。但最终由您决定。干杯！