我最近開展了一個針對特定用例的Corda性能項目。 這個項目的結果使我們在170多個節(jié)點的網(wǎng)絡上一天之內(nèi)處理了1.15億個請求。 此外，Corda每秒能夠處理6300個請求，確認滿足了網(wǎng)絡的最高要求。 迄今為止，這是迄今為止已部署的最大的Corda網(wǎng)絡，并且實現(xiàn)了最高的吞吐量。 證明Corda可以在非常苛刻的環(huán)境中交付。

這項研究是由埃森哲為DTCC進行的，該研究還探討了另一個DLT平臺，數(shù)字資產(chǎn)。 有關更多信息，請參見新聞稿。

DTCC宣布研究結果，表明DLT可以支持美國股票的交易量…
突破性的研究表明，DLT每天可處理超過1億筆交易紐約/倫敦/香港……www.dtcc.com

在這篇文章中，我將利用我在該項目中獲得的經(jīng)驗來描述如何還可以從Corda中獲得最大收益。 我希望不久的將來會有與我們?yōu)镈TCC所做的類似的項目，我希望這里的信息可以幫助其他開發(fā)人員指明正確的方向。

結果怎么樣？ 好吧，這并非沒有困難。 但是，我認為我們做得很好。 更準確地說，我們證明，如果精心設計網(wǎng)絡并精心設計CorDapp，Corda可以達到很高的吞吐量。 是的，我知道我基本上是在說，如果您做的一切正確，那么一切都會順利進行。 真的很重要。 當我們在整個項目中調(diào)整CorDapps時，我們發(fā)現(xiàn)了可以大大提高應用程序性能的途徑。 進行這些更改可以使我們越來越接近我們的目標。 但是，如果我們不以特定方式設計網(wǎng)絡，那么這一切都將無關緊要。

需要Corda Enterprise來實現(xiàn)最高的性能
這是將性能提高10倍或?qū)⒂嬎銠C的內(nèi)核數(shù)提高最簡單的方法。 除其他事項外，Corda Enterprise允許在節(jié)點內(nèi)運行的Flow Worker的數(shù)量從1增加到很多。 這影響了可以在節(jié)點內(nèi)異步運行的流的數(shù)量。 但是，這不會改變在每個版本上以相同速度運行的各個Flow的性能。 實際上，沒有企業(yè)版，您將永遠無法實現(xiàn)極高的性能目標。

如果您的用例不需要達到這種性能，那么開源版本將滿足您的需求。 例如，由于DTCC處理的請求量和需要處理的比率非常大，因此我們100％需要將Enterprise用于我們的項目。 另一方面，如果我們要處理貸款的處理。 與DTCC的需求相比，流經(jīng)節(jié)點的請求速率將大大降低。 在這種情況下，使用開源就足夠了。

方便地，企業(yè)代碼和開放源代碼兼容，使您可以輕松切換。 部署方面存在差異，并且在進行更改時很有可能需要擺弄這一方面。

企業(yè)版本和開放源代碼版本之間的兼容性使您可以嘗試兩者，從而確定最適合您的需求。 這樣，您就可以開始在開源上編寫應用程序，直到認為有必要切換到企業(yè)版為止。

考慮一下您的網(wǎng)絡
我確實非常想強調(diào)網(wǎng)絡體系結構的重要性。 我什至不想考慮如果堅持我們的原始設計將會獲得的性能。 實際上，我們?nèi)∠嗽荚O計，因為它從根本上存在缺陷，并且會阻止實現(xiàn)我們目標的任何希望。 就我個人而言，我認為本節(jié)一半是關于Corda，一半是關于構建一個好的解決方案。

分片以提高大規(guī)模性能
在撰寫本文時，Corda不支持負載平衡。 當前，單個節(jié)點將為其代表的身份處理所有工作。 這是他們充分意識到的領域，也是他們在不久的將來要努力進行的工作。 如果在那里，那么可能有可能僅僅依靠旋轉大量支持單個Corda節(jié)點的實例。 這將導致更多的計算能力，并因此增加吞吐量。

