吞吐量-Corda的故事

我最近开展了一个针对特定用例的Corda性能项目。这个项目的结果使我们在170多个节点的网络上一天之内处理了1.15亿个请求。此外，Corda每秒能够处理6300个请求，确认满足了网络的最高要求。迄今为止，这是迄今为止已部署的最大的Corda网络，并且实现了最高的吞吐量。证明Corda可以在非常苛刻的环境中交付。

这项研究是由埃森哲为DTCC进行的，该研究还探讨了另一个DLT平台，数字资产。有关更多信息，请参见新闻稿。

DTCC宣布研究结果，表明DLT可以支持美国股票的交易量…
突破性的研究表明，DLT每天可处理超过1亿笔交易纽约/伦敦/香港……www.dtcc.com

在这篇文章中，我将利用我在该项目中获得的经验来描述如何还可以从Corda中获得最大收益。我希望不久的将来会有与我们为DTCC所做的类似的项目，我希望这里的信息可以帮助其他开发人员指明正确的方向。

结果怎么样？好吧，这并非没有困难。但是，我认为我们做得很好。更准确地说，我们证明，如果精心设计网络并精心设计CorDapp，Corda可以达到很高的吞吐量。是的，我知道我基本上是在说，如果您做的一切正确，那么一切都会顺利进行。真的很重要。当我们在整个项目中调整CorDapps时，我们发现了可以大大提高应用程序性能的途径。进行这些更改可以使我们越来越接近我们的目标。但是，如果我们不以特定方式设计网络，那么这一切都将无关紧要。

需要Corda Enterprise来实现最高的性能
这是将性能提高10倍或将计算机的内核数提高最简单的方法。除其他事项外，Corda Enterprise允许在节点内运行的Flow Worker的数量从1增加到很多。这影响了可以在节点内异步运行的流的数量。但是，这不会改变在每个版本上以相同速度运行的各个Flow的性能。实际上，没有企业版，您将永远无法实现极高的性能目标。

如果您的用例不需要达到这种性能，那么开源版本将满足您的需求。例如，由于DTCC处理的请求量和需要处理的比率非常大，因此我们100％需要将Enterprise用于我们的项目。另一方面，如果我们要处理贷款的处理。与DTCC的需求相比，流经节点的请求速率将大大降低。在这种情况下，使用开源就足够了。

方便地，企业代码和开放源代码兼容，使您可以轻松切换。部署方面存在差异，并且在进行更改时很有可能需要摆弄这一方面。

企业版本和开放源代码版本之间的兼容性使您可以尝试两者，从而确定最适合您的需求。这样，您就可以开始在开源上编写应用程序，直到认为有必要切换到企业版为止。

考虑一下您的网络
我确实非常想强调网络体系结构的重要性。我什至不想考虑如果坚持我们的原始设计将会获得的性能。实际上，我们取消了原始设计，因为它从根本上存在缺陷，并且会阻止实现我们目标的任何希望。就我个人而言，我认为本节一半是关于Corda，一半是关于构建一个好的解决方案。

分片以提高大规模性能
在撰写本文时，Corda不支持负载平衡。当前，单个节点将为其代表的身份处理所有工作。这是他们充分意识到的领域，也是他们在不久的将来要努力进行的工作。如果在那里，那么可能有可能仅仅依靠旋转大量支持单个Corda节点的实例。这将导致更多的计算能力，并因此增加吞吐量。

由于负载平衡尚未准备好，而且我们只有一个参与者坐在网络中间，这是处理请求的巨大瓶颈，因此我们不得不以不同的方式处理整个网络设计。作为补偿，我们必须考虑一种方法，以便将我们自己的水平缩放比例提供给系统，因为必须删除位于中间的单个节点。如果不解决这些问题，我们将无法实现每秒6300笔交易的网络吞吐量。

我们的解决方案？分片。我们确定了一种方法，可以从逻辑上将一个参与者分解为许多非常小的部分。每个处理请求彼此并行。这需要一些额外的逻辑来将请求路由到正确的分片节点。但是，此解决方案可能节省了项目。我们从未测试过单个瓶颈节点的性能，但是，我100％确信我们不会达到目标。

下面我提供了两个图表。一种使用单节点设计的示例过程，另一种采用分片方法。

单节点

分片

我将让图表说明一切。由于该信息仍然是机密的，因此我将不进一步研究该实现。那里应该有足够的信息来理解我们为什么做以及做什么，而不是我们如何实现。

