我最近开展了一个针对特定用例的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%确信我们不会达到目标。
下面我提供了两个图表。 一种使用单节点设计的示例过程,另一种采用分片方法。
单节点
![科尔达故事](https://i-blog.csdnimg.cn/blog_migrate/24c1c6309b9f0f9c7e19ef22b5a77f4d.png)
分片
![科尔达故事](https://i-blog.csdnimg.cn/blog_migrate/d721e45aef0505d7482d992fadb71f31.png)
我将让图表说明一切。 由于该信息仍然是机密的,因此我将不进一步研究该实现。 那里应该有足够的信息来理解我们为什么做以及做什么,而不是我们如何实现。
您可以想象第二种设计将产生更高的吞吐量。 它还具有在将节点添加到网络时线性扩展的优势。
在原始设计中,吞吐量对于少量节点可能是可以接受的。 但是,当您遇到较大的数字(例如100),甚至可能只有10时,您会注意到性能下降。 这完全是由于整个网络依赖单个瓶颈节点可以处理请求的速率。
消除具有多个公证人的额外瓶颈
可以提高网络整体性能的另一个领域是使用多个公证人。 当网络的吞吐量已经很高时,单个公证员将开始成为工作流程的瓶颈。 遵循与上一节相同的想法。 公证人可以分片。 允许每个人处理较小数量的交易。
每当我说“多个公证人”时,我只是想澄清一下我不是在谈论公证人团体。
我已经写了一篇有关利用多个公证人提高网络吞吐量的文章,涵盖了这个主题,而不是重复我自己,我将带你去那里。
![科尔达故事](https://i-blog.csdnimg.cn/blog_migrate/035feff5a790a5d67feba911e7862040.png)
调整那些Cordapps
在Cordapps上。 您可以在这里做很多事情来提高性能。 大部分来自尝试尽可能少地做。
- 我需要发送所有这些交易吗?
- 对方是否真的需要签署此交易?
- 我的交易上有太多州吗?
- 发起方和交易对手之间的流跳了多少次?
这些都是对流程性能至关重要的问题。 我敢肯定还有其他地方可以提高性能(稍后我会介绍),但是这些是我现在唯一想到的地方。 我确定你知道图片。
让我们快速看一下最后一个问题。
- 发起方和交易对手之间的流跳了多少次?
这实际上涵盖了我提出的其他一些观点。 无论如何。 每次跨网络跳转时,Flow的性能都会下降。 它需要从一个Corda节点移动到另一个节点,并且可能需要在某个时候回来。 在此期间,由于网络延迟以及将流指向磁盘的检查点的过程,您正在积累性能成本。
网络延迟可以说明一切,不需要进一步说明。 另一方面,检查点需要充实一些。 检查点是序列化Flow当前执行的过程,以便在发生故障时可以从特定点重新启动它。 这样做需要序列化整个流程堆栈,这可能会很大,因此要执行的过程成本很高。
考虑到此信息,请确保您考虑是否真的需要进行这些跳跃。 尽量减少它们。 如果这样做,我相信您会看到应用程序性能的提高。
这对性能有好处吗?
对对对。 虽然,我们没有衡量包括多线程在内的影响,但我确信它取得了很好的改进。 但小心点。 如果操作不正确,可能会有点麻烦。 在撰写本文时,Corda不支持Flows中的多线程。 如果这样做,您将得到一些奇怪的错误。 话虽如此,这是可能的。 您可以在Corda服务中执行此操作,而该服务在Flow的范围之外运行。 通过将一些处理委托给服务,我们能够利用线程来启动新的Flow,每个Flow都是异步运行的,处理相似但分离的任务。
我在之前的Corda Services异步流调用文章中对此进行了介绍,该文章深入探讨了该主题,并解释了为什么您最终会在尝试时失败。
![科尔达故事](https://i-blog.csdnimg.cn/blog_migrate/a5a3174c008018dd84b4d9099bddbda1.png)
使用Corda感觉如何?
我发现使用Corda相对简单。 当您尝试实现更复杂的用例时,确实会变得更加困难。 但是,在大多数情况下,许多流程可以遵循相同的简单结构。 在交易中添加一些状态,进行验证,让所有必要的各方签字并提交交易。
随着事情变得越来越复杂,您需要牢记哪一方需要做什么。 例如,花费现金。 作为发起者,您不能将他人的现金状态放入交易中。 您需要向他们发送一些信息,并要求他们将其添加到交易中。 像这样的场景花了我一段时间才能适应。 随着越来越多的开发人员花时间在Corda上工作,我相信这些概念将变得更容易理解。 将发布更多示例,并将分发有关如何编写良好Flow的知识。
此外,我支持Corda提出的关键概念 。 仔细阅读这些内容和提供的文档后,我对Corda的理解大大提高了。
关键概念– R3 Corda V3.3文档 本节介绍Corda平台的关键概念和功能。 适用于 docs.corda.net的新手。
向前进
现在,我不代表Corda或R3,但是由于我们在整个项目中都与他们紧密合作,因此我可以说该平台可能有所改进。
- 使部署多个Corda节点更加容易。 R3与我们合作产生了一个框架,可以更轻松地部署节点,可以对其进行修改和推广,使其适合更广泛的受众。
- 性能。 Corda代码中的一些区域可以进行调整,以便为获得良好的性能而让路。
- 更好的多线程。 如前所述,这可以在Corda Services中完成,但有可能将其中一些转移到Flows中。 主要侧重于异步启动多个
subFlow
并等待其完成。
包起来
在项目快要结束时,它肯定很忙,但是我们在1个月内就能够实现巨大的性能提升,这是疯狂的。 一旦我们改进了CorDapp,以充分发挥其性能,我们的人数便从““”升至“哇”。 幸运的是,我们正确地设计了我们的网络以使这些数字成为可能。 如果网络没有按照原来的方式组合在一起,那么世界上所有的调整都将无法挽救它。
因此,Corda能否获得良好的吞吐量? 是。 是的你可以。 使用Corda Enterprise可以使更高的性能目标更容易实现,并且可以减少最终工作量。 但是,这并不是正确的想法。使用本文中介绍的信息,您应该对如何设计高性能Corda应用程序或网络有更好的了解。
展望未来,Corda的性能只会越来越好。 将其与如何设计应用程序的好主意相结合,应使您的数字从屋顶冒出来。
最后,在关闭这篇文章之前,我只想感谢R3,尤其是Stefano在此项目期间与我们紧密合作。
如果您认为这篇文章有帮助,可以在Twitter上@LankyDanDev关注我,以跟上我的新文章。
翻译自: https://www.javacodegeeks.com/2018/12/throughput-corda-story.html