加密社交媒体：构建 Web3 社交应用需要什么基础设施？

“加密社交媒体”背后隐藏着两个不同的问题

这个术语的搜索结果清晰地分为两类。一些页面是加密社区聚集的社交应用目录，另一些是关于建立在区块链上的去中心化社交网络的解释性文章。这些是不同的受众，做出不同的决策。

如果你是用户、创作者或营销人员，你的问题通常关于覆盖面、托管以及哪个平台值得你花时间。如果你是开发者或基础设施买家，你的问题关于如何运行一个在链上读写数据而不会崩溃的社交应用。本页是为第二类人写的，同时提供足够的背景帮助第一类人定位。

这种区分很重要，因为基础设施建议完全不同。社区管理者不需要考虑归档节点。构建信息流的开发者则需要。

• 社区和目录问题：加密用户在哪里交流，哪些应用活跃，奖励如何运作。
• 构建问题：如何存储身份和内容，如何快速读取信息流，如何订阅事件，如何索引活动。
• 基础设施问题：选择哪个 RPC 提供商，共享节点还是专用节点，归档访问，WebSocket 支持，故障转移。

决策指南：你是在构建、集成，还是仅仅评估？

在比较提供商之前，先确定你处于以下三种情况中的哪一种。每种情况都会导向不同的下一步，而混淆它们是人们过度购买或购买不足基础设施的最常见原因。

下表是一个快速路由指南，不是完整比较。用它来选择本文中适用于你的部分。

Web3 社交应用对 RPC 端点的实际要求

社交应用从外面看很简单：资料、帖子、关注、互动，也许还有打赏或奖励。在底层，每一个都是合约调用或事件，读写比严重偏向读取。一个活跃用户滚动信息流，每写一个帖子可能触发几十次读取。

这种形态改变了你对 RPC 提供商的需求。吞吐量很重要，但方法组合也很重要。信息流和资料读取主要是 eth_call 和类似的读取方法。发帖和互动是交易，需要可靠的 eth_sendRawTransaction 和收据轮询。实时功能需要事件订阅或频繁的日志查询。索引器需要历史日志，这意味着归档访问。

如果你在非 EVM 网络上构建，方法名称不同，但模式相同：大量廉价读取、较少写入以及稳定的事件流。

• 读密集型：资料查找、关注者图谱、信息流组装、互动计数。
• 突发写入：发帖、互动、关注、打赏，尤其是在活动或发布期间。
• 事件驱动：新帖子、提及和互动通常通过日志或订阅呈现。
• 历史数据：索引器和分析需要比最近几个区块更早的日志。

工作负载与基础设施的契合度

同一个 RPC 计划可能适合社交应用的一部分，而不适合另一部分。与其问“哪个提供商最好”，不如将每个工作负载映射到适合它的基础设施。

下表是这种映射的起点。它故意保持通用，因为正确答案取决于你的网络和流量。

单个公共端点在哪里崩溃

大多数 Web3 社交应用从公共或共享 RPC 端点开始，这是原型开发的合理方式。当三件事同时发生时，问题就会出现：信息流变得繁忙，索引器运行回填，通知工作者轮询新事件。三者都在竞争相同的速率预算。

症状很熟悉。在高峰活动期间读取开始超时。交易提交间歇性失败。日志查询返回部分结果或被限速。这些起初看起来都不像基础设施问题；它们看起来像应用中的错误。

解决方法通常是分离而不是更大的单个端点。给面向用户的读取自己的路径，给索引器自己的路径并具有归档访问，给通知一个订阅友好的路径。OnFinality 的 RPC API 和专用节点选项的结构支持这种分离，当你超出共享端点时。

• 高峰信息流活动期间读取超时。
• 间歇性交易提交失败，难以复现。
• 日志查询静默返回少于预期的结果。
• 一个后台任务降低每个用户的体验。

社交应用工作负载的提供商评估矩阵

当你为社交应用比较 RPC 提供商时，标准与交易机器人或桥略有不同。你不太关心超低延迟的区块流，而更关心持续的读取吞吐量、归档深度、订阅支持以及你能多干净地隔离工作负载。

下表列出了要检查的标准以及好的答案是什么样的。OnFinality 作为选项列在首位；其他行是你应该问任何提供商的问题。

实用的推出顺序

你不需要在拥有用户之前解决基础设施问题。一个合理的顺序是在共享端点上进行原型开发，测量你的读写模式，然后随着工作负载开始相互干扰而分离它们。

第一个拆分通常是索引器，因为它是最重且最不面向用户的。第二个是通知，因为订阅的行为与请求-响应调用不同。面向用户的读取最后，一旦你知道真实容量。

在整个过程中，保持提供商决策可逆。使用标准 JSON-RPC 方法，将端点配置放在环境变量中，避免在核心路径中使用提供商特定功能，这样你可以在不重写的情况下移动流量。

• 在共享端点上进行原型开发并记录你的方法组合。
• 将索引移动到具有归档访问的自己的端点。
• 为通知添加订阅友好的路径。
• 通过缓存扩展面向用户的读取，如果需要则使用专用节点。
• 保持端点可配置，以便你可以故障转移或迁移。

常见问题