由于負載平衡尚未準備好，而且我們只有一個參與者坐在網(wǎng)絡中間，這是處理請求的巨大瓶頸，因此我們不得不以不同的方式處理整個網(wǎng)絡設計。 作為補償，我們必須考慮一種方法，以便將我們自己的水平縮放比例提供給系統(tǒng)，因為必須刪除位于中間的單個節(jié)點。 如果不解決這些問題，我們將無法實現(xiàn)每秒6300筆交易的網(wǎng)絡吞吐量。

我們的解決方案？ 分片。 我們確定了一種方法，可以從邏輯上將一個參與者分解為許多非常小的部分。 每個處理請求彼此并行。 這需要一些額外的邏輯來將請求路由到正確的分片節(jié)點。 但是，此解決方案可能節(jié)省了項目。 我們從未測試過單個瓶頸節(jié)點的性能，但是，我100％確信我們不會達到目標。

下面我提供了兩個圖表。 一種使用單節(jié)點設計的示例過程，另一種采用分片方法。

單節(jié)點

分片

我將讓圖表說明一切。 由于該信息仍然是機密的，因此我將不進一步研究該實現(xiàn)。 那里應該有足夠的信息來理解我們?yōu)槭裁醋鲆约白鍪裁?#xff0c;而不是我們?nèi)绾螌崿F(xiàn)。

您可以想象第二種設計將產(chǎn)生更高的吞吐量。 它還具有在將節(jié)點添加到網(wǎng)絡時線性擴展的優(yōu)勢。

在原始設計中，吞吐量對于少量節(jié)點可能是可以接受的。 但是，當您遇到較大的數(shù)字（例如100），甚至可能只有10時，您會注意到性能下降。 這完全是由于整個網(wǎng)絡依賴單個瓶頸節(jié)點可以處理請求的速率。

消除具有多個公證人的額外瓶頸

可以提高網(wǎng)絡整體性能的另一個領域是使用多個公證人。 當網(wǎng)絡的吞吐量已經(jīng)很高時，單個公證員將開始成為工作流程的瓶頸。 遵循與上一節(jié)相同的想法。 公證人可以分片。 允許每個人處理較小數(shù)量的交易。

每當我說“多個公證人”時，我只是想澄清一下我不是在談論公證人團體。

我已經(jīng)寫了一篇有關利用多個公證人提高網(wǎng)絡吞吐量的文章，涵蓋了這個主題，而不是重復我自己，我將帶你去那里。

調(diào)整那些Cordapps

在Cordapps上。 您可以在這里做很多事情來提高性能。 大部分來自嘗試盡可能少地做。

• 我需要發(fā)送所有這些交易嗎？
• 對方是否真的需要簽署此交易？
• 我的交易上有太多州嗎？
• 發(fā)起方和交易對手之間的流跳了多少次？

這些都是對流程性能至關重要的問題。 我敢肯定還有其他地方可以提高性能（稍后我會介紹），但是這些是我現(xiàn)在唯一想到的地方。 我確定你知道圖片。

讓我們快速看一下最后一個問題。

• 發(fā)起方和交易對手之間的流跳了多少次？

這實際上涵蓋了我提出的其他一些觀點。 無論如何。 每次跨網(wǎng)絡跳轉時，Flow的性能都會下降。 它需要從一個Corda節(jié)點移動到另一個節(jié)點，并且可能需要在某個時候回來。 在此期間，由于網(wǎng)絡延遲以及將流指向磁盤的檢查點的過程，您正在積累性能成本。

網(wǎng)絡延遲可以說明一切，不需要進一步說明。 另一方面，檢查點需要充實一些。 檢查點是序列化Flow當前執(zhí)行的過程，以便在發(fā)生故障時可以從特定點重新啟動它。 這樣做需要序列化整個流程堆棧，這可能會很大，因此要執(zhí)行的過程成本很高。

考慮到此信息，請確保您考慮是否真的需要進行這些跳躍。 盡量減少它們。 如果這樣做，我相信您會看到應用程序性能的提高。

這對性能有好處嗎？

