硬核！企业级MCP网关 mcp-context-forge

慢煮AI
0 阅读8分钟

背景

MCP（Model Context Protocol，模型上下文协议）  是一种用于规范大语言模型（LLM）与外部系统之间结构化上下文交互的通信协议。其核心目标是：让模型在决策和执行时，拥有准确、完整、安全且可操作的上下文信息。

它是大模型从“聊天机器人”升级为“可信智能体”的关键桥梁——它不传递原始数据，而是传递“模型此刻需要知道什么、能做什么”的结构化上下文。

MCP 的应用场景广泛，已基本成为智能体与外部应用通信的标准协议。

但由于该协议的兴起太快，市面上的MCP开源框架，并未集成安全方面的相关功能。传统 MCP 实现（如 fastmcp）只解决“模型能调工具”，但未解决“模型是否该调、能否安全调、是否有足够信息调”。

前面文章有介绍，fastmcp并未解决以下问题：

image.png

因此，如果要用于生产还需要进行改造。我在文章 juejin.cn/post/759763… 中介绍了在fastmcp基础上手搓一个具备安全属性的MCP服务架构。

开源MCP网关

今天给大家介绍一个开源的MCP网关，它解决了以上问题，并且更加优雅。

这个开源MCP网关的名字是 mcp-context-forge，它与fastmcp对比有如下优势。

维度fastmcp（假设为轻量级实现）mcp-context-forge
定位快速原型验证，最小化 MCP 协议实现生产级上下文网关，面向企业复杂场景
上下文能力仅传递基础消息 + 简单工具列表动态聚合多源上下文，支持状态感知
安全性基础 token 验证集成 IAM、字段级脱敏、操作审批流
扩展性插件少，难对接内部系统提供上下文插件框架，易集成 CMDB/监控等
适用场景实验室、Demo、简单问答运维自动化、金融客服、高合规要求场景

系统架构

MCP Context Forge 基于 FastAPI 构建，采用清晰的三层架构设计，兼顾高性能、可扩展性与多协议兼容能力，具体如下：

  • API 层：提供标准化的 HTTP 与 WebSocket 接入端点，支持 RESTful 请求与实时双向通信；
  • 服务层：封装核心业务逻辑，包括上下文聚合、权限校验、MCP 消息编解码及工具调用路由；
  • 数据层：采用 PostgreSQL/SQLite 作为持久化存储（用于配置、会话元数据），并集成 Redis 实现高速缓存与临时状态管理。

其架构图如下：

image.png

系统原生兼容多种通信协议，灵活适配不同客户端场景：

  • Server-Sent Events (SSE) ：适用于单向流式响应；
  • stdio：支持本地 CLI 工具或嵌入式部署；
  • HTTP/REST：用于传统请求-响应模式；
  • WebSocket：支撑低延迟、长连接的交互式智能体对话。

同时，它具备横向扩展能力。

  • 基于 Redis 的会话状态共享机制，实现无状态服务节点的横向扩展；
  • 结合 数据库连接池 与 异步 I/O，有效提升高并发下的吞吐能力与资源利用率。

该架构确保 MCP Context Forge 在保障上下文一致性与安全性的前提下，能够稳定支撑企业级智能运维、多租户 SaaS 应用等复杂场景的规模化部署需求。

协议实现

MCP Context Forge 严格遵循 Model Context Protocol（MCP）规范，全面支持协议定义的核心要素，包括：

  • Tools（工具） ：注册、发现与调用外部可执行能力；
  • Resources（资源） ：访问结构化数据实体（如配置项、监控指标、工单记录）；
  • Prompts（提示模板） ：动态注入上下文感知的指令或约束，引导模型行为；
  • Notifications（通知） ：支持异步事件推送，实现状态变更或告警的实时反馈。

在协议层，系统基于 JSON-RPC 2.0 标准实现消息路由与交互管理，并内置 协议版本协商机制，确保客户端与服务端在兼容性范围内高效通信。该设计不仅保障了跨平台互操作性，也为未来协议演进提供了平滑升级路径。

服务层架构

