1 简介

本文试图说明mcp和mvc结构主要区别（深入说明 —— 行为、架构与工程特性层面）

下面把差别按主题展开，给出为什么不同、会带来哪些工程后果，以及如何把两者结合起来。

2 交互模式：实时事件驱动（Push） vs 请求-响应（Pull）

• MVC（典型 Web MVC）

客户端发 HTTP 请求，服务器返回响应（短连接、无状态或依赖会话 cookie）。

服务器被动响应请求，客户端轮询或使用额外技术来获取实时数据。

• MCP WebSocket

双向长连接，服务器可以随时推送事件（push）；客户端也可随时发起消息。

更适合实时协作、流式生成、LLM 的流式交互（Claude 的边生成边请求工具）。

工程影响：需要考虑心跳、ping/pong、连接管理、网络断开重连和消息顺序，且后端通常要维持更多状态（会话、本地缓存），而不是短时无状态处理。

3 有状态 vs 无状态

MVC 控制器通常尽量无状态（或把状态放 Model/DB），可横向扩展简单（任意实例都可处理请求）。

MCP session是显式有状态（MCPSession 保存 conn、send、会话级工具、claudeWaiting 等），会话状态与内存结构耦合在进程中。

工程后果：水平扩展需要额外设计（例如：使用 Redis pub/sub 或集中化 session/messaging，或要求 LB sticky session）。否则广播/claudeWaiting 等跨实例协调会失效。

• 控制流：同步调用 vs 异步/流式、事件交错

MVC：Controller 处理请求后同步返回。即便异步任务，也是由后台任务系统并通过轮询/回调通知。

MCP：消息驱动、异步、流式。特别的交错思考流程（LLM 发起工具调用并在生成过程中阻塞等待）需要在服务端维持等待通道、把工具结果反填给 LLM 流——这是 MVC 很少见到的控制流。

实现复杂度：需要小心死锁、超时、并发竞态、内存泄露（等待通道无限期挂起）。

• 横向扩展与可观测性

MVC：易于用 stateless 实例 + LB 扩展，日志/监控较直观。

MCP：需要会话粘性或外部共享消息系统（Redis、NATS、Kafka）来广播和路由消息；追踪单次交互（一个 LLM 的流 + 多个工具调用）需要分布式追踪设计（trace id 贯穿 WebSocket、工具调用、外部 LLM）。

• 事务边界与一致性

MVC：通常每个请求一个事务边界，数据库事务很好界定。

MCP：一系列消息、工具调用可能跨多个消息/时间点（例如：LLM 先读取历史、再写入消息、再继续生成），事务变得松散 —— 需通过幂等、补偿、事件日志来保证一致性。

• 安全与鉴权

MVC：常见使用 cookie/jwt，在每次请求验证。

MCP：鉴权必须在 WebSocket 建连时或首条 initialize 消息中完成，并且长期有效；还必须对工具调用权限做细粒度控制（谁能调用哪些工具、对哪些资源读写）。注意防止 CSRF、XSS、滥用工具（rate limit）。

• 代码组织与测试

MVC：清晰 controller -> service -> repository 分层，单元测试容易（短请求）。

MCP：还可以采用相同分层思想，但要引入事件中间层（message handler / dispatcher / domain events），并为长连接、并发行为写更多的集成测试与并发测试（模拟网络、断连、slow consumer）。

4、 MCP 与 MVC 结合（实践建议）

MCP 并不是要摈弃 MVC 的分层思想；相反，可以把它视为替代传统 HTTP Controller 的消息入口（Controller 层的变体），并把服务内部仍然拆成清晰层次：

• Transport 层（WebSocket / MCP 协议）：

负责连接管理、心跳、消息序列化、身份认证、速率限制。

wsHandler、reader、writer、sendJSON 属于这里。

• Message Dispatcher / Controller 层：

负责根据 MCPMessage.Type 和 Method 路由到具体 Handler（类似 HTTP 路由）。

例如 handleToolCall、handleInitialize 属于此层。尽量保持“无业务逻辑”，转发到 Service。

• Service 层 / Domain 层：

真正的业务逻辑（如 sendMessage、getChatHistory）实现。可以单元测试、放到独立包。

Service 不直接操作 WebSocket，而是返回结果或者发事件到事件总线。

• Repository / Persistence 层：

数据持久化（DB、Redis），替代内存 sync.Map。保证可扩展与持久化。

• Event / PubSub 层（可选但推荐）：

用于跨进程广播（例如 Redis pub/sub），解决多实例广播问题。

当 service 发生 chat_message 时 publish 到 pubsub，所有实例订阅并把消息下发到本实例的 WebSocket 客户端集合。

这样做能把“实时长连接的复杂性”限制在 Transport + Dispatcher 层，而把业务逻辑保持在传统 MVC/分层可测试位置。

5 小结

MCP WebSocket 服务是一种面向会话、消息驱动、双向实时的应用层，它将 Transport（WebSocket）与 Message Dispatcher、工具执行、LLM 流式交互连接起来，能够实现 LLM 的“交错思考”并把工具结果实时回填给 LLM。

与传统 MVC 的区别在于：长连接与事件驱动、显式会话状态、异步流式控制流、跨消息事务、扩展与一致性挑战。但两者不是互斥：MCP 的内部仍应遵循 MVC/分层的设计，把 Transport 与业务逻辑（Service/Repo）分离，以提升可维护性和可扩展性。

工程上需要注意会话生命周期、超时、并发安全、广播跨实例、鉴权、可观测性与对交错思考流的精细管理（比如基于 message ID 的等待通道、多实例协调）。