我正在使用Hyperledger Fabric开发投票应用程序。
在投票的情况下，最多交易的数量是人数，因为每个人只能投票一次。
但是，我们不知道在投票开始之前会有多少人投票。这使我们不必要地准备了许多REST服务器来覆盖总人数（潜在投票者），这增加了成本。
那么，是否有可能根据Hyperledger架构中的实时流量来扩展节点数量？
答案 0 :(得分：0)
不，这是不可能的，因为要执行其工作，节点（对等或订购者）将需要拥有区块链的所有块。
因此，要扩大节点数量，您需要等待，直到新节点从其他节点复制了块为止，这将需要一些时间。
另一个问题是，将新的对等方添加到频道是手动过程，需要用户干预。
答案 1 :(得分：0)
说实话，到目前为止您所说的还不多，听起来Hyperledger实际上不适合该项目。
重点是提供一个可让所有参与者都知道的可信系统。参与者是指组织。一个组织加入了一个渠道，然后向其添加了对等方。
REST API是围绕对等体构建的，就像每个对等体都使用一个REST API一样。因此，是的，从理论上讲，您可以扩展，扩展另一个对等方，创建API等，所有这些都可以通过脚本自动完成。您的主要问题是知道什么时候流量太大以及什么时候开始增加流量。另外，您可能会启动一个新端点，但是您的应用程序应该如何知道一个新端点可用？
我想您可以构建一个Facade系统，并且当您的脚本旋转一个新的对等体并公开一个新的API时，这时可以报告给应用程序，以便它维护可用API的列表，听起来很像工作几乎没有收获。
我想知道，为什么不简单地构建一个普通的API，将其放在云中，让它通过内置工具自动扩展，完成工作呢？
除了所有这些，如果现在更改现在为时已晚，也许您可以采用其他方式来进行更改。您的应用可能正在与排队系统对话，这是将选票推向对等方（如果可用）的系统。如果不可用，它可以等待，这仅表示投票将在稍后进行。因此，您的应用程序不会直接与REST API对话，不会将带有投票的消息发送到队列，然后您可以使用另一个应用程序监视此队列并使用REST API（如果它们已启动）。您甚至可以实施一个系统，在此系统中，您可以决定在一段时间内或每次之内一次发送多少票。您仍然可以扩展Web应用程序，以使用户的流量没有任何问题。