MCP 的部署模式从本地进程到远程服务差异巨大，选择合适的部署方式是系统可靠性和安全性的基础。

一、基本定义

MCP 部署涉及如何将 Server 运行起来并持续提供服务。核心挑战：

• 本地 Server 需要进程管理和自动启动
• 远程 Server 需要网络、认证和扩缩容
• 所有 Server 都需要配置管理、监控和更新策略

二、部署模式

本地进程部署（stdio）

最常见的模式，适用于桌面客户端和个人工具。

特点：
- Client 启动时自动创建 Server 进程
- 通过 stdin/stdout 通信
- 生命周期绑定到 Client
- 无需网络配置

适用场景：

• Claude Desktop + 本地 Server
• Cursor + 文件系统 Server
• 个人开发环境

管理要点：

• 进程守护（Client 负责重启）
• 日志输出到 stderr（不干扰协议通信）
• 配置文件指定启动命令和参数

容器部署（Docker）

适用于团队共享和生产环境。

特点：
- 隔离的运行环境
- 可复现的部署
- 资源限制
- 便于版本管理

Dockerfile 要点：

• 最小基础镜像
• 非 root 用户运行
• 只读文件系统（如果可能）
• 健康检查
• Secret 通过环境变量注入

远程服务部署（HTTP）

适用于跨设备、跨团队的共享服务。

特点：
- 使用 Streamable HTTP 传输
- 需要 TLS 加密
- 需要认证（OAuth 2.1）
- 可独立扩缩容

适用场景：

• 团队共享的数据库 Server
• 企业内部系统接入
• SaaS 形式的 MCP 服务

多租户部署

适用于服务提供商。

特点：
- 每个租户独立的认证和权限
- 数据严格隔离
- 资源配额管理
- 按租户计量

三、配置管理

配置文件

Server 通常需要配置：

• 监听地址和端口
• 日志级别
• 外部服务凭证
• 权限白名单
• 资源限制

环境变量

推荐的环境变量分类：

MCP_SERVER_PORT=3000           # 服务配置
MCP_LOG_LEVEL=info             # 日志配置
MCP_ALLOWED_PATHS=/data,/tmp   # 权限配置
DB_CONNECTION_STRING=...       # 外部依赖（通过 Secret Manager）
API_KEY=...                    # 认证凭证（通过 Secret Manager）

配置热加载

• 日志级别可以热加载
• 权限白名单建议重启生效
• 凭证变更必须重启

四、Secret 管理

方式	安全性	适用场景
环境变量	中	本地开发
配置文件	低	不推荐
Secret Manager	高	生产环境
云 KMS	很高	企业级

核心原则：

• Secret 不写入代码
• Secret 不写入日志
• Secret 不写入配置文件（如果配置文件会被提交到 Git）
• 定期轮换 Secret

五、健康检查

健康检查端点：

GET /health → { status: "ok", version: "1.2.3", uptime: 3600 }

检查项目：
- 进程是否存活
- 依赖服务是否可达
- 内存使用是否正常
- 连接池是否健康

六、发布策略

滚动发布

1. 部署新版本实例
2. 健康检查通过
3. 流量切换到新版本
4. 旧版本下线

适用于远程 HTTP 部署。

灰度发布

1. 部署新版本（少量实例）
2. 部分流量路由到新版本
3. 监控指标
4. 逐步扩大流量
5. 全量发布或回滚

适用于大规模部署。

回滚策略

• 保留前一个版本的镜像/包
• 回滚时间 < 5 分钟
• 数据库 Schema 变更需要向前兼容
• 回滚后检查数据一致性

七、扩缩容

水平扩展

• 无状态 Server 可直接水平扩展
• 有状态 Server 需要外部存储（Redis 等）
• 负载均衡器分发请求

自动扩缩容

指标	扩容阈值	缩容阈值
CPU	> 70%	< 30%
内存	> 80%	< 50%
请求延迟	> 2s	< 500ms
连接数	> 80% 容量	< 20% 容量

八、限流和资源配额

限流维度：

- 每个用户：每分钟最多 N 次调用
- 每个 Tool：每秒最多 M 次执行
- 每个 Server：总 CPU/内存上限
- 全局：总连接数上限

九、进程守护

本地 Server

• Claude Desktop 自动管理进程生命周期
• 自定义 Host 需要实现进程管理
• 使用 systemd（Linux）或 launchd（macOS）守护进程

远程 Server

• 使用容器编排（Kubernetes）
• 使用进程管理器（PM2、supervisor）
• 配置自动重启策略

十、自动更新风险

MCP Server 的自动更新需要特别注意：

风险	缓解策略
Tool 行为变化	固定版本，手动升级
新增恶意 Tool	审查更新内容
依赖包漏洞	定期安全扫描
配置被覆盖	配置与代码分离
Schema 不兼容	兼容性测试

建议：生产环境不建议自动更新，应使用受控的发布流程。

十一、依赖安全

• 定期扫描依赖漏洞
• 锁定依赖版本
• 使用可信的包来源
• 最小化依赖数量
• 监控安全公告

十二、运行用户权限

最小权限原则：

- 不使用 root 运行 Server
- 文件系统访问限制在必要目录
- 网络访问限制在必要端口
- 数据库使用最小权限账户
- 禁止不必要的系统调用

十三、备份和恢复

• 定期备份配置
• 备份 Secret（加密存储）
• 备份数据库（如果使用）
• 测试恢复流程
• 记录恢复时间目标（RTO）

十四、Mermaid 部署架构

十五、设计原则

1. 配置与代码分离：不硬编码任何环境特定配置
2. Secret 不落地：使用 Secret Manager，不写入文件或日志
3. 最小权限运行：不用 root，限制文件和网络访问
4. 健康检查必备：每个 Server 都需要健康检查端点
5. 受控发布：不使用自动更新，使用灰度发布
6. 可回滚：每次发布都可以快速回滚
7. 监控先行：部署前先建立监控和告警

十六、常见误区

误区	正确做法
在代码中硬编码 Secret	使用 Secret Manager
使用 root 运行 Server	创建专用用户
不设置健康检查	必须有 /health 端点
自动更新生产环境 Server	使用受控发布流程
不限制资源使用	设置 CPU/内存上限
日志输出敏感信息	脱敏处理
不测试回滚	定期演练回滚流程

十七、实践检查清单

• Secret 通过 Secret Manager 注入
• 使用非 root 用户运行
• 健康检查端点已实现
• 日志脱敏已配置
• 资源限制已设置
• 限流策略已配置
• 监控和告警已建立
• 回滚流程已测试
• 依赖安全扫描已配置
• 备份策略已实施

十八、与其他概念的关系

• MCP Server设计：Server 的部署相关设计
• MCP日志与可观测性：运维所需的日志和监控
• MCP测试策略：部署前的测试保障
• MCP安全边界：部署的安全考量
• MCP认证与授权：远程部署的认证
• MCP性能与扩展性：扩缩容的性能考量
• MCP生态与实现选型：部署方式的选型

十九、适用边界

适用于：

• 将 MCP Server 部署到生产环境
• 团队共享 MCP 服务
• 企业级 MCP 部署

不适用于：

• 个人开发环境（本地进程即可）
• 一次性脚本或原型

二十、参考资料

• MCP 官方文档 - https://modelcontextprotocol.io/
• Docker 安全最佳实践 - https://docs.docker.com/develop/security-best-practices/
• OWASP 部署安全 - https://owasp.org/www-project-deployment-guide/