您可以想象第二种设计将产生更高的吞吐量。它还具有在将节点添加到网络时线性扩展的优势。

在原始设计中，吞吐量对于少量节点可能是可以接受的。但是，当您遇到较大的数字（例如100），甚至可能只有10时，您会注意到性能下降。这完全是由于整个网络依赖单个瓶颈节点可以处理请求的速率。

消除具有多个公证人的额外瓶颈

可以提高网络整体性能的另一个领域是使用多个公证人。当网络的吞吐量已经很高时，单个公证员将开始成为工作流程的瓶颈。遵循与上一节相同的想法。公证人可以分片。允许每个人处理较小数量的交易。

每当我说“多个公证人”时，我只是想澄清一下我不是在谈论公证人团体。

我已经写了一篇有关利用多个公证人提高网络吞吐量的文章，涵盖了这个主题，而不是重复我自己，我将带你去那里。

调整那些Cordapps

在Cordapps上。您可以在这里做很多事情来提高性能。大部分来自尝试尽可能少地做。

我需要发送所有这些交易吗？
对方是否真的需要签署此交易？
我的交易上有太多州吗？
发起方和交易对手之间的流跳了多少次？

这些都是对流程性能至关重要的问题。我敢肯定还有其他地方可以提高性能（稍后我会介绍），但是这些是我现在唯一想到的地方。我确定你知道图片。

让我们快速看一下最后一个问题。

发起方和交易对手之间的流跳了多少次？

这实际上涵盖了我提出的其他一些观点。无论如何。每次跨网络跳转时，Flow的性能都会下降。它需要从一个Corda节点移动到另一个节点，并且可能需要在某个时候回来。在此期间，由于网络延迟以及将流指向磁盘的检查点的过程，您正在积累性能成本。

网络延迟可以说明一切，不需要进一步说明。另一方面，检查点需要充实一些。检查点是序列化Flow当前执行的过程，以便在发生故障时可以从特定点重新启动它。这样做需要序列化整个流程堆栈，这可能会很大，因此要执行的过程成本很高。

考虑到此信息，请确保您考虑是否真的需要进行这些跳跃。尽量减少它们。如果这样做，我相信您会看到应用程序性能的提高。

这对性能有好处吗？

对对对。虽然，我们没有衡量包括多线程在内的影响，但我确信它取得了很好的改进。但小心点。如果操作不正确，可能会有点麻烦。在撰写本文时，Corda不支持Flows中的多线程。如果这样做，您将得到一些奇怪的错误。话虽如此，这是可能的。您可以在Corda服务中执行此操作，而该服务在Flow的范围之外运行。通过将一些处理委托给服务，我们能够利用线程来启动新的Flow，每个Flow都是异步运行的，处理相似但分离的任务。

我在之前的Corda Services异步流调用文章中对此进行了介绍，该文章深入探讨了该主题，并解释了为什么您最终会在尝试时失败。

使用Corda感觉如何？

我发现使用Corda相对简单。当您尝试实现更复杂的用例时，确实会变得更加困难。但是，在大多数情况下，许多流程可以遵循相同的简单结构。在交易中添加一些状态，进行验证，让所有必要的各方签字并提交交易。

随着事情变得越来越复杂，您需要牢记哪一方需要做什么。例如，花费现金。作为发起者，您不能将他人的现金状态放入交易中。您需要向他们发送一些信息，并要求他们将其添加到交易中。像这样的场景花了我一段时间才能适应。随着越来越多的开发人员花时间在Corda上工作，我相信这些概念将变得更容易理解。将发布更多示例，并将分发有关如何编写良好Flow的知识。

此外，我支持Corda提出的关键概念。仔细阅读这些内容和提供的文档后，我对Corda的理解大大提高了。

关键概念– R3 Corda V3.3文档 本节介绍Corda平台的关键概念和功能。 适用于 docs.corda.net的新手。

向前进

现在，我不代表Corda或R3，但是由于我们在整个项目中都与他们紧密合作，因此我可以说该平台可能有所改进。

使部署多个Corda节点更加容易。 R3与我们合作产生了一个框架，可以更轻松地部署节点，可以对其进行修改和推广，使其适合更广泛的受众。
性能。 Corda代码中的一些区域可以进行调整，以便为获得良好的性能而让路。
更好的多线程。如前所述，这可以在Corda Services中完成，但有可能将其中一些转移到Flows中。主要侧重于异步启动多个subFlow并等待其完成。