JJXxXLL

一句话先概括 这一节我做的是 MCP 协议里的 tools/list 能力，把原来写死返回的工具定义，改造成基于数据库配置动态生成工具列表和参数 Schema。 如果面试官问：你具体解决了什么问题？ 在 MCP 场景里，客户端连接服务端后，通常会先调用 tools/list 获取当前服务端支持哪些工具、每个工具叫什么、用途是什么、入参长什么样。 前一个版本的问题是，tools/list 返回的是硬编码的 demo 数据。这样虽然能跑通流程，但不具备可扩展性。只要换一个网关、换一个工具、换一套参数结构，就得改代码。 所以这节的目标就是把“工具定义”从代码里抽出来，放到数据库配置里，由系统运行时动态生成返回结果。这样新增工具时主要改配置，不需要改 ToolsListHandler 的业务代码。 如果面试官问：你的整体设计思路是什么？ 我的设计思路是“配置驱动 + 递归组装”。 系统里已经有两类数据： 网关配置：这个网关对应哪个工具、工具名称、工具描述是什么 协议映射配置：工具的每个字段如何定义，字段类型、父子层级、是否必填、排序等 我做的事就是把这两类配置读取出来，然后动态组装成 MC ...

AI MCP Gateway 从消息处理案例到 DAO 数据层落地一、这一节做了什么3.6 分支是在 3.5 分支的基础上继续向前推进的一步。 如果说 3.5 还停留在“消息协议处理案例”的阶段，那么 3.6 做的核心事情，就是把项目的基础设施层数据能力补齐，正式引入了： MyBatis 持久层映射 DAO 接口定义 PO 数据对象 MCP 网关相关库表设计 CRUD 测试验证 这一节的主题可以概括为： 从“协议消息怎么处理”，推进到“这些协议配置和网关信息如何落库、如何查询、如何维护”。 二、3.6 比 3.5 多了什么3.6 分支相对 3.5 主要新增了 1 个提交： feat: 第3-6节：基础层数据处理(Dao) 从改动内容看，重点不是业务逻辑编排，而是数据层正式建模。 1. 新增了 4 组核心 DAO 接口这一节新增了 4 个 DAO 接口，分别负责 4 张核心业务表的持久化操作： IMcpGatewayDao IMcpGatewayAuthDao IMcpProtocolRegistryDao IMcpProtocolMappingDao 每个 DAO 都 ...

MCP 网关开发实战：从协议框架到完整消息处理（3-4 → 3-5 分支演进）前言在前一阶段（3-4 分支）中，我们完成了 MCP（Model Context Protocol）网关的基础框架搭建，包括会话管理、SSE 通信通道和消息路由机制。但所有的消息处理器（Handler）都还是空实现。本文将详细介绍 3-5 分支 如何将这个框架完善为一个功能完整的 MCP 服务器，实现真正的消息协议处理。 一、整体架构演进1.1 3-4 分支：骨架阶段123456789101112131415161718┌─────────────────────────────────────────┐│ McpGatewayController ││ ┌─────────────┐ ┌─────────────┐ ││ │ SSE 连接 │ │ 消息接收 │ ││ │ /mcp/sse │ │ POST 接口 │ ││ └──────┬──────┘ └──────┬──────┘ │ ...

McpSchemaVO 详解：MCP协议消息结构定义📋 文件作用McpSchemaVO.java 是一个值对象（Value Object），定义了 MCP（Model Context Protocol）协议的消息结构，用于： 序列化：将Java对象转换为JSON字符串 反序列化：将JSON字符串转换为Java对象 🏗️ 核心结构1. 密封接口（Sealed Interface）123public sealed interface JSONRPCMessage permits JSONRPCRequest, JSONRPCResponse { String jsonrpc();} 作用： 定义所有MCP消息的公共接口 限制只有 JSONRPCRequest 和 JSONRPCResponse 可以实现该接口 确保类型安全，防止非法实现 sealed关键字的优势：123456789101112// Java 17+ 特性public sealed interface JSONRPCMessage permits JSONRPCRequest, JSO ...

🚀 ai-mcp-gateway v3.4 版本更新：MCP协议消息处理架构全面升级 📋 标题选项 从SSE连接到MCP协议：ai-mcp-gateway v3.4 消息处理架构演进 策略模式实战：ai-mcp-gateway v3.4 如何优雅处理MCP协议消息 MCP协议支持升级：ai-mcp-gateway v3.4 核心技术解析 🎯 引言在 ai-mcp-gateway v3.3 版本中，我们成功实现了基于SSE的实时通信能力，为AI微服务网关提供了会话编排架构。然而，v3.3 版本主要关注会话的建立和管理，对于具体的协议消息处理还不够完善。 在 v3.4 版本中，我们正式引入了对 MCP（Model Context Protocol）协议的完整支持，实现了基于策略模式的消息处理架构。本次更新共涉及 17个文件，新增 498行代码，删除 10行代码，标志着项目从”会话管理”迈向”协议支持”的重要里程碑。 ✨ 新特性1. MCP协议消息结构定义新增了完整的MCP协议消息结构定义，支持JSON-RPC 2.0协议格式。 核心类：McpSchemaVO 123456789 ...

Case模块运行机制详解一、整体架构case模块采用了责任链模式和策略模式的组合设计，通过多个节点串联处理MCP会话请求。整体架构如下： 1234567891011121314151617181920212223242526┌─────────────────────────────────────────────────────────────┐│ Case Module ││ ││ ┌──────────────┐ ┌──────────────────────────────┐ ││ │ Service │─────▶│ Session Factory │ ││ │ │ │ │ ││ │ McpMes ...

