基于NKN的分布式Pub / Sub服务

Posted 2021-11-27 nknnet

作者：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开发的各种应用将给终端用户带来各种全新的网络体验。