Syndica Cloud 推出了其在 Solana 上的 web3 原生云堆栈的 V2 版本。
这篇帖子是我们介绍 Syndica Cloud 系列文章的第一部分,它是我们在 Solana 上的高级 web3 原生云栈。它重点介绍了我们 RPC 基础设施中关键组件的 V2 实现。敬请关注后续文章,探索其他新功能,如高级速率限制、ChainStream API、应用程序部署、动态索引等。
自 2021 年以来,基于我们在 Solana RPC 方面的经验,我们对基础设施的核心组件进行了重新设计,以提供一流的开发者体验。在这里,我们重点介绍核心基础设施、Edge Gateway、指标和分析方面的这些进展。
在 Syndica Cloud 中,我们实现了多区域支持,并具有自动地理位置路由功能。我们最初的推出包括 us-east
(弗吉尼亚州)、us-west
(俄勒冈州) 和 eu-west
(伦敦)。现在,使用 api.syndica.io
,请求会自动定向到最近的区域,以确保尽可能低的延迟。我们比较了所有顶级 Solana RPC 供应商的 RPC 延迟,以验证我们的 V2 是否是一流的:
我们优化了节点配置以及新的硬件,以最大限度地提高性能和可靠性。利用我们的 RPC 节点运营经验,我们向上游的验证器仓库做出了贡献,包括显著的内存使用改进,该改进已合并到此 PR 中:https://github.com/anza-xyz/agave/pull/1137 (包含技术细节的原始 PR 在这里:https://github.com/solana-labs/solana/pull/34955)。
Edge Gateway 是我们的 API 路由服务,用于 RPC 请求,确保快速可靠的性能。它平衡了运行状况良好的 RPC 节点之间的请求并保持正常运行时间,即使在云或硬件中断期间也是如此,使其成为我们 RPC 基础设施的支柱。
我们最初的 API 路由服务是用 Go 实现的,它有其优点,但为了真正最大限度地提高性能并最大限度地减少维护开销,我们用 Rust 重新实现了它。Rust 提供了对分配、性能和错误处理的卓越控制,使我们能够在编译时捕获更多问题并确保最佳性能。
我们使用各种参数在不同的 RPC 方法上测试了我们的 V2 实现,发现平均响应时间快了约 2.5 倍:
订阅多路复用是重用来自 RPC 节点的单个现有订阅,以将数据流式传输到多个相同的客户端订阅。我们实现了机会性订阅多路复用,以减少订阅创建延迟和相关成本。
当请求新的订阅时,我们会快速检查上游 RPC 节点上是否已存在相同的订阅。如果存在,则会重用它,而无需向上游节点发出新的请求,从而使它们能够以更低的负载和延迟来服务更多请求。
多路复用是机会性地应用的,这意味着只要有匹配的现有订阅可用,就会发生多路复用。如果未找到匹配项,则会立即创建新的订阅,而不会延迟。在最坏的情况下,连接的行为类似于标准的非多路复用订阅,而没有延迟改进。在最好的情况下,多路复用通过消除冗余请求来减少延迟。
此图显示了一个示例,其中一个上游 RPC 节点 slotSubscribe
订阅流式传输三个相同客户端 slotSubscribe
订阅的数据,以及一个 pubkey 为 DriFTm3wM9ugxhCA1K3wVQMSdC4Dv4LNmyZMmZiuHRpp
的上游 RPC 节点 accountSubscribe
订阅流式传输两个相同客户端 accountSubscribe
订阅的数据。
Edge Gateway 充当 RPC 节点的反向代理和负载平衡器,确保来自同一客户端到 api.syndica.io
的顺序请求分布在多个 RPC 节点上,以获得最佳性能和可靠性。
通常,这种负载平衡行为可确保请求均匀分布在各个节点上,从而最大限度地减少延迟。但是,在某些情况下,将顺序 RPC 请求定向到同一节点有利于获得网络的“顺序一致”视图。由于 RPC 节点将信息传播到彼此的方式存在固有的延迟,因此不同的节点可能并不总是就最新数据达成一致。将顺序请求定向到单个节点可以缓解此问题,从而提供网络状态的一致视图。
例如,当使用 getSlot
RPC 方法 (https://solana.com/docs/rpc/http/getslot) 时,由于 slot 号不断递增,因此将重复的 getSlot
请求发送到同一 RPC 节点将始终返回一个大于或等于前一个请求的值。但是,由于节点之间 slot 生成的差异,将这些请求发送到不同的 RPC 节点可能会导致收到的 slot 号低于前一个请求,其中某些节点可能会落后于其他节点。
我们的 RPC API 允许通过请求标头中的 X-Syndica-Affinity
标头分配节点亲和性,从而可以精确控制请求路由。此功能可确保顺序请求将由同一节点处理,从而提供一致性和控制。有关更多详细信息,请参阅此处的文档。
我们通过添加对 br
(brotli) 的支持来增强了响应压缩功能,同时通过 HTTP 请求中的标准 Accept-Encoding
标头保持 gzip
压缩。
我们彻底改进了速率限制系统,以提高性能并在凭据级别实现更精细的自定义。现在,你可以为 API 密钥配置单独的限制,以用于 RPC 调用、WS 连接和订阅。
你还可以选择为不同的 RPC 方法设置单独的限制,并在单个 IP 级别应用限制。有关详细信息,请参阅我们的文档 https://docs.syndica.io/platform/concepts/api-keys。
请继续关注有关此具有影响力的功能的深入博客文章及其对去中心化应用程序 (dApp) 的重要性。
在内部,我们开发了广泛的指标和严格的测试协议,以确保 API 稳定并通过迭代更新不断提高性能。我们正在进行的基础设施改进旨在显著减少延迟并提高整体网络可访问性。
我们开发了一种名为 Gateway Tester 的专用服务,用于持续集成测试。此工具在我们的集群中不断运行,发出请求并验证预期行为。它可以防止 API 倒退并作为我们服务的额外监视器。
我们统一了指标聚合和监视,以涵盖基础设施的每一层:云服务、硬件节点、Kubernetes、容器和所有代码/Web 服务。
我们为暂存和生产环境开发了一套全面的警报,这些警报利用了来自我们内部服务和 API 请求的全部新指标。
我们扩展了基础设施,以确保在更新期间整个平台(网站、仪表板、API 等)的服务降级程度降至最低甚至没有。虽然我们一直优先考虑这一点,但过渡到 Edge Gateway 增强了我们维护无缝服务的能力。
总而言之,这个坚实的基础确保我们仍然是 RPC 基础设施的领导者。
无论是分析数据使用情况还是调查特定方法的延迟,指标都在获取实时见解方面发挥着至关重要的作用。我们重新构想了指标系统,以增强可用性和性能,确保简化对基本信息的访问。
我们完全重新设计了指标系统,以支持实时仪表板和快速聚合,能够以闪电般的速度处理每月数十亿个请求。现在,用户可以轻松按方法、错误、延迟等查看细分,而不会遇到页面加载延迟。
日志和指标现在配备了按命名空间(solana-mainnet
、chainstream
等)无缝过滤的功能,并且经过精心设计,可以支持未来所有 Syndica API。我们的目标是通过提供统一的信息中心来消除不必要的页面导航和不熟悉的 UI。例如,无论是使用 RPC 基础设施还是访问 ChainStream 数据,查看指标都会感觉非常熟悉和直观。
除了重新实施核心基础设施之外,我们还优化了定价,以更好地服务于个人开发者和高级企业。
立即开始免费使用 标准模式。你将获得每月 1000 万次的免费 RPC 调用,最高可达每秒 100 个请求 (RPS) 和一次免费的应用部署。无需访问费。
当你的应用准备好扩展时,请升级到 扩展模式。只需 199 美元,你将获得每月 2 亿次的 RPC 调用、300 RPS 和 1TB 的数据传输。立即注册 并启用扩展模式,即可获得 3 个月的免费服务,价值 600 美元。
寻求 Solana 基础设施中优质白手套服务的大型企业应咨询我们的 超大规模模式 。我们将为你设置自定义限制,以实现更高的 RPC 数量和 RPS、专用支持、无与伦比的可靠性和以用户为中心的导向。在超大规模模式下,你可以完全专注于发展业务。
我们将 web3 开发堆栈的各个方面统一到一个无缝平台中。现在,你可以忘记处理多个 RPC 提供商、托管服务或其他 Solana 特定的需求,我们将为你处理一切。
立即开始免费使用,并查看我们的此处文档。
- 原文链接: blog.syndica.io/introduc...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!