對對對。 雖然，我們沒有衡量包括多線程在內(nèi)的影響，但我確信它取得了很好的改進。 但小心點。 如果操作不正確，可能會有點麻煩。 在撰寫本文時，Corda不支持Flows中的多線程。 如果這樣做，您將得到一些奇怪的錯誤。 話雖如此，這是可能的。 您可以在Corda服務中執(zhí)行此操作，而該服務在Flow的范圍之外運行。 通過將一些處理委托給服務，我們能夠利用線程來啟動新的Flow，每個Flow都是異步運行的，處理相似但分離的任務。

我在之前的Corda Services異步流調(diào)用文章中對此進行了介紹，該文章深入探討了該主題，并解釋了為什么您最終會在嘗試時失敗。

使用Corda感覺如何？

我發(fā)現(xiàn)使用Corda相對簡單。 當您嘗試實現(xiàn)更復雜的用例時，確實會變得更加困難。 但是，在大多數(shù)情況下，許多流程可以遵循相同的簡單結構。 在交易中添加一些狀態(tài)，進行驗證，讓所有必要的各方簽字并提交交易。

隨著事情變得越來越復雜，您需要牢記哪一方需要做什么。 例如，花費現(xiàn)金。 作為發(fā)起者，您不能將他人的現(xiàn)金狀態(tài)放入交易中。 您需要向他們發(fā)送一些信息，并要求他們將其添加到交易中。 像這樣的場景花了我一段時間才能適應。 隨著越來越多的開發(fā)人員花時間在Corda上工作，我相信這些概念將變得更容易理解。 將發(fā)布更多示例，并將分發(fā)有關如何編寫良好Flow的知識。

此外，我支持Corda提出的關鍵概念 。 仔細閱讀這些內(nèi)容和提供的文檔后，我對Corda的理解大大提高了。

關鍵概念– R3 Corda V3.3文檔 本節(jié)介紹Corda平臺的關鍵概念和功能。 適用于 docs.corda.net的新手。

向前進

現(xiàn)在，我不代表Corda或R3，但是由于我們在整個項目中都與他們緊密合作，因此我可以說該平臺可能有所改進。

• 使部署多個Corda節(jié)點更加容易。 R3與我們合作產(chǎn)生了一個框架，可以更輕松地部署節(jié)點，可以對其進行修改和推廣，使其適合更廣泛的受眾。
• 性能。 Corda代碼中的一些區(qū)域可以進行調(diào)整，以便為獲得良好的性能而讓路。
• 更好的多線程。 如前所述，這可以在Corda Services中完成，但有可能將其中一些轉移到Flows中。 主要側重于異步啟動多個subFlow并等待其完成。

包起來

在項目快要結束時，它肯定很忙，但是我們在1個月內(nèi)就能夠?qū)崿F(xiàn)巨大的性能提升，這是瘋狂的。 一旦我們改進了CorDapp，以充分發(fā)揮其性能，我們的人數(shù)便從““”升至“哇”。 幸運的是，我們正確地設計了我們的網(wǎng)絡以使這些數(shù)字成為可能。 如果網(wǎng)絡沒有按照原來的方式組合在一起，那么世界上所有的調(diào)整都將無法挽救它。

因此，Corda能否獲得良好的吞吐量？ 是。 是的你可以。 使用Corda Enterprise可以使更高的性能目標更容易實現(xiàn)，并且可以減少最終工作量。 但是，這并不是正確的想法。使用本文中介紹的信息，您應該對如何設計高性能Corda應用程序或網(wǎng)絡有更好的了解。

展望未來，Corda的性能只會越來越好。 將其與如何設計應用程序的好主意相結合，應使您的數(shù)字從屋頂冒出來。

最后，在關閉這篇文章之前，我只想感謝R3，尤其是Stefano在此項目期間與我們緊密合作。

如果您認為這篇文章有幫助，可以在Twitter上@LankyDanDev關注我，以跟上我的新文章。

翻譯自: https://www.javacodegeeks.com/2018/12/throughput-corda-story.html

總結

以上是生活随笔為你收集整理的吞吐量-Corda的故事的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。