Cortex 路由器：如何为每个请求选择最快的健康节点

你的应用发出的每一次 RPC 调用，都必须先到达某个节点，再返回结果，用户才能看到任何东西。把调用送到附近的区域，这是每一家认真做这件事的服务商都会自动完成的工作，我们也不例外，我们也在不断开设新区域，以进一步缩短这第一跳的距离。更值得关注的问题是请求到达之后发生了什么：具体是该区域内的哪个节点来响应，以及在请求被送过去之前，是否有任何机制检查过这个节点是否健康、是否已经追上链的最新状态。

这第二个判断，是我们在每一次请求时都重新做出的决定，也是我们在 EVM 链上的平均响应时间低于 15ms 的主要原因之一。这个数字是热请求-响应时间，测量对象是一个已经建立好的连接，这也正是运行中的应用在处理重复流量时的典型情况。它不包含 DNS、连接建立和 TLS 握手，所以下面提到的边缘层工作是在这个数字之外，而不是之内。

Cortex 路由器到底在决定什么？

Cortex 是驱动整个 Alchemy 平台的引擎，从节点集群一直到路由层，再到上层的 RPC 和 Data API，都由它支撑。此前的架构是在流量前面放置第三方 CDN，这使得该 CDN 成为所有网络、所有客户共用的单点故障。用我们自己运营的裸金属取代它之后，消除了这个依赖，把整条路径都置于我们自己的运维之下。现在你发出的每一个请求都要经过 Cortex，而路由器正是负责决定这个请求去向何处的部分。

对每一个请求，路由器都要决定路径：哪个区域接收它、哪个节点为它服务，以及如果该节点在处理过程中出现异常该怎么办。所谓“到你的链的最佳路径”，实际含义是：在此时此刻，能够正确回答这一具体调用的、延迟最低的健康节点。这个答案会随着负载和健康状况的变化而逐秒改变，这也是我们按每个请求重新计算，而不是解析一次就复用结果的原因。

区域这部分的选择，如今已是业界的标准做法。来自新加坡的请求和来自法兰克福的请求，在任何一家主流服务商那里都会从不同的入口进入，也都不需要你手动配置。我们额外提供的是第二个判断，是按每个请求而不是按每条连接做出的：在请求落地的区域内可用的节点中，哪一个是健康的、数据是最新的，并且适合这一具体调用。

请求是如何到达正确区域的？

基于地理位置的 DNS 会把端点解析到最近的边缘区域，这样请求就能就近进入系统，而不是所有流量都涌向同一个地方。这个过程发生在路由器查看任何一个节点之前，因为到入口的距离是一种你永远无法挽回的纯粹往返时间。连接建立和 TLS 协商也发生在这里，也就是在最近的接入点，而不是在更深的链路中。

这个入口就是我们自己的 Alchemy Edge Proxy，一个裸金属的接入层，用来替代第三方 CDN。推出它是本次重建中延迟收益最大的举措之一。亚太地区的 P99 从 150ms 降到 20ms，全网络的 P95 大致减半，从约 200ms 降到约 100ms。这些数字反映的是这次迁移前后的对比，而不是当前的实际水平；P95 和 P99 分别是最慢的 5% 和 1% 的请求，也正是用户能实际感受到的部分。边缘层只是我们在延迟方面整体投入的一环，这项投入从预测性扩容一直延伸到集群自动化。

我们是如何在一个区域内选出节点的？

这里有两层各自负责不同的工作。在边缘，控制面会查看哪些服务集群支持你请求的网络、其中哪些是健康的，然后把请求发送到最近的那个。但选择具体节点这一步发生在更深的一层，在集群前面的网关中。这个网关是链路中第一个了解具体机器情况的环节。

要选好一个节点，仅仅选一个近的是不够的，因此在请求被转发出去之前，还有若干因素会进一步筛选候选节点。

• 健康状态，来自实时监控。 一个节点追踪系统会持续进行健康检查，未通过检查的节点不会成为候选。这样可以在一开始就避免选中状态异常的后端，而不是等用户发现问题。
• 对当前状态的一致性。 各节点所处的区块高度并不相同，如果把读请求交给响应最快的那个节点，可能会返回链已经越过的旧状态。一个一致性层确保无论由哪个节点提供服务，请求看到的都是同一个规范化的链视图，而带版本号的更新意味着即使在故障切换过程中，也不会读到过期数据。
• 实测延迟，而不仅仅是地理位置。 候选节点会根据其近期实测延迟的指数加权移动平均值打分，这与负载均衡器多年来一直采用的方法相同。由于较旧的样本会逐渐从平均值中衰减出去，一个几分钟前才开始变慢的节点，排名会自然下降，无需任何人发出告警。
• 工作负载的形态。 不同的节点客户端在同步行为、以及擅长处理的方法上各有差异，而归档节点和全节点持有的数据也不同，因此请求中的方法和参数会进一步收窄候选池。一个繁重的历史查询和一个简单的余额读取，不应该落在同一个节点上。

所以“最低延迟”从来不是我们在某处一次性打开的一个开关。它是针对每一次调用重新计算出来的结果，取决于这次调用从哪里进来、它在请求什么，以及此刻恰好哪些机器又快又健康。

当选中的节点不健康时会发生什么？

故障切换是路由决策的一部分，而不是事后挂上去的报警机制。当某个节点宕机时，Cortex 会自动将流量重新路由到健康的节点。更值得关注的情形是那些并未彻底宕机、但处于拥塞、延迟滞后或运行着已知有缺陷的客户端版本的节点，同样的上下文感知路由也会绕开这些节点。你的应用不会看到错误，这里也没有需要你自己编写的重试逻辑。

