--- title: "深入 Cortex：实现 50 毫秒以下延迟、99.995% 可用性的工程实践" description: "可靠的区块链连接是不可或缺的。Cortex 通过专门设计的架构——从裸金属硬件到 AI 管理的节点集群——在规模化场景下实现 50 毫秒以下的响应时间和 99.995% 的可用性。" --- # 深入 Cortex：实现 50 毫秒以下延迟、99.995% 可用性的工程实践 可靠的区块链连接是不可或缺的。[Cortex](https://www.alchemy.com/cortex) 是为 Alchemy 平台提供支持的智能区块链引擎：[RPC APIs](https://www.alchemy.com/docs/reference/node-api-overview)、[data APIs](https://www.alchemy.com/docs/reference/data-overview)、[rollups](https://www.alchemy.com/docs/reference/rollups-quickstart)，以及开发者平台其余部分背后的基础设施。 它是从第一性原理构建的，基于数万亿次请求和超过七年的数据训练而成，目标只有一个：提供在任何规模下都能可靠运行的基础设施。 结果是平均响应时间低于 50 毫秒，正常运行时间达到 99.995%，并且吞吐量可扩展至数千万用户，而无需迁移、更换新工具或在你这一端进行任何配置调整。 关于跨供应商的公开对比，可参阅 Alchemy 的 [RPC 性能基准测试](https://www.alchemy.com/benchmarks)，其中涵盖延迟、成功率和失败请求数据。 本文深入探讨了 Cortex 背后的工程决策：在延迟、吞吐量和可靠性方面所做的系统级工作，正是这些工作使上述数据成为可能。 ## Cortex 如何降低延迟？ ### 通过 Kubernetes affinity 实现 Pod 协同定位 当你的应用发送请求时，该请求会在得到响应之前经过多个内部服务。每次从一台服务器转移到另一台服务器，都会付出延迟代价。 Pod 协同定位是指将通信最频繁的服务部署在同一台物理机器上。Kubernetes 支持 affinity 规则来实现这一点，使对延迟敏感的工作负载能够一起运行，而不是分散在不同的机器或机架上。 结果是：请求保持在本地处理，减少了网络跳转，缩短了响应时间。 ### Istio 的位置感知路由 即使在单个数据中心内，服务也会分布在不同的节点和机架上。Istio 是管理内部服务之间通信的网络层。 通过位置感知路由，Istio 能够识别每个服务实例的物理位置，并尽可能将流量路由到最近的可用实例。如果处理你的请求的服务正运行在同一节点上，流量就会留在本地，而不是跨网络转发到更远的实例。 这样可以减少不必要的网络跳转，且无需对应用代码做任何改动。 ### 微内核代理架构 随着基础设施复杂度的增加，紧耦合的系统会变得更难安全地进行变更。更新一个组件可能会给整个技术栈带来风险。 微内核方法保持核心部分小而稳定，只负责关键路径。其他一切，包括日志记录、速率限制、身份认证和路由逻辑，都作为叠加在核心之上的模块化组件实现。 我们的代理层位于传入请求和后端系统之间。由于它基于微内核模型构建，各个模块可以独立更新和部署，而不会影响核心请求路径。这使得快速迭代变得更容易，同时降低了引入回归问题的风险。 ### 直连数据中心路由 对于企业级工作负载，通过公共互联网路由流量会带来不稳定性：延迟不一致、丢包，以及会随着不受你控制的因素而变化的拥塞路径。 直连数据中心路由通过将企业流量发送至直接连接到我们基础设施的私有优化网络路径来避免这些问题。这消除了共享公共路由带来的不可预测性，在每一跳都能提供更稳定的低延迟性能。 ## Cortex 如何实现扩展？ ### 全球部署的数千台裸机服务器 大多数云基础设施运行在虚拟机上。虚拟化很灵活，但由于 CPU、内存带宽和 I/O 需要与同一主机上的其他工作负载共享，这会带来额外开销。 裸机是指直接运行在物理硬件上，中间没有 hypervisor。每一份资源都专门用于处理你的请求。这消除了共享环境带来的性能波动，使 Cortex 在高负载下也能保持稳定的吞吐量。 ### Java Virtual Threads 处理大量并发请求会给服务器的线程模型带来压力。传统的操作系统级线程消耗大量内存，随着并发量上升，管理上下文切换的成本也会随之增加。 Java 21 引入的 Java Virtual Threads 是由 JVM 而非操作系统管理的轻量级线程。创建和切换这些线程的开销远低于传统线程，使单台机器能够处理更多的并发任务，而不会产生通常会限制吞吐量的内存和 CPU 开销。 在实践中，这意味着能更高效地利用现有硬件，并有更大的余量来应对流量高峰而不影响性能。 ### 预测式扩缩容逻辑 标准的自动扩缩容会监控某个阈值（例如 CPU 使用率），并在该阈值被突破后才增加容量。这使其在设计上是被动响应式的：需求先上升，基础设施随后才跟上。 我们的扩缩容逻辑同时监控多个信号，包括 CPU、内存、磁盘 I/O 和流量模式，然后利用历史数据在流量高峰发生之前进行预测。容量会在需求出现之前而非之后就被配置好，从而缩小了流量增长与基础设施承载能力之间的差距。 ### AI 管理的节点集群 我们的节点集群由一个全自动的 agentic 系统管理，该系统负责处理升级、测试和监控。更新会被实时检测并应用，测试流程中内置了自动化测试，因此强制性的网络升级和硬分叉不会被遗漏。 这提高了正常运行时间，并在关键链事件发生时消除了人为延误的风险。 ## 为什么这些系统能够产生叠加效应？ 这些并不是孤立的优化措施。Pod 协同定位降低了延迟。位置感知路由进一步降低了延迟。微内核架构使得在不引入不稳定性的情况下同时改进这两者成为可能。裸机硬件为 Java Virtual Threads 提供了高效运行所需的资源。预测式扩缩容确保容量在需要之前就已就绪。 每一层的设计都是为了让其上层运行得更快、更具韧性。这正是从第一性原理重新思考基础设施的含义，而这正是 Cortex 的构建基础。 这一切都在幕后运行。你这一端无需迁移、无需新工具，也无需任何配置。我们持续构建基础设施，让你能够持续构建你的产品。 [立即开始构建](https://dashboard.alchemy.com/)，或[联系销售团队](https://www.alchemy.com/contact-sales)了解定制化定价、集成问题等更多信息。 ## 常见问题 ### 什么是 Alchemy Cortex？ Cortex 是为 Alchemy 开发者平台提供支持的智能区块链引擎，涵盖 RPC APIs、data APIs、rollups 和基础设施。它是从第一性原理构建的，基于数万亿次请求和超过七年的数据训练而成，可实现低于 50 毫秒的响应时间、99.995% 的正常运行时间，以及无需迁移或配置调整即可扩展的吞吐量。 ### Cortex 如何实现低于 50 毫秒的响应时间？ Cortex 使用基于 Kubernetes affinity 的 Pod 协同定位，将频繁通信的服务部署在同一台物理机器上；使用 Istio 位置感知路由将流量引导至最近的服务实例；采用微内核代理架构以保证核心性能稳定；并对企业流量采用直连数据中心路由，通过私有网络传输。 ### Cortex 的微内核代理架构是什么？ 微内核方法使核心请求处理系统保持小而稳定，而日志记录、速率限制、身份认证和路由逻辑则作为模块化组件实现，可以独立更新，而不会影响关键路径或给整个技术栈带来风险。 ### Cortex 在扩缩容方面有何不同？ Cortex 使用预测式扩缩容逻辑，同时监控包括 CPU、内存、磁盘 I/O 和流量模式在内的多个信号，并利用历史数据在需求高峰出现之前配置容量，而不是在阈值被突破之后才做出反应。 ### 为什么 Cortex 使用裸机服务器而非虚拟机？ 裸机服务器直接运行在物理硬件上，没有 hypervisor，所有资源都专门用于处理请求，消除了共享虚拟化环境带来的性能波动和开销，从而在高负载下提供稳定的吞吐量。 ### 什么是 Java Virtual Threads，Cortex 为何使用它们？ Java Virtual Threads 是由 JVM 而非操作系统管理的轻量级线程，其创建和上下文切换成本远低于传统线程，使单台机器能够处理更多并发任务，而不会产生通常会限制吞吐量的内存和 CPU 开销。 ### Cortex 如何管理区块链节点升级？ Cortex 使用一个全自动的 agentic 系统实时处理升级、测试和监控，测试流程中内置了自动化测试，因此强制性的网络升级和硬分叉不会被遗漏，从而提高正常运行时间并消除人为延误的风险。 ### 使用 Cortex 是否需要迁移或进行任何配置？ 不需要。你这一端无需迁移、无需新工具，也无需任何配置，Cortex 在幕后运行，在你持续构建产品的同时自动带来基础设施层面的改进。