api聚合平台解决方案

单例应用的鉴权困境

中小企业就适合这样干

方案 A：API Gateway 统一鉴权（推荐你现在就这么做）

思路：所有请求都先到网关；网关负责：

• 校验 access token（JWT / introspection）
• 必要时做权限/租户判断（可选）
• 把“已认证的身份信息”通过 header 透传给下游服务 下游（知识库后端）不做登录逻辑，只做极轻量：从 header 拿到 user_id / tenant_id / roles。

关键点怎么落地

1. 统一入口

• 前端只打一个域名：api.xxx.com
• 网关按 path 分流：
  • /admin/* -> 管理系统后端
  • /kb/* -> 知识库后端

1. 网关做鉴权

• token 校验放在网关插件/中间件层（Kong 就是插件）
• 只要请求通过鉴权，网关加上这些头给下游：
  • X-User-Id: 123
  • X-Tenant-Id: t1
  • X-Roles: admin,editor
  • （可选）X-Email / X-Name / X-Permissions

1. 知识库后端怎么“零压力”

• 你只需要一个非常薄的依赖/中间件：
  • 校验请求是否来自网关（防止别人绕过网关直连知识库）
  • 读取 X-User-Id 等 header，当成当前用户上下文

防绕过这一步很重要：不然别人可以直接访问知识库服务并伪造 header。

防绕过的常用做法（任选其一或组合）

• 网络层隔离：知识库服务只在内网暴露；公网只暴露网关
• mTLS：网关到知识库用双向 TLS，知识库只接受持有客户端证书的请求
• 网关签名头：网关生成 X-Gateway-Signature（HMAC/时间戳），下游用共享密钥验证

这样知识库后端就不需要解析 JWT，也不需要对接登录系统，只信任“网关签过名的用户信息”。

api 网关

使用api网关为下游服务鉴权

上游服务获取 token