每天在Vercel上进行的部署量约为1000万次，截至目前已累计完成23.5亿次。Vercel是世界上最繁忙的多租户系统之一。
Each day ~10 million deployments are made on Vercel, with 2.35 billion made to date. Vercel is one of the most heavily multi-tenant systems in the wor...
Guillermo RauchAI2026-09-10
每个请求都通过我们的CDN，平均每秒执行超过8000万条路由指令。其中一部分工作是查找元数据以确定哪些路径存在以及如何提供服务。当这些元数据未缓存时，CDN必须在提供服务之前先获取它。我们过去一次只获取和缓存一条路径的元数据，只检索每个查找所需的内容。当时这似乎很高效，但大型部署可能包含数十万个路径，每个路径都有自己的缓存条目。每次新的部署都会引入新的元数据，使得缓存未命中成为频繁部署的大型网站的持续成本。一次性获取更多元数据使这些查找更快。通过将路径分组，每次获取都可以为后续许多查找填充缓存。但获取过多也引入了自己的成本。通过生产实验，我们找到了一个平衡点，将P99元数据查找延迟降低了91%，并使部署更快。
CDN如何找到正确的路由
请求中的路径并不总是与提供内容或功能的路径相匹配。框架路由规则将它们连接起来。例如，对/blog/hello-world的请求可能解析为动态路由/blog/[slug]。对该页面的React服务器组件负载的请求可能解析为/blog/[slug].rsc。当CDN应用这些规则时，可能需要检查多个目标路径以找到正确的响应。
框架在构建过程中描述这些路由。使用框架定义的基础设施，应用程序代码声明哪些输出是静态的，哪些需要函数，以及哪些响应可以被缓存或重新生成。框架将这种意图转换为构建输出API输出，Vercel生成CDN读取的路由元数据。
在请求时间，CDN需要确定哪些目标路径存在并检索它们的元数据。我们添加到全局路由规则中的布隆过滤器排除了肯定不存在的路径。R
原文
Every request to Vercel passes through our CDN, which executes on average over 80 million routing instructions per second. Part of that work is looking up metadata to determine which paths exist and how to serve them. When that metadata isn’t cached, the CDN has to fetch it before it can serve the response.We used to fetch and cache metadata one path at a time, retrieving only what each lookup needed. That seemed efficient at the time, but large deployments can contain hundreds of thousands of paths, each with its own cache entry. Every new deployment introduced fresh metadata, making cache misses a recurring cost for large sites that deployed frequently.Fetching more metadata at once made these lookups faster. By grouping paths together, each fetch could populate the cache for many subsequent lookups. But fetching too much introduced its own costs. Through production experiments, we found a balance that cut P99 metadata lookup latency by 91% and made deployments faster along the way.Copy link to headingHow the CDN finds the right routeThe path in a request doesn’t always match the path of the content or function that serves it. Framework routing rules connect the two. A request for /blog/hello-world, for example, might resolve to the dynamic route /blog/[slug]. A request for that page’s React Server Component payload might resolve to /blog/[slug].rsc. As the CDN applies these rules, it may need to check several target paths to find the right response.The framework describes those routes during a build. With framework-defined infrastructure, application code declares which outputs are static, which need Functions, and which responses can be cached or regenerated. Frameworks translate that intent into Build Output API outputs, and Vercel generates the routing metadata the CDN reads.At request time, the CDN needs to determine which target paths exist and retrieve their metadata. The Bloom filters we added to global routing rule out paths that definitely don’t exist. Remaining paths need an exact metadata lookup.Originally, we stored that metadata as a separate object per target path. The CDN fetched and cached each object independently. This worked well for smaller projects that deployed infrequently. But every new deployment created a fresh set of cache keys, so the first lookup for each path missed the cache.Copy link to headingFetching metadata in groupsTo reduce cache misses, we grouped metadata for many paths into files called shards. We bounded each shard’s size to control how much data a lookup had to fetch. Fetching a shard brought metadata for all of its paths into the cache, so later lookups for those paths could reuse it.A per-path cache fill warms one path. A shard fill warms every path assigned to that shard.Each shard also included an index that let the CDN locate an individual path’s metadata without decoding, decompressing, or parsing the other entries. Each fetch warmed many paths, while each lookup still parsed only the record it