#Serverless

为什么 MCP 服务器难以部署在 Serverless 架构上？

随着大模型生态的发展，MCP（Model Context Protocol，模型上下文协议）成为了连接 AI 助手与外部工具的热门选择。然而，在实际部署中，开发者很快就会遇到一个棘手的架构问题：MCP 服务器默认是有状态的（Stateful）。

1. 单客户端的尴尬限制

在最基础的 HTTP/SSE（Server-Sent Events）实现中，服务器通常会将连接通道（Transport）保存在内存变量中。这意味着，一旦有第二个客户端尝试连接，前一个客户端的连接就会被迫中断。

2. 内存常驻与 Serverless 的冲突

即便我们通过引入 ID 标识来管理多个连接，依然无法解决核心问题——连接状态依然保存在服务器的内存中。

这种“有状态”的特性，直接把 Serverless 部署方案（如 Vercel、AWS Lambda）排除在外。因为 Serverless 函数在请求结束后会随时销毁实例，导致内存中的连接状态丢失。要维持连接，你只能选择 VPS 等需要持续运行的服务器，这增加了运维成本。

3. 如何实现无状态化？

目前最可行的解决方案是将状态外置。我们可以将 Transport 信息存储到像 Redis 这样的键值数据库中。

通过将状态抽离到 Redis，MCP 服务器成功实现了无状态化（Stateless），从而能够自由地部署到 Vercel 等 Serverless 平台上。Vercel 官方开源的 mcp-on-vercel 项目正是采用了这种架构设计。

思考

虽然通过 Redis 解决了部署问题，但这无疑增加了系统的复杂度。我们不禁会想：在协议设计之初，是否应该让客户端去承担更多的状态维护，从而避免让服务端背上数据库的包袱？

---

原文链接：https://www.aihero.dev/the-problem-with-mcp-stateful-server

#MCP #Serverless #系统架构 #Redis #AI开发

www.aihero.dev

The Problem With MCP: Stateful Servers

Discover how to deploy MCP servers statelessly using Redis, enabling compatibility with serverless platforms like Vercel and AWS Lambda.

让 Cloudflare Workers 拥有专属缓存：更低的延迟与零 CPU 开销

Cloudflare 宣布推出 Workers Cache。以往，Worker 总是运行在缓存的前面；而现在，Cloudflare 的多级缓存（Tiered Cache）可以直接放置在你的 Worker 前面。

当请求命中缓存时，你的 Worker 代码根本不会执行。这不仅能让页面加载体验如静态网页般飞快，还能将这部分请求的 CPU 计费直接降为零。

核心特性

• 极简配置：只需在 Wrangler 配置文件中开启一行配置，即可通过标准的 HTTP 响应头（如 Cache-Control 和 Vary）直接控制缓存。
• 丝滑的异步更新：原生支持 stale-while-revalidate。当缓存过期时，系统会先将旧页面立即返回给用户，并在后台异步运行 Worker 更新缓存，让用户实现“零等待”。
• 属于 Worker 自己的缓存：它摆脱了传统域名（Zone）的规则限制，缓存直接跟随 Worker 移动。无论是在自定义域名、workers.dev 还是预览 URL 中，都能无缝工作。
• 多租户安全（ctx.props）：可以将用户 ID 或租户 ID 编入缓存键，从而在边缘安全地为不同登录用户缓存个性化的 API 响应。
• 应用内微服务级组合：缓存不仅能挡在最外层，还可以塞入同一个 Worker 的不同入口点（Entrypoints）之间，让你的架构设计更加灵活。

目前，Astro 框架已经率先提供原生集成支持。所有方案（包括免费版）的 Worker 即日起均可启用该功能。

https://blog.cloudflare.com/workers-cache/

#Cloudflare #Serverless #Web开发 #缓存技术 #CloudflareWorkers

The Cloudflare Blog