同样的逻辑也适用于更高的层级。如果整个区域出现异常，请求会路由到备用区域，而备用区域之后还有进一步的后备方案。实时的全球数据复制在这些切换过程中保持各区域数据的一致，所以最终落到更远的区域，并不意味着读到的是更旧的数据。

分片乱序（shuffle sharding）和冗余节点池支撑着这一切的底层，让故障保持隔离和可控，而不是让一个问题扩散到整个集群。路由层把一个状态异常的节点视为应当避开的路径，这也正是支撑我们零停机 Solana gRPC 流式传输、以及在加密行业最大规模清算事件中持续保持运行的同一套容错机制。

为什么自建边缘层能让路由更智能？

RPC 流量大多是动态的。一次 eth_call 或一笔交易提交，都无法像静态图片那样被缓存，因此通用 CDN 的主要手段——就近向用户提供缓存内容——大多并不适用，请求仍然必须到达一个实时节点。自建边缘层而不是租用 CDN，使我们能够针对这种特定的流量形态进行调优，也让路由能够使用第三方层永远看不到的信号，比如此刻哪个节点已同步、健康，并且对这个方法和这条链来说是最快的。

这也意味着我们不与无关的流量共用这一层。在共享的 CDN 上，一个与你的应用完全无关的事故，仍可能表现为你这边的延迟飙升，而修复进度取决于别人的排期。

服务商之间真正产生分化的地方，在于区域以下的一切，因为那正是路由层要么真正了解每台机器在做什么、要么只能靠猜测的地方。

我们之所以自己运营这一切，是因为这是唯一能确保路径上没有任何一段属于别人的方式。为此我们付出了真实的工程成本，而作为交换，我们可以调优整条路径，而不必去给拥有那个慢环节的人提交工单。

这对像 Base 这样的链意味着什么？

Base 是一个很好的压力测试对象，因为这条链本身就很快。它通过 Flashblocks 实现 200ms 的增量区块更新，因此一条 RPC 路径如果响应时间超过这个数字，瓶颈就变成了 RPC 而不是链本身。来自任何区域的 Base 调用都会进入最近的边缘节点，被匹配到一个健康且与链保持同步的 Base 节点，并且如果该节点状态恶化，会在区域内重新路由。当链每 200ms 就预览一次新状态时，去掉一百毫秒的网络开销，其重要性只会更高，而不是更低。

一致性是更难保证的部分，也是真正值得用来评判我们的部分。Polymarket 就是压力测试案例。在 2024 年美国大选期间，他们同时承载了超过 125,000 名并发用户，下注金额高达 33 亿美元，请求会根据 p99 延迟动态重新路由，以维持性能。他们的关键数据摄取流程也单独实现了 2.5 倍提速，从约 250ms 降到约 100ms。某个安静的下午在单一区域测得的中位数，几乎说明不了你的用户在铸造高峰或清算连锁反应中的实际体验。如果你更愿意自己验证而不是听我们说，我们的基准测试方法会同时衡量延迟、成功率和失败请求数，而服务商基准测试结果是公开的。

在同一条路由路径上构建

Alchemy 上的每一个应用已经在经由这套引擎路由，无需任何配置。开通一个免费的 RPC 端点，你的读写请求就会走本文所述的相同的按请求路径。无需签约，无需排队等待，无需更换端点。你的 Data API 调用同样运行在这套体系之上。

如果你需要一个固定在某个区域的节点、单租户隔离，或者路径上的自定义二进制版本，Alchemy Dedicated Clusters 在单租户硬件上运行同一套路由，你也可以选择在流量超出集群容量时自动故障切换到共享集群。无论哪种方式，应用背后的请求处理都会变成一件你不再需要操心的事。

常见问题

哪家 RPC 服务商在全球各区域提供最低延迟？

Alchemy 在 EVM 链上的平均响应时间，根据我们持续更新的基准测试，低于 15ms，测量方式是在已建立连接上的热请求-响应时间。该页面每隔几分钟就会重新计算一次，建议以页面上的当前服务商排名为准。正常运行时间为 99.995%。任何一家认真做事的服务商都会把你路由到附近的区域。Cortex 在此基础上更进一步，在区域内部把每个请求匹配到经过健康检查、并与链的当前状态保持一致的节点上。

哪家 RPC 服务商对 Base RPC 提供最低延迟支持？

Alchemy 上的 Base RPC 会进入最近的边缘区域，然后被匹配到一个健康且与链保持同步的 Base 节点。这一点在 Base 上比在较慢的链上更为重要，因为 Flashblocks 每 200ms 就推送一次区块更新，即使只是略微落后的节点，也可能返回已经过期的状态。

Cortex 是如何选择由哪个节点来处理 RPC 请求的？

这项工作由两层共同完成。边缘控制面会选出支持所请求网络的、最近的健康服务集群，然后由集群前面的网关来选择具体节点，依据健康状态、与链当前状态的一致性、近期实测延迟以及所调用的方法，逐步缩小候选范围。

按请求路由是否会增加延迟？

路由只占响应预算中很小的一部分，而不是决定整体表现的关键数字。低于 15ms 这一数字，是 EVM 链上的热请求-响应时间，并非路由决策本身所耗费的时间，也不同于覆盖所有链和所有产品的、平台层面低于 50ms 的平均值这一统计口径。区域选择发生在边缘、靠近用户的地方，而节点选择则发生在更深处，也就是集群前面的网关中。

RPC 节点出现故障时会发生什么？

故障切换是路由决策的一部分，而不是你需要自己搭建的重试逻辑。当某个节点宕机时，Cortex 会自动将流量重新路由到健康的节点，其上下文感知路由同样会绕开那些拥塞、延迟滞后或运行有缺陷客户端的节点。如果整个区域状态恶化，请求会转移到备用区域，同时实时数据复制会保持数据的一致性。