服务层负责实现各类 MCP 实体（如工具、资源、提示模板、通知等）的核心业务逻辑。所有服务均遵循统一的设计范式，确保系统的一致性与可维护性，具体包括：

  • 标准化 CRUD 操作：提供创建、读取、更新和删除的完整生命周期管理；
  • 分页支持：对列表类接口内置高效分页机制，保障大规模数据查询性能；
  • 指标埋点与追踪：自动采集关键操作的调用频次、响应时延等运行指标，支撑可观测性；
  • 事件通知机制：在状态变更或关键操作发生时，发布标准化事件供下游消费。

在技术实现上，所有服务均基于 SQLAlchemy 进行 ORM 数据访问，确保数据库交互的类型安全与可移植性；同时，利用 Redis 作为分布式缓存层，显著提升高频读取场景的响应速度并降低数据库负载。

数据持久化与缓存机制

为有效降低数据库负载并提升系统响应性能，MCP Context Forge 采用三级缓存策略，实现从内存到持久化存储的分层数据访问：

  • L1：进程内内存缓存（In-Memory Cache）
    每个工作进程（per-worker）维护本地缓存，用于加速高频、只读数据的访问，具有最低延迟但作用域限于单个进程。
  • L2：共享 Redis 缓存
    作为分布式缓存层，Redis 提供跨进程、跨节点的数据共享能力，适用于需在服务集群中一致缓存的元数据（如工具定义、注册信息等）。
  • L3：持久化存储（PostgreSQL / SQLite）
    作为系统唯一数据源，负责长期存储所有 MCP 实体的完整状态，确保数据可靠性与事务一致性。

缓存逻辑通过统一的抽象层进行管理，核心由两个单例组件实现：

  • registry_cache：用于缓存注册中心相关的实体（如可用工具列表、资源目录）；
  • tool_lookup_cache：专用于加速工具元数据的查询与解析。

该分层设计在保证数据一致性的同时，显著提升了系统吞吐能力与可扩展性。

传输层与协议适配器

MCP Context Forge 支持多种传输协议，灵活对接上游 MCP 服务器，满足不同部署环境与客户端场景的需求。当前支持的协议包括：

  • SSE（Server-Sent Events） ：适用于单向、流式下行通信；
  • stdio（标准输入/输出） ：便于本地 CLI 工具集成或嵌入式运行；
  • Streamable HTTP：支持基于 HTTP 的分块传输，兼顾兼容性与流式响应能力；
  • WebSocket：提供全双工、低延迟的实时双向通信。

为屏蔽底层协议差异，传输层通过 ClientSession 接口（来自官方 MCP SDK）对各类连接进行统一抽象。上层服务无需感知具体传输细节，仅需调用标准化会话方法即可完成消息收发，从而提升代码复用性与协议可扩展性。

传输层的架构如下：

image.png

管理界面与 UI 架构

MCP Context Forge 的管理界面（Admin UI）采用 服务端渲染（Server-Side Rendering）  架构，结合现代轻量级前端技术，兼顾开发效率与交互体验：

  • 核心框架：基于 HTMX 实现动态内容加载，减少对复杂前端框架的依赖；

  • 客户端交互：使用 Alpine.js 提供轻量级响应式行为（如表单验证、模态框、状态切换等），避免全页面刷新；

  • 资源组织：

    • 主页面模板：admin.html，包含 HTML 结构与 HTMX 指令；
    • 客户端逻辑：集中于 admin.js，封装 Alpine.js 组件与辅助函数；
    • 路由定义：由 FastAPI 路由器 admin.py:admin_router 统一管理，处理页面请求与 API 端点。

该架构在保持后端主导开发模式的同时，提供了接近单页应用（SPA）的流畅交互体验，且易于维护和扩展。

部署模式

MCP Context Forge 支持灵活的部署策略，可无缝适配从开发测试到大规模生产环境的不同需求：

  • 单节点开发模式：适用于本地开发与快速验证，支持通过 Docker Compose 一键启动；
  • 高可用生产模式：支持在 多集群 Kubernetes 环境中部署，具备自动扩缩容、服务发现与故障恢复能力。

应用已全面容器化，并作为标准 OCI 镜像发布至 GitHub Container Registry，镜像地址为：
ghcr.io/ibm/mcp-context-forge

该设计确保了环境一致性、部署可重复性，并为 CI/CD 流水线集成提供了坚实基础。

avatar
文章
阅读
粉丝