微服务架构的鉴权机制以及大模型MCP和业务服务集成

目录

• 鉴权
  • • 方案对比分析
    • 适用场景再梳理
      • 方案1更适合以下场景：
      • 方案2更适合以下场景：
• 方案2 鉴权实现
  • BFF 层鉴权
  • 业务服务鉴权
• 大模型MCP和业务服务查询集成
  • • 四、关键决策点
    • 五、推荐架构模式
      • 混合依赖模式（Hybrid）
      • 技术实现示例
    • 六、总结
• 参考资料

鉴权

在微服务架构，通常BFF,和业务服务。有2种鉴权方案
方案1 BFF 负责所有的鉴权，包括基础越权和越权校验。 业务服务提供原子的查询接口（如订单列表查询，提供 用户id，销售组织ids，产品类型ids），不做权限校验。

方案2 BFF负责基础的权限校验，业务服务负责越权校验。 业务服务提供的不是原子的查询接口（如订单列表查询，只用户id， 订单服务去权限服务获取权限点）。业务服务需要依赖权限服务获取权限点，并做越权校验。

方案对比分析

维度	方案1（BFF层获取权限）	方案2（订单服务调用权限服务）
职责边界	✅ 订单服务无状态，专注业务逻辑；BFF负责权限聚合	❗️ 订单服务依赖外部权限服务，职责耦合
性能	✅ 可缓存权限数据，减少重复查询（尤其权限变更低频场景）	❗️ 每次请求需调用权限服务，无缓存时延迟较高
安全性	❗️ BFF需确保权限参数不被篡改（需签名/加密）	✅ 权限在服务内闭环校验，参数不可伪造
可维护性	❗️ 权限模型变更需同步修改BFF+订单接口	✅ 权限逻辑内聚在订单服务，修改点集中
扩展性	✅ 原子接口可复用（如支持管理后台直接调用）	❗️ 接口与用户权限强绑定，扩展需侵入订单服务逻辑
容错能力	✅ 权限服务宕机时，BFF可用缓存数据降级处理	❗️ 权限服务宕机直接导致订单服务不可用

适用场景再梳理

方案1更适合以下场景：

• 开放平台：外部开发者通过BFF调用原子接口，需严格隔离内部权限服务。
• 高频查询场景：订单服务压力大，需减少每次请求的RPC调用链路。
• 多租户SaaS：租户权限模型稳定，可接受短暂缓存不一致。

方案2更适合以下场景：

• 金融/政府系统：权限数据必须实时校验，不允许任何缓存延迟。
• 权限模型动态多变：用户-权限关系每分钟都可能变化。

2. 低频写请求：实时调用权限服务 + 熔断降级（方案2优化）。

像互联网公司也不是一刀切用方案1或者方案2，还是根据场景选择合适的架构。比如淘宝面向C端的电商估计是选择方案1，但是淘宝内部管理系统可能是选择方案2.

方案2 鉴权实现

BFF 层鉴权

BFF层强制校验用户身份与基础角色的核心目标是快速拦截非法请求，保护后端服务免受未授权访问

​1. 用户身份校验

、
​目的：确认请求来自合法用户，而非攻击者或未登录访客。
​校验内容：
​登录态验证：检查Token/Session是否有效（如JWT是否过期或被篡改）。
​设备指纹验证：识别异常设备（如突然更换IP或设备型号）。

2. 基础角色校验

​目的：过滤用户是否有权访问某类接口（粗粒度权限）。
​校验内容：
​用户角色：如买家（buyer）、卖家（seller）、管理员（admin）。
​租户归属：如用户所属企业、组织（防止跨租户越权）。

业务服务鉴权

越权校验。

大模型MCP和业务服务查询集成

四、关键决策点

1. 协议兼容性

   • 若业务服务已通过BFF暴露标准化API（如REST），且无需低延迟，可复用BFF。
   • 若需高性能（如流式响应）、自定义协议（如二进制+Protobuf），应直连业务服务。

2. 安全性要求

   • 敏感操作（如支付）：必须通过BFF完成端侧用户二次确认，MCP不可直连核心服务。
   • 内部工具调用（如数据查询）：MCP直连业务服务，通过服务网格（如Istio）鉴权。

3. 性能与扩展性

   • 高频读操作：MCP直连缓存或读库，绕过BFF减少延迟。
   • 低频写操作：通过BFF集中审计，保障操作可追溯性。

---

五、推荐架构模式

混合依赖模式（Hybrid）

graph TB A[大模型] --> B[MCP Server] B -->|直连协议| C[业务服务] B -->|BFF协议| D[BFF层] D --> E[前端/App] C --> F[(数据库)] C --> G[(消息队列)] B --> H[向量引擎] B --> I[知识图谱]

• 直连业务服务：用于实时性要求高的场景（如流式数据读取、事务操作）。
• 依赖BFF：用于需要端侧用户上下文（如Session、设备信息）的请求。

技术实现示例

1. 协议路由表（YAML配置）：

   routes:
     - name: order_query
       protocol: grpc      # 直连业务服务
       endpoint: order-service:50051
       required_headers: [user_id, auth_token]
     - name: user_profile
       protocol: rest      # 通过BFF
       endpoint: https://bff.example.com/api/profile
   

2. 动态依赖注入：

   def route_request(request):
       if request.type == "HIGH_RISK":
           # 通过BFF完成二次鉴权
           return call_bff(request)
       else:
           # 直连业务服务
           return call_service_directly(request)
   

---

六、总结

• MCP Server应优先直连业务服务接口，确保对大模型任务的高效响应与灵活调度。
• 仅在需要端侧上下文或严格审计时依赖BFF（如用户会话管理、敏感操作）。
• 核心原则：
  • 性能敏感路径：直连业务服务，减少中间层。
  • 安全敏感路径：通过BFF复用企业级安全基建。
  • 协议适配层：在MCP Server内统一处理多协议转换，而非强制依赖BFF。

通过分层依赖与动态路由，MCP Server可在大模型与业务系统间实现高效、安全的协作，同时避免架构僵化。

参考资料