🚀 ai-mcp-gateway v3.3 版本更新：会话编排架构升级，SSE实时通信能力全面增强 📋 标题选项 从会话管理到会话编排：ai-mcp-gateway v3.3 架构演进实录 责任链模式实战：ai-mcp-gateway v3.3 如何优雅处理SSE会话流程 会话编排架构升级：ai-mcp-gateway v3.3 核心技术解析 🎯 引言在 ai-mcp-gateway v3.2 版本中，我们成功实现了基础的会话管理功能，为AI微服务网关提供了会话状态管理能力。然而，随着业务复杂度的提升，单一的会话管理服务已无法满足多样化的业务场景需求。 在 v3.3 版本中，我们引入了会话编排架构，采用责任链模式重构了会话处理流程，新增了完整的SSE（Server-Sent Events）实时通信能力。本次更新共涉及 22个文件，新增 473行代码，删除 20行代码，标志着项目从”会话管理”迈向”会话编排”的重要里程碑。 ✨ 新特性1. SSE实时通信接口新增了完整的SSE连接建立接口，支持客户端与服务器之间的实时双向通信。 新增接口：12@GetMapping(value ...

3.2分支会话管理功能详细解析一、改动背景与目标3.2分支（3-2-session-management）的核心目标是为AI微服务网关添加会话管理功能，以支持长连接、实时交互场景，如AI聊天、持续对话等。在3.1分支（3-1-init-project）中，项目仅完成了基础架构搭建，缺乏会话状态管理能力，无法支持需要保持上下文的AI服务交互。 二、具体改动内容1. 新增目录结构1234567891011121314ai-mcp-gateway-domain/└── src/main/java/cn/bugstack/ai/domain/session/ ├── adapter/ │ ├── port/ │ └── repository/ ├── model/ │ ├── aggregate/ │ ├── entity/ │ └── valobj/ │ └── SessionConfigVO.java └── service/ ├── ISessionManagementService.ja ...

深入理解 AI MCP Gateway：从协议演进到网关架构设计 摘要：本文梳理了大模型与企业内部系统交互的技术演进路径，深入分析了传统 Function Calling 模式在企业级落地时的耦合痛点。基于此，提出并设计了 AI MCP Gateway 架构方案，通过动态代理与协议翻译机制，实现现有 HTTP/RPC 接口的零代码接入。文章重点探讨了基于 SSE 的流式传输选型、JSON-RPC 2.0 协议解析及动态路由引擎的设计思路，旨在为企业级 AI 应用提供一套高内聚、低耦合的基础设施解决方案。 1. 引言：大模型落地的“最后一公里”难题在当前的 AI 工程化实践中，我们面临着一个显著的矛盾：大模型（LLM）的通用推理能力与企业内部私有业务数据/服务之间的割裂。 虽然 LLM 具备了强大的逻辑推理和代码生成能力，但它本质上是一个“黑盒”，无法直接访问外部数据库、微服务或遗留系统。为了解决这个问题，业界经历了从 Prompt Engineering 到 Function Calling，再到如今 MCP (Model Context Protocol) 协议的演进。 本文旨在梳 ...

String 还是 Hash 存储对象数据更好呢

1.基础知识1.主键和外键有什么区别?​ 主键是用来唯一标识一条记录的，不能为空也不能重复，一张表只能有一个主键。在 InnoDB 中，主键索引是聚簇索引，数据本身存放在主键索引的叶子节点中。 外键主要用于建立表与表之间的关联关系，用来约束子表中的字段必须来自于父表的主键或唯一键，从而保证数据一致性。外键字段可以重复，也可以为空，一张表可以有多个外键。 在实际生产环境中，一般不直接使用数据库外键，而是在业务层通过逻辑外键来维护数据一致性，以避免外键带来的性能开销和维护复杂度问题。 2.为什么不推荐使用外键与级联？外键和级联主要用于在数据库层面保证数据一致性，但在实际生产环境中通常不推荐使用。 一方面，外键和级联在插入、更新和删除时会带来额外的性能开销，尤其是在高并发场景下影响明显；另一方面，级联操作存在较大的误操作风险，一次错误删除可能导致大量数据被级联删除。 此外，外键不适用于分库分表和微服务架构，会增加系统的耦合度和维护成本。 因此，在实际项目中通常采用逻辑外键，在业务层通过代码和事务来保证数据一致性，而不是依赖数据库外键和级联机制。 什么是存储过程存储过程是一组预先编译并 ...

IoC有什么用？ 第一层（核心定义）：“IoC将对象创建和依赖管理的控制权从程序代码反转到容器，实现了解耦。我的类不再new依赖对象，而是通过构造器、Setter或字段声明它需要什么，容器在运行时注入给它。” 第二层（具体价值）：“它带来了四个关键好处：第一是解耦，让我的业务代码只依赖接口，便于替换实现。第二是易于测试，我可以轻松注入Mock对象进行单元测试。第三是集中管理，所有对象的生命周期由容器统一管理，更安全。第四是配置灵活，通过修改配置就能改变组件行为和依赖关系。” 第三层（结合实践）：“比如在我的项目中，OrderService依赖PaymentService。利用IoC，我只需用@Autowired声明依赖。当需要从微信支付切换到支付宝时，我只需配置不同的PaymentService实现Bean，OrderService的代码一行都不用改，这极大地提升了维护性和扩展性。”