边缘层如何让 Alchemy 上的 RPC 更快
作者：Uttam Singh
如今，每年有数万亿美元的价值通过区块链基础设施流转。Solana 上的一笔 DeFi 兑换、Ethereum 上的一笔稳定币转账、Polygon 上的一笔预测市场结算——这些交易都依赖于经过多层网络传输后才能到达节点的 RPC 调用。当金融活动运行在链上时，这条路径上的每一毫秒都关系到资金安全。
对于一个每年在100 多个区块链网络上处理数万亿次请求的基础设施提供商来说，用户与数据中心之间的这一层，正是性能胜负的关键所在。这一层就是边缘层。2025 年末，Alchemy 从零开始重建了它。
RPC 延迟为何对链上金融很重要？
区块链用户和应用程序分布在全球各地。新加坡的一个交易机器人、法兰克福的一个钱包应用、弗吉尼亚州的一个 DeFi 协议后端——它们都需要发起 RPC 调用来读取链上状态、提交交易。这些调用的响应速度越快，体验就越好。
在 DeFi 中，延迟直接影响执行质量。eth_call 响应变慢，意味着价格数据过时。交易提交延迟，意味着成交价更差或交易失败。对钱包应用而言，加载时间每多出 100ms，用户留存所依赖的体验就会下降一分。
但延迟只是问题的一半，可靠性同样重要。如果你的 RPC 提供商将所有流量都通过单一的第三方 CDN 路由，那么这个 CDN 就成了单点故障。一旦它宕机，所有网络、所有客户、所有请求都会随之瘫痪。
什么是 Alchemy Edge Proxy？
可以把 Edge Proxy 看作是 Alchemy RPC 基础设施的前门。每一个 API 请求——无论是读取 Ethereum 状态、查询 Solana 账户，还是在 Base 上提交交易——在到达后端服务基础设施之前，都要先经过这一入口层。
多年来，Alchemy 一直使用一个主流 CDN 作为这道前门。CDN 之所以成为业界的普遍选择，是有道理的：它们开箱即用地提供 DDoS 防护、地理路由、WAF 规则和 SSL 终止。对大多数 Web 应用来说，这套方案已经够用。二十年来，从电商到流媒体，CDN 一直是默认的入口层，这个地位是它们凭实力赢得的。
链上金融的需求不同。RPC 流量具有突发性、对延迟敏感、地理上遍布全球，且在安全性上有着普通 Web 流量所不具备的关键性要求。一个并行读取三条链状态的交易机器人，并不关心 CDN 能否在 50 个城市缓存一个营销页面，它关心的是发出 eth_call 到收到响应之间的时间。一个同步余额的钱包不需要针对 SQL 注入的 WAF 规则，它需要的是尽可能近的边缘节点，以及能在个位数毫秒内完成的 TLS 握手。一个在衍生品交易所结算头寸的协议，无法接受把第三方 CDN 的故障处理时限当作自身正常运行时间的上限。
为满足这些需求，我们在裸金属上构建了一套自研的边缘代理：一个从零开始为高吞吐、低延迟区块链 RPC 流量设计的入口层。它运行在 Alchemy 自主掌控的、分布于全球多个区域的基础设施上，用可按网络调优的同等或更强的防护层替代了 CDN 层的每一项保护，并彻底移除了关键服务路径上的第三方依赖。
结果是：这是目前生产环境中最快的区块链 RPC 入口层。
Alchemy Edge Proxy 是如何工作的？
Edge Proxy 架构由两个核心组件构成，运行在全球多个区域（美国东部、美国西部、欧洲中部、东南亚等）的专用裸金属服务器上。
Istio Ingress Gateway
第一个组件是运行 Envoy 作为数据平面的 Istio Ingress Gateway。它负责 TLS 终止、连接管理和请求代理。Envoy 正是支撑 Lyft、Google Cloud 和 AWS App Mesh 承载高负载的同一款代理。它的异步非阻塞 C++ 内核、HTTP/2 多路复用以及预热的上游连接池，使其非常适合高吞吐、低延迟的入口场景。
Edge Proxy Control Plane（EPCP）
第二个组件是一个自研的控制平面，以 ext_authz filter 的形式与 Envoy 一起运行。对于每一个进入的请求，EPCP 都会评估：
- 根据 URL、请求头和目标区块链网络，判断请求应路由到哪里
- 该请求有哪些可用的后端集群（例如归档节点集群、AWS 托管服务、特定区域的端点）
- 该请求是否因安全或合规原因需要被拦截
- 本地区域内哪些网络处于健康状态（通过健康检查判断）
随后，EPCP 会注入路由头信息，告知 Envoy 应将请求转发至何处。这一设计使得热路径保持高速（由 Envoy 负责代理转发），同时让路由逻辑保持灵活、可动态配置。
请求生命周期
一个典型的成功请求，其流转过程如下：
- 客户端向
*.g.alchemy.com发送 RPC 请求。 - 基于地理位置的 DNS 将请求解析到最近的 Edge Proxy 区域。
- Istio Ingress Gateway 接收请求，并通过 ext_authz 将其传递给 EPCP。
- EPCP 对请求进行校验（OFAC 检查、安全规则），确定目标集群，并返回路由头信息。
- Istio 将请求转发至相应的后端。
- 响应直接返回给客户端。
基于地理位置的 DNS 路由
Edge Proxy 采用基于地理邻近性的 DNS 解析。这意味着 DNS 层与具体的链和网络无关：一个针对 Ethereum 主网的请求和一个针对 Solana 主网的请求，会解析到同一个区域性的 Edge Proxy。网络层面的路由判断，由 Edge Proxy 内部自行处理。
这一设计具备以下几个优势：
- 无论最终需要访问哪条区块链网络，DNS 解析和 TLS 握手都在最近的边缘节点完成。
- 新增区块链网络无需任何 DNS 变更。
- 区域健康检查在 Edge Proxy 层面进行。一旦某个 Edge Proxy 区域变得不健康，DNS 会自动切换到次近的区域。
动态配置
Edge Proxy 从我们内部的配置平台拉取路由配置，这使得运行时变更无需重新部署即可生效：
regions:
us-east:
enabled: true
routes:
"/v2":
verbs: ["POST"]
destination: archive-cluster
fallbackRegions:
- us-west
- eu-central
- apac-southeast
security:
ipsBanned: ["..."]
pathsBanned: ["..."]无论是需要排空某个区域、为某个网络重新路由，还是需要执行新的安全规则，配置更新都会自动传播，无需改动正在运行的代理。
在没有 CDN 的情况下，安全模型是如何运作的？
移除对 CDN 的依赖，意味着要从零开始重建每一项安全防护。Edge Proxy 用分层方式替代了 CDN 提供的防护：
关键在于：这些防护措施并不比 CDN 提供的弱，而是更具针对性。Alchemy 掌控每一层防护，可以按网络调整阈值，出现问题时也无需受制于第三方的故障处理时限。
Alchemy Edge Proxy 带来了哪些成果？
Edge Proxy 于 2025 年 10 月分三周时间在 100 多个区块链网络上完成推出，客户无需进行任何迁移。效果立竿见影。
延迟
客户端遥测数据显示，在不同负载类型下均出现了类似幅度的改善，其中对延迟最敏感的场景收益最大。
如需查看当前公开的行业数据，可参考跨链、跨区域及常用方法的 RPC 延迟基准测试。
可靠性
在同一时间段内，若仍沿用之前以 CDN 为前端的架构，本应受到上游故障波及，而 Alchemy 的基础设施未受任何影响。
与其他基础设施方案相比如何？
处理区块链 API 基础设施的入口流量，通常有三种常见方案：
自研边缘代理兼具直连的延迟优势和 CDN 的防护能力与流量灵活性，同时不背负两者各自的供应商依赖或成本扩张问题。
已有一些 RPC 提供商推出了不依赖 CDN 的边缘方案，但这些方案通常要求客户在弃用截止日期前迁移到新端点。而 Alchemy Edge Proxy 在无需客户采取任何行动的情况下，就实现了同等甚至更大的性能提升。
在最快的区块链基础设施上构建
Alchemy 的 Edge Proxy 只是这个为全球金融活动需求而打造的平台中的一部分。尾部延迟最高降低 7.5 倍、支持 100 多个网络、跨多个大洲的多区域覆盖、无需任何操作即可享受的性能升级——这些都随 Alchemy 的 RPC 端点开箱即用。
无论你在构建 DeFi 协议、钱包、支付应用，还是面向金融机构的链上基础设施，性能与可靠性都是基本前提。可以查看完整的支持链列表，深入阅读 Alchemy 开发者文档，或创建免费账户开始构建。
Alchemy 新闻通讯
第一时间获取发布信息
订阅我们的新闻通讯
获取 Alchemy 的最新产品更新和资源
填写您的电子邮箱地址即表示您同意接收我们的营销通讯和产品更新。您确认 Alchemy 按照我们的隐私声明处理我们收到的信息。您可以随时取消订阅。
