MCP Server 封装存量 Java 微服务的工程模式

MCP Server 封装存量 Java 微服务的工程模式

一、为什么这件事值得单独做成一层

企业里真正重要的能力，往往不在新写的 AI Demo 里，而在已经跑了很多年的 Java 微服务里：

• 订单、库存、支付、会员、营销等核心域能力，通常已经沉淀在 Spring Boot、Dubbo、gRPC 或内部 REST 服务中
• 这些系统经过多年演进，拥有完备的数据模型、业务规则、鉴权体系和审计链路
• 问题不在于“能力不存在”，而在于这些能力并不是为 LLM 和 Agent 设计的

于是团队常常会掉进两个误区：

1. 直接让 Agent 调已有 OpenAPI。
2. 重新写一套“AI 专用后端”。

这两种方式都不理想。

前者的问题是，传统 API 面向的是前端或系统集成，不是面向模型语义。接口名、参数名、枚举值、异常语义、前置条件，对 LLM 来说往往并不透明。后者的问题则是重复建设，把已经在线上被验证过的业务逻辑又复制一遍，最终形成两套规则、两套治理、两套数据口径。

更合理的做法，是在存量微服务与 Agent 之间增加一层 MCP Server 能力适配层：

• 对上，暴露统一、可发现、可描述、可组合的 Tool/Resource/Prompt 能力
• 对下，复用现有 Java 微服务的业务实现、权限模型和数据边界
• 对中间，补齐 LLM 场景下必须有的语义描述、调用约束、并发治理和安全审计

这才是 MCP 在企业架构中的真正价值：**不是替代微服务，而是把微服务升级为 Agent 可安全消费的标准能力面。**

二、先把概念讲透：MCP 在微服务体系中的角色到底是什么

2.1 MCP 不是网关，也不是 Agent 框架

很多文章一上来就写“用 MCP 暴露工具”，但没有把它在整体架构中的职责讲清楚。

MCP 更接近一种 面向模型的能力协议层。它解决的是三类问题：

• 能力发现：Agent 如何知道系统里有哪些可调用能力
• 能力语义：模型如何理解工具的用途、参数含义、约束条件和返回结构
• 能力调用：模型如何用统一协议触发后端动作

它不直接解决的事情包括：

• 复杂业务实现本身
• 企业服务治理本身
• 多智能体编排本身
• API 网关的统一南北向流量接入

所以在企业架构里更准确的定位应该是：

用户 / Agent / Host │ │ MCP Protocol ▼ MCP Server（语义暴露层 + 治理适配层） │ │ HTTP / Dubbo / gRPC / MQ / DB ▼ 存量 Java 微服务与企业基础设施

一句话总结：

• 微服务负责业务能力
• 网关负责流量接入
• MCP Server负责让模型“理解并安全调用这些能力”

2.2 Tool、Resource、Prompt 如何映射企业系统

在企业系统里，MCP 三类原语可以这样理解：

实际项目里，最核心的是 Tool。因为企业希望 Agent 不只是“会回答”，而是“能做事”。

但一旦进入“做事”这个维度，架构要求就完全变了。你需要的不再只是一个能返回 JSON 的接口，而是：

• 明确的前置条件
• 强约束参数定义
• 幂等语义
• 超时策略
• 权限校验
• 审计追踪
• 失败补偿
• 风险分级

这也是为什么很多 MCP Demo 可以工作，但无法直接进生产。

三、存量 Java 微服务接入 MCP 的四种主流工程模式

先给出结论：**不存在唯一最佳模式，只有最适合当前系统约束的模式。**

3.1 选型矩阵

下面分别展开。

四、模式 A：同进程嵌入模式

4.1 适用场景

如果你的存量服务本身就是 Spring Boot 应用，而且可以正常发版，那么最推荐从这一种开始。它的核心思想是：

在现有服务内部直接嵌入 MCP Server，把服务中的领域能力以薄适配层方式暴露为 Tool。

优势很明显：

• 不需要再多维护一套代理服务
• 没有额外网络转发损耗
• 能最自然地复用现有 Spring Bean、事务、权限、日志和监控体系
• 适合先在单个核心域快速打样，再逐步规模化

4.2 推荐分层

即使是同进程模式，也不建议直接把 @Service 方法原封不动暴露成 Tool，而应该分四层：

MCP Transport 层 ↓ Tool Facade 层 ↓ Application Service 层 ↓ Domain / Repository / External Client

其中真正需要暴露给 LLM 的，只应该是 Tool Facade。

原因很简单：

• 领域服务的接口通常对人类程序员友好，不一定对模型友好
• 领域服务中的参数对象往往缺少面向模型的描述信息
• Tool 层更适合承接参数规整、风险检查、权限校验和结果裁剪

4.3 生产级代码示例

下面给一份更接近真实项目的实现，而不是只停留在注解 Demo。

1. 领域服务

package com.example.order.application; import com.example.order.domain.Order; import com.example.order.domain.OrderRepository; import com.example.order.domain.command.CreateOrderCommand; import com.example.order.domain.command.RefundOrderCommand; import com.example.order.domain.exception.OrderNotFoundException; import com.example.order.domain.exception.RefundNotAllowedException; import org.springframework.stereotype.Service; import org.springframework.transaction.annotation.Transactional; @Service public class OrderApplicationService { private final OrderRepository orderRepository; private final InventoryGateway inventoryGateway; private final PaymentGateway paymentGateway; public OrderApplicationService(OrderRepository orderRepository, InventoryGateway inventoryGateway, PaymentGateway paymentGateway) { this.orderRepository = orderRepository; this.inventoryGateway = inventoryGateway; this.paymentGateway = paymentGateway; } @Transactional(readOnly = true) public OrderDetailDTO getOrder(String orderId) { Order order = orderRepository.findById(orderId) .orElseThrow(() -> new OrderNotFoundException(orderId)); return OrderDetailDTO.from(order); } @Transactional public CreateOrderResult createOrder(CreateOrderCommand command) { inventoryGateway.reserve(command.items()); Order order = Order.create(command.userId(), command.items(), command.requestId()); orderRepository.save(order); return new CreateOrderResult(order.getOrderId(), order.getStatus().name()); } @Transactional public RefundResult refundOrder(RefundOrderCommand command) { Order order = orderRepository.findById(command.orderId()) .orElseThrow(() -> new OrderNotFoundException(command.orderId())); if (!order.canRefund(command.amount())) { throw new RefundNotAllowedException(command.orderId(), command.amount()); } paymentGateway.refund(order.ge