文章摘要MCP在Java和Spring AI项目中常见三种部署方式STDIO适合本地进程工具Streamable HTTP适合需要会话和双向能力的远程服务Stateless HTTP则适合请求—响应型工具和云原生水平扩容。三种方式在网络边界、状态管理、Sampling、Elicitation、负载均衡、鉴权和故障恢复方面存在明显差异。本文给出生产选型方法和迁移建议。一、三种方式解决的不是同一个问题STDIO客户端启动本地子进程 → 通过标准输入输出交换JSON-RPCStreamable HTTP客户端通过HTTP连接远程MCP Server → 协议可能维护逻辑会话 → 支持更完整的双向交互Stateless HTTP每次HTTP请求相互独立 → 不维护协议级会话 → 任意实例都可以处理选择传输方式不能只看“哪个更新”而要看业务交互模型。二、STDIO适合什么场景适合桌面AI客户端本地文件工具本地Git工具本地数据库开发环境CLI单机插件不希望开放网络端口。配置通常需要command args environment working_directory示意{command:java,args:[-jar,local-tools.jar]}优点网络攻击面小部署简单凭证可留在本机与桌面客户端生命周期一致调试方便。缺点每个客户端都要部署一份升级困难难以统一审计不适合共享企业服务子进程崩溃会中断工具资源占用随客户端增加。三、Streamable HTTP适合什么场景适合远程共享MCP Server需要Sampling需要Elicitation服务端需要向客户端发送请求或通知复杂Agent交互会话中持续报告进度长时间连接。Spring AI服务端spring:ai:mcp:server:protocol:STREAMABLE优点远程集中部署支持更丰富的双向能力适合复杂Agent便于统一安全与审计可以共享后端资源。缺点需要管理逻辑会话负载均衡更复杂连接和超时配置更复杂滚动升级需要考虑会话网关可能缓冲流式响应断线恢复设计更复杂。四、Stateless HTTP适合什么场景Spring AIspring:ai:mcp:server:protocol:STATELESS适合查询订单查询库存获取客户信息检索知识库计算报价生成短报告高并发只读工具云原生微服务。优点普通Round-Robin负载均衡不需要Sticky Session实例可快速扩缩容器故障恢复简单更适合Serverless网关和监控更标准。限制无状态服务端通常不支持需要服务端主动回调客户端的能力例如SamplingElicitation部分双向通知连接级交互。业务状态仍需保存到数据库Redis工作流引擎任务服务。五、三种方式对比维度STDIOStreamable HTTPStateless HTTP典型部署本地进程远程服务云原生远程服务协议会话进程连接通常存在不存在水平扩容不适用较复杂最简单双向能力可用最完整受限Sampling可支持可支持通常不支持Elicitation可支持可支持通常不支持网络暴露无远程端口有有统一审计较难容易容易客户端安装需要不需要不需要适合高并发查询一般可以最适合六、不要把业务状态与协议状态混淆订单审批工具即使使用Stateless HTTP业务仍然有状态DRAFT → PENDING_APPROVAL → APPROVED → EXECUTED这些状态应该由业务系统保存。错误privatefinalMapString,ApprovalStatestatesnewConcurrentHashMap();容器重启后全部丢失。正确MCP Server无状态 审批状态进入数据库七、Sampling与Elicitation决定传输选择SamplingMCP Server请求客户端调用模型。例如工具读取复杂数据 → 请求客户端模型总结 → 服务端继续处理Elicitation服务端请求用户补充结构化信息。例如退款工具发现缺少退款原因 → 请求客户端向用户提问 → 用户填写 → 工具继续如果业务强依赖这两种能力不应优先选择Stateless。八、企业远程服务为什么通常不选STDIO企业工具需要统一版本统一权限统一审计数据库连接池高可用灰度发布限流服务发现。如果每个客户端本地启动一个MCP Server工具版本不一致 凭证散落 日志分散 权限难以撤销 升级依赖用户因此订单、客户、仓储、财务类工具更适合远程服务。九、什么时候选择WebMVC什么时候选择WebFluxWebMVC适合阻塞式业务系统JDBC普通请求—响应团队熟悉Servlet工具并发中等。WebFlux适合大量并发连接流式响应异步I/OReactive数据源多个远程调用组合。不能只因为MCP支持流式就强制使用WebFlux。如果底层全部是阻塞JDBC和同步SDK错误使用WebFlux可能造成Event Loop阻塞。十、网关层需要注意什么远程HTTP方式需要配置请求体大小流式缓冲连接超时读取超时请求头转发OAuth TokenCORSWAF规则负载均衡Trace ID。Stateless方式可以按请求路由。Streamable方式还需要考虑长连接会话亲和断线重连连接排空滚动发布。十一、安全差异STDIO风险本地命令注入环境变量泄露文件权限恶意子进程自动启动不可信程序。HTTP风险未授权访问Token泄露重放跨租户网关绕过SSRF公网暴露。远程服务至少需要TLS OAuth 2.0或API Key 最小Scope 租户校验 工具级权限 审计十二、成本与运维STDIO成本分散到客户端机器服务端基础设施少但维护成本高。Streamable HTTP需要连接管理、会话管理和更复杂的容量规划。Stateless HTTP最接近普通微服务容易使用现有Kubernetes、网关和APM体系。十三、选型决策树工具只在本机使用 → STDIO 需要远程共享 → HTTP 服务端必须主动向客户端请求Sampling或Elicitation → Streamable HTTP 主要是独立请求—响应并要求简单扩容 → Stateless HTTP十四、推荐组合一个企业可以同时使用三种方式本地代码与文件工具 → STDIO 复杂交互与长会话Agent → Streamable HTTP 订单、库存、客户、知识查询 → Stateless HTTPMCP的价值就是使用统一协议连接不同部署形态而不是强迫所有工具使用同一传输。十五、迁移建议从SSE旧传输迁移确认客户端支持Streamable HTTP → 建立新入口 → 双入口运行 → 测试工具发现和调用 → 灰度切换 → 下线SSE从有状态迁移无状态盘点进程内状态 → 状态外置 → 移除会话依赖 → 测试任意实例处理 → 关闭Sticky Session总结三种MCP传输的核心定位是STDIO → 本地、进程级、低网络暴露 Streamable HTTP → 远程、会话型、双向能力 Stateless HTTP → 远程、无状态、云原生扩容正确选型应从业务交互和部署要求出发而不是简单选择最新的协议模式。
文章摘要MCP在Java和Spring AI项目中常见三种部署方式STDIO适合本地进程工具Streamable HTTP适合需要会话和双向能力的远程服务Stateless HTTP则适合请求—响应型工具和云原生水平扩容。三种方式在网络边界、状态管理、Sampling、Elicitation、负载均衡、鉴权和故障恢复方面存在明显差异。本文给出生产选型方法和迁移建议。一、三种方式解决的不是同一个问题STDIO客户端启动本地子进程 → 通过标准输入输出交换JSON-RPCStreamable HTTP客户端通过HTTP连接远程MCP Server → 协议可能维护逻辑会话 → 支持更完整的双向交互Stateless HTTP每次HTTP请求相互独立 → 不维护协议级会话 → 任意实例都可以处理选择传输方式不能只看“哪个更新”而要看业务交互模型。二、STDIO适合什么场景适合桌面AI客户端本地文件工具本地Git工具本地数据库开发环境CLI单机插件不希望开放网络端口。配置通常需要command args environment working_directory示意{command:java,args:[-jar,local-tools.jar]}优点网络攻击面小部署简单凭证可留在本机与桌面客户端生命周期一致调试方便。缺点每个客户端都要部署一份升级困难难以统一审计不适合共享企业服务子进程崩溃会中断工具资源占用随客户端增加。三、Streamable HTTP适合什么场景适合远程共享MCP Server需要Sampling需要Elicitation服务端需要向客户端发送请求或通知复杂Agent交互会话中持续报告进度长时间连接。Spring AI服务端spring:ai:mcp:server:protocol:STREAMABLE优点远程集中部署支持更丰富的双向能力适合复杂Agent便于统一安全与审计可以共享后端资源。缺点需要管理逻辑会话负载均衡更复杂连接和超时配置更复杂滚动升级需要考虑会话网关可能缓冲流式响应断线恢复设计更复杂。四、Stateless HTTP适合什么场景Spring AIspring:ai:mcp:server:protocol:STATELESS适合查询订单查询库存获取客户信息检索知识库计算报价生成短报告高并发只读工具云原生微服务。优点普通Round-Robin负载均衡不需要Sticky Session实例可快速扩缩容器故障恢复简单更适合Serverless网关和监控更标准。限制无状态服务端通常不支持需要服务端主动回调客户端的能力例如SamplingElicitation部分双向通知连接级交互。业务状态仍需保存到数据库Redis工作流引擎任务服务。五、三种方式对比维度STDIOStreamable HTTPStateless HTTP典型部署本地进程远程服务云原生远程服务协议会话进程连接通常存在不存在水平扩容不适用较复杂最简单双向能力可用最完整受限Sampling可支持可支持通常不支持Elicitation可支持可支持通常不支持网络暴露无远程端口有有统一审计较难容易容易客户端安装需要不需要不需要适合高并发查询一般可以最适合六、不要把业务状态与协议状态混淆订单审批工具即使使用Stateless HTTP业务仍然有状态DRAFT → PENDING_APPROVAL → APPROVED → EXECUTED这些状态应该由业务系统保存。错误privatefinalMapString,ApprovalStatestatesnewConcurrentHashMap();容器重启后全部丢失。正确MCP Server无状态 审批状态进入数据库七、Sampling与Elicitation决定传输选择SamplingMCP Server请求客户端调用模型。例如工具读取复杂数据 → 请求客户端模型总结 → 服务端继续处理Elicitation服务端请求用户补充结构化信息。例如退款工具发现缺少退款原因 → 请求客户端向用户提问 → 用户填写 → 工具继续如果业务强依赖这两种能力不应优先选择Stateless。八、企业远程服务为什么通常不选STDIO企业工具需要统一版本统一权限统一审计数据库连接池高可用灰度发布限流服务发现。如果每个客户端本地启动一个MCP Server工具版本不一致 凭证散落 日志分散 权限难以撤销 升级依赖用户因此订单、客户、仓储、财务类工具更适合远程服务。九、什么时候选择WebMVC什么时候选择WebFluxWebMVC适合阻塞式业务系统JDBC普通请求—响应团队熟悉Servlet工具并发中等。WebFlux适合大量并发连接流式响应异步I/OReactive数据源多个远程调用组合。不能只因为MCP支持流式就强制使用WebFlux。如果底层全部是阻塞JDBC和同步SDK错误使用WebFlux可能造成Event Loop阻塞。十、网关层需要注意什么远程HTTP方式需要配置请求体大小流式缓冲连接超时读取超时请求头转发OAuth TokenCORSWAF规则负载均衡Trace ID。Stateless方式可以按请求路由。Streamable方式还需要考虑长连接会话亲和断线重连连接排空滚动发布。十一、安全差异STDIO风险本地命令注入环境变量泄露文件权限恶意子进程自动启动不可信程序。HTTP风险未授权访问Token泄露重放跨租户网关绕过SSRF公网暴露。远程服务至少需要TLS OAuth 2.0或API Key 最小Scope 租户校验 工具级权限 审计十二、成本与运维STDIO成本分散到客户端机器服务端基础设施少但维护成本高。Streamable HTTP需要连接管理、会话管理和更复杂的容量规划。Stateless HTTP最接近普通微服务容易使用现有Kubernetes、网关和APM体系。十三、选型决策树工具只在本机使用 → STDIO 需要远程共享 → HTTP 服务端必须主动向客户端请求Sampling或Elicitation → Streamable HTTP 主要是独立请求—响应并要求简单扩容 → Stateless HTTP十四、推荐组合一个企业可以同时使用三种方式本地代码与文件工具 → STDIO 复杂交互与长会话Agent → Streamable HTTP 订单、库存、客户、知识查询 → Stateless HTTPMCP的价值就是使用统一协议连接不同部署形态而不是强迫所有工具使用同一传输。十五、迁移建议从SSE旧传输迁移确认客户端支持Streamable HTTP → 建立新入口 → 双入口运行 → 测试工具发现和调用 → 灰度切换 → 下线SSE从有状态迁移无状态盘点进程内状态 → 状态外置 → 移除会话依赖 → 测试任意实例处理 → 关闭Sticky Session总结三种MCP传输的核心定位是STDIO → 本地、进程级、低网络暴露 Streamable HTTP → 远程、会话型、双向能力 Stateless HTTP → 远程、无状态、云原生扩容正确选型应从业务交互和部署要求出发而不是简单选择最新的协议模式。
