走向生产 — 架构、打包、测试与可观测
这一章讲三件事: 一台能跑的 MCP 服务器,离「敢给客户用」还差哪五关; 每一关里,MCP 应用和传统 Web 应用一样的地方、不一样的地方; 以及上线之后,怎么知道它活得好不好、坏了怎么不被骂。 这是全书收官章——前面十一章造出来的东西,这一章把它当成产品重新过一遍。
1. 顶层全景:上线日的五道关卡
先把全章压成「上线日的一天」——这是本章主走查的轨道:
早 9:00 合并代码 → 入口有 Zod 校验,坏数据进不来(关① 架构)
早 9:30 CI 自动跑三层测试,包括一组「黄金提示词」(关② 测试)
早 10:00 流水线部署:构建 → 测试 → 上线,每一步是护栏(关③ 部署)
下午 2:00 流量尖峰:网关限流、熔断器跳闸,用户无感(关④ 弹性)
下午 5:00 看仪表盘:日志、追踪、指标;AI 的 token 账单独算(关⑤ 运营)
图说:五关任何一关缺席,前面十一章的手艺都会在第一次事故里赔掉。
上面这些时间是演示编排,不是真实数值。
2. 关①架构:MCP 服务器很少单独站在外面
真实系统里,MCP 服务器最常见的位置是躲在一座传统 Web API 后面: 用户的请求先打到你现有的 REST API(过它原有的认证中间件), 再由 API 层里嵌着的 MCP 客户端,用 JSON-RPC 转发给 MCP 服务器1。 第 06 章那个「嵌在应用里的客户端」,在架构图里就站这个位置1。
架构审查时书里点名的三件事2:
- 模块化:一个模块只管一件事,改它的理由只有一个—— 解析逻辑和业务逻辑不住同一个文件(第 05 章的 tools/ 目录就是这个原则的样子);
- 入口校验:所有进来的数据,先用 Zod 过一遍——
合法才放行,不合法当场报错。这不只为正确性,也为安全:
恶意输入在入口就被拦下。而且书里说的校验不止入口——
输入、输出、组件之间的契约,三层都要验;
给工具的输出也立 schema(第 03 章埋的那个好习惯),就是「输出」这一层的样子。
书里给了低层服务器里
Schema.parse把关的完整代码 (就是第 05 章主走查的第二关)2; - 为 AI 留余地:客户端带着模型,就要考虑模型的脾气—— 响应慢时界面要有反馈而不是卡死;模型挂了(故障或限流)要有重试与熔断; token 用量要当成本管,该缓存缓存2。
3. 打包与分发:你的服务器以什么形态出门
先选形态,再选渠道3。
形态一:standalone(独立服务器)。 公开或公司内部用。 跑在用户本机的(STDIO 型)要回答沙箱问题—— 沙箱就是「给程序划一个围栏,围栏外的文件和网络它碰不到」: 书里拿官方文件系统服务器当样板——配置里限定能访问的目录, 还给出容器化运行的指引,尽量压小它的「手可及范围」3。 跑在远端的(HTTP 型)则回到第 10 章:OAuth 或 API key, 外加 RBAC(按角色分配权限——管理员、普通用户、访客各见各的)3。
形态二:嵌入——英文叫 embedded,就是把 MCP 集成做成你产品的一部分: 那你发布的不只是服务器,还有嵌在应用里的客户端,两者随你的产品一起出门3。 这种形态也叫「嵌入式」。
渠道三条4:
| 渠道 | 适合谁 | 用户怎么用 |
|---|---|---|
| Docker 镜像 | 要环境一致、好部署 | docker run,书里给了官方文件系统服务器的多阶段 Dockerfile |
| 包管理器(npm / PyPI / NuGet) | 要被别的项目当依赖 | npm install 你的服务器 |
| 源码仓库 | 想给最大控制权 | clone 自己构建;README 里附上 mcp.json 配置示例 |
版本号怎么涨也有规矩,叫语义化版本(semver):主.次.修 三位——
1.3.0 修了 bug 涨成 1.3.1,加了向下兼容的功能涨成 1.4.0,
做了不兼容的改动涨成 2.0.0。用户由此可以自主选择:
钉 1.3.x(只吃修复)还是钉 1.x.x(连功能一起收,但不冒不兼容的险)5。
4. 关②测试:AI 那一半,老办法测不了
传统的两层照跑6:
- 单元测试:把解析、纯逻辑拆出来单独测——第 05 章那个不碰框架的
add.ts,就是为这层设计的; - 集成测试:模拟用户一路打穿:界面 → Web API → MCP 客户端 → MCP 服务器 → 回来。
新的是第三层:AI 测试。 模型的回答不稳定,同一句话两遍可能两个样, 所以6:
- 对抗测试(adversarial testing):专门构造想把它带沟里的输入,看它出不出格—— 比如藏了「忽略你之前的指令」的数据,这就是提示注入 (prompt injection):把恶意指令混在正常输入里,骗模型按攻击者的意思办;
- 黄金提示词集:攒一批「该答好 / 该调工具」的提示词,每次发布前跑一遍, 防「改了代码,AI 行为悄悄变了」。
5. 关③部署:一键、多次、带护栏
书里给「2025 年的稳健(robust)」下了个定义:点一下按钮就部署,一天能部署好多次, 而且全程有护栏7。护栏就是流水线里的一道道检查: 测试不过不往下走、政策不合不往下走、性能退步不往下走7。
这套做法叫持续集成:代码一合并就自动构建、自动测试;配上持续部署——测试过了就自动上线。
干这套活的流水线,行话叫 CI/CD——工具是 GitHub Actions 或 Jenkins 这类,
它的产物通常是一个 .yml 配置文件7。
MCP 特有的一笔:如果你的发布物里有 AI(模型、提示词、上下文管理), 它可能要单开一条流水线——模型的表现、提示词的回归,和代码的测试节奏不是一回事7。
6. 关④⑤:上线之后,看得见、扛得住、说得清
看得见(可观测)靠三件套8:
| 件 | 记什么 | 回答的问题 |
|---|---|---|
| 日志(logs) | 一条条带级别、带上下文(用户 id、请求 id)的事件 | 「刚才发生了什么」 |
| 追踪(tracing) | 一个请求穿过各服务的完整旅程 | 「慢在哪一环」 |
| 指标(metrics) | CPU、内存、每 秒请求数、响应时间、错误率 | 「整体健不健康」 |
MCP 特有的一本账:token 用量——每个请求烧了多少词元、 多少是缓存命中的,既是成本账也是性能账;协议还有内建的日志级别 (给每条日志标严重等级的机制——debug/info/warning/error,排障时按等级筛着看)可以用8。
扛得住(弹性)靠三件套,而且都可以挂在网关上声明式配置9:
- 负载均衡(load balancing):流量分摊到多个实例,单点不炸;
- 限流(rate limiting):单位时间只放行进 N 个请求,防滥用也控 API 成本;
- 熔断(circuit breaker):下游连跪到阈值(预先定好的那条线——比如「连续失败 5 次」)就「跳闸」,一段时间直接拒, 给它喘息,也保住用户体验(降质不瘫痪)。
书里建议:AI 端点和应用端点分开设这三套——模型贵且慢,它的账要单算9。
说得清(治理):GDPR、HIPAA 这类法规落到工程上,就是留审计痕 (audit trail——谁、什么时候、改了什么,全程可查)、访问控制、加密; AI 还要管偏见与内容安全10。
最后一关是面向未来的:MCP 是年轻协议,还在变——SSE 已经废了; SDK 也在变,大版本可能破坏兼容。作者的处方:版本钉住一阵(主版本内升级), 安全更新必须跟,用 Dependabot 这类工具盯着依赖风险11。
7. 作者的判断与证据
有证据的:
- 集成模式、校验位置、打包形态、三条渠道、Dockerfile 样例,书里有代码与链接1234;
- 三件套(可观测/弹性)的清单与「挂网关」的建议是书中原话89;
- 「SSE 已废、SDK 要钉版本盯更新」写在书的结尾11。
作者的判断:
- 「AI 要独立流水线」「AI 端点单独设弹性策略」——作者的经验处方,合理但非标准;
- 网关推荐 Azure API Management / AWS API Gateway,测试推荐对抗测试—— 带有明显的微软系工具链视角(见总纲「这是谁在什么时候写的」);
- 章末总结「在安全上花的时间应该比你以为的多」——作者的优先级排序12。
判断(我们的,不是书里的): 这一章的正确读法是验收清单,不是教程—— 每一条都是「你不得不回答的问题」,答案多半要回到各专题的书里找。 它对 MCP 特有的增量其实只有三处:嵌在 REST 后的集成形态、token 成本账、AI 测试与治理。 其余九成是成熟的 Web 生产实践,被作者平移到了 MCP 语境——这不是缺点, 恰恰说明 MCP 服务器的工程化没有玄学。 如果错,会错在: 若你的 MCP 服务器是纯内部小工具(团队几个人用), 按这张清单全做是浪费——先沙箱、密钥、审计痕三样保命,其余按需。
8. 边界与局限
- 全章几乎没有 MCP 协议内容——它是「软件生产通识」在 MCP 上的套版; 代码示例又出现了 Python(FastAPI) 残留,且「create_user」的例子与所附代码对不上;
- 每条的深度都停在「该做什么」,「怎么做」普遍指向云厂商服务与外部链接;
- 多实例部署下的会话亲和(2025 代 Streamable HTTP 的会话表在内存里, 请求落到别的实例怎么办)——我们在第 04 章边界里提过的问题,本章没接住;
- 成本只有「token 预算」一句带过,没有容量规划与压测方法。
9. 可带走的
- MCP 服务器的常见位置:REST API 后面,入口一律 Zod 校验;
- 本机服务器想沙箱:限目录、容器化,手别伸出围栏;
- 分发三条渠道:Docker / 包管理器 / 仓库;版本号按 semver 涨,让用户有得选;
- 测试三层:单元(单元测试——每个函数、每个模块各测各的)、集成,外加 AI 测试(对抗 + 黄金提示词集);
- 部署要「一键多次带护栏」;AI 部分考虑独立流水线;
- 可观测三件套:日志、追踪、指标;token 账单独算;
- 弹性三件套:负载均衡、限流、熔断,挂网关声明式配置,AI 端点单列;
- 治理落地三样:审计痕、访问控制、内容安全;
- 协议与 SDK 都在变:钉版本、跟安全更新、工具盯依赖11。
10. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 集成模式 | Bringing MCP Apps to Production | text/14-fm-bringing-mcp-apps-to-production.txt:75(搜「RESTful API」) |
| 文档与架构审查 | 同上 | text/14-fm-bringing-mcp-apps-to-production.txt:178(搜「Modular design」) |
| Zod 校验 | 同上 | text/14-fm-bringing-mcp-apps-to-production.txt:194(搜「Validation」) |
| AI 对架构的影响 | 同上 | text/14-fm-bringing-mcp-apps-to-production.txt:405(搜「Decoupled architecture」)· :423(搜「Token budgeting」) |
| standalone 与沙箱 | 同上 | text/14-fm-bringing-mcp-apps-to-production.txt:489(搜「sandboxed」) |
| embedded | 同上 | text/14-fm-bringing-mcp-apps-to-production.txt:537(搜「ship an MCP client as well」) |
| 分发渠道 | 同上 | text/14-fm-bringing-mcp-apps-to-production.txt:547(搜「Docker container」) |
| semver | 同上 | text/14-fm-bringing-mcp-apps-to-production.txt:647(搜「incompatible API changes」) |
| 测试三层 | 同上 | text/14-fm-bringing-mcp-apps-to-production.txt:689(搜「Unit tests」)· :709(搜「AI tests」) |
| 部署与护栏 | 同上 | text/14-fm-bringing-mcp-apps-to-production.txt:737(搜「deploy something at the click of a button」) |
| 可观测三件套 | 同上 | text/14-fm-bringing-mcp-apps-to-production.txt:833(搜「Logging」)· :845(搜「Tracing」)· :859(搜「Metrics」) |
| token 账 | 同上 | text/14-fm-bringing-mcp-apps-to-production.txt:871(搜「token usage per request」) |
| 弹性三件套 | 同上 | text/14-fm-bringing-mcp-apps-to-production.txt:927(搜「Load balancing」)· :947(搜「Circuit breakers」) |
| 治理 | 同上 | text/14-fm-bringing-mcp-apps-to-production.txt:1075(搜「audit trail」) |
| future-proofing | 同上 | text/14-fm-bringing-mcp-apps-to-production.txt:1095(搜「fairly young protocol」) |