作者：NKN Labs CTO 張逸

什麽是Pub / Sub

NKN客戶端的一個基本功能（例如https://github.com/nknorg/nkn-client-js）是提供去中心化的消息傳遞系統，包括單播，多播和任播。如果消息發送者知道誰是接收者，那就足夠了。但是，在許多常見情況下，接收器應在邏輯上與發送方分離。例如，當我向聊天室發送消息時，我不一定確切地知道聊天室中有誰，我只想讓聊天室中的任何人能接收我的消息。這就是Pub/sub能實現的功能。

簡單來說，Pub/sub（發布/訂閱的簡稱）是一種將消息發送者（發布者）和接收者（訂閱者）解耦的模型。發布者將消息發布到主題（我們僅在此處考慮基於主題的Pub/sub），而無需知道誰訂閱該主題並將接收到消息。訂閱者訂閱主題並將收到別人發送到此主題的消息。發布/訂閱是現代應用程序的基本構建模塊，並且已廣泛用於從基礎設施級別（例如負載均衡）到應用程序級別（例如聊天室/即時聊天軟件等）。

Google雲的以下圖表（https://cloud.google.com/pubsub/docs/overview）顯示了發布者，訂閱者和主題之間的關系：

發布者應用創建主題並將消息發送到主題。訂閱者應用創建對主題的訂閱以便從其接收消息。通信可以是一對多（扇出）、多對一（扇入）和多對多。

分布式Pub / Sub的挑戰

像Google Cloud，AWS這樣的雲服務商提供基於雲的發布/訂閱，但是它們的集中化屬性使得它們很難（如果不是不可能的話）用於分布式的應用程序中。

另一方面，建立去中心化的發布/訂閱也具有挑戰性，因為大多數現有的去中心化系統（例如以太坊）並不太適合實時消息———想象一下在它上面發送單個消息將花費超過1美元並且需要幾乎一分鐘才能傳達，怎麽能期望它在實際中可用呢？更不用說它的可擴展性問題。

更通俗一點來說，基於現有的去中心化系統（最有可能是基於區塊鏈）構建分布式的Pub / sub存在下述困難：

· 消息需要實時傳遞

· 消息傳遞開銷需要是可負擔得起的

· 消息吞吐量需要支持水平可擴展

如果是沒有區塊鏈背景的人，可能會覺得上述“挑戰”看起來貌似是微不足道的。實際情況是，如果我們依靠鏈上交易來傳遞信息，那麽解決上述問題是非常困難的。

這些問題的一個解決方案是使用鏈下消息傳遞機制。這就是為什麽我們認為NKN非常適合作為分布式 Pub/sub系統的基礎設施：NKN中的消息傳遞是即時的（端到端延遲毫秒級），免費和水平可擴展

建立分布式的Pub / Sub

要構建Pub/sub系統，我們需要解決兩個基本問題：如何存儲和檢索主題 和 訂閱者信息以及如何投遞消息。雖然NKN網絡輕松地解決了第二個問題，但我們仍然需要確定訂戶信息的存儲位置。

經過多番討論，我們決定將主題 - 訂戶信息存儲在鏈上。因此，訂閱需要在交易中完成，這將是可靠的但不是水平可擴展的。幸運的是，與發布相比，訂閱是一種不那麽頻繁的行為，所以它不會成為系統瓶頸。

經過一些工作和測試，我們現在可以自豪地說NKN的Pub/sub機制工作得非常好。由於發布主要是發送鏈下消息，因此它被集成到了NKN客戶端（例如https://github.com/nknorg/nkn-client-js）。

另一方面，訂閱被整合到NKN錢包（例如https://github.com/nknorg/nkn-wallet-js）中，因為它需要簽署和發送交易。兩者都集成到NKN SDK（例如https://github.com/nknorg/nkn-sdk-go），其中包含NKN客戶端和NKN錢包。

使用Pub / Sub

有關如何使用Pub/sub的詳細信息可以在各種NKN客戶端/錢包/ SDK實現的文檔中找到。API的調用也非常簡單。例如，在JavaScript實現中，訂閱主題只需如下簡單操作:

[code/

wallet.subscribe(topic, bucket, duration)

[/code/

我們有桶概念的原因是在有大量訂閱者的情況下避免（意外）消息泛濫，並且可以被更高層的API（如SubscribeToFirstAvailableBucket）隱藏。同樣，發布到主題也很簡單:

[code]

client.publish(topic, bucket, message)

[/code]

可以通過GetTopicBucketsCount之類的API獲取主題的存儲桶數。訂閱該主題的客戶端可以監聽消息:

[code]

client.on(‘message‘, (src, payload, payloadType) => {

});

[/code]

用例和摘要

Pub/Sub已廣泛用於許多系統和應用程序中。根據Gartner估計，應用程序基礎架構和中間件（其中Pub/sub是關鍵部分）的市場總額為215億美元。除了現有的應用之外，我還想深入研究一個更適合分布式應用程序的新課題。

絕大多數集中式應用程序不是開源的，協議通常僅與應用程序綁定。另一方面，分布式應用程序通常是開源的，協議與實現解耦，以允許不同實現的互聯通信。這極大地減少了設計和實現交叉應用協議的摩擦。如果多個應用程序想要共享相同的信息流，那麽去中心化的，應用程序中立的語言和中立的Pub/sub平臺將是必不可少的。

舉例來說：

• 不同的服務提供商希望共享相同的服務發現機制

• 多個應用程序希望共享相同的評級系統

• 應用程序希望將數據傳遞給共享協議的下遊應用程序

基於NKN的分布式Pub/sub可用於很好的實現這些目標。簡言之，這代表了去中心化應用程序中最有趣的屬性之一（在我看來）—— 應用程序、協議和數據的分離。NKN的技術具有獨特的定位和創意，可以充分利用這一機會。我們很快將發布更多基於NKN的分布式Pub/ sub框架的內容，感興趣的朋友們可持續關註。

背景知識

什麽是Cloud Pub / sub

https://cloud.google.com/pubsub/docs/overview

Cloud Pub/Sub靈活可靠地將企業消息-定向的中間件帶入雲平臺中。同時，Cloud Pub/Sub是一個可擴展的、持久的事件提取和傳遞系統，可作為現代流分析通道的基礎。通過提供將發送者和接收者分離的多對多異步消息傳遞，它允許獨立編寫的應用程序之間的安全和高度可用的通信。Cloud Pub/Sub提供低延遲、持久的消息傳遞，幫助開發人員快速集成托管在Google雲平臺和外部的系統。

核心概念

主題：發布者向其發送消息的命名資源。

訂閱：一種命名資源，表示要傳遞給訂閱應用程序的單個特定主題的消息流。有關訂閱和郵件傳遞語義的更多詳細信息，請參閱“訂閱者指南”。

消息：發布者發送主題並最終傳遞給訂閱者的數據和（可選）屬性的組合。

消息屬性：發布者可以為消息定義的鍵值對。例如，可以將keyiana.org/language_tag和value en添加到消息中，以將其標記為英語訂閱者可讀。

優點

（https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern#Advantages）

松耦合

發布者與訂閱者松散耦合，甚至不需要知道它們的存在。以主題為重點，允許發布者和訂閱者不知道系統拓撲。每個都可以按照正常情況繼續獨立運行。在傳統的緊密耦合的客戶端 - 服務器實例中，客戶端無法在服務器進程未運行時將消息發布到服務器上，除非客戶端正在運行，否則服務器也不能接收消息。許多消息發布/訂閱系統不僅將發布者和訂閱者的位置分離，而且還在時間上將它們分離。中間件分析師使用這種發布/訂閱系統的常用策略是取消發布者以允許訂閱者處理積壓（一種帶寬限制形式）。

可擴展性

Pub/sub提供了比傳統客戶端 - 服務器更好的彈性服務，通過並行操作，消息緩存，基於樹或基於網絡的路由等。但是，在某些類型的緊密耦合的大容量企業環境中，作為系統擴展成為數千個服務器共享發布/訂閱基礎設施的數據中心，當前的供應商系統經常得不到這份好處; 在這些環境中高負荷下的Pub/sub產品的可擴展性是一項研究挑戰。

另一方面，在企業環境之外，Pub/sub實例已經證明其可擴展性遠遠超過單個數據中心的容量，通過RSS和Atom等網絡聯合協議提供互聯網範圍的分布式消息傳遞。這些聯合協議接受更高的等待時間和傳送保證的缺位，以換取更低端網絡服務器將消息聯合到（可能）數百萬個單獨的訂戶節點的能力。

關於NKN

NKN是一個完全去中心化，基於網絡傳輸量工作證明，可支持千萬級規模節點共識的區塊鏈系統。由NKN所構建的這樣一個有經濟模型所驅動，社區共建共享的新型點對點網絡，為開發者提供了一個開放、便捷、高效和安全的網絡連接傳輸平臺。基於NKN開發的各種應用將給終端用戶帶來各種全新的網絡體驗。

基於NKN的分布式Pub / Sub服務