# 身份认证中心

技术解析与开源项目匹配度分析报告

## 一、身份认证中心 — 系统定位

身份认证中心是整个全域智能认证与门户平台的底座系统，承担"一次认证、全域通行"的核心职责。 它不是简单的登录页面，而是一个完整的 IAM（Identity & Access Management）平台， 向上支撑门户、移动端、第三方业务系统的认证需求，向下对接零信任网关、短信服务、各业务系统的用户数据库。

┌────────────────────────────────────┐ │ 调用方 / 消费端 │ │ 门户平台 │ 移动端 App │ 业务系统 │ └──────────┬─────────────────────────┘ │ ┌──────────▼─────────────────────────┐ │ 身份认证中心 (IAM) │ │ ┌──────────┐ ┌──────────────────┐ │ │ │ 认证引擎 │ │ 协议网关 │ │ │ │ 多因子鉴权│ │ CAS/OAuth/SAML │ │ │ └──────────┘ └──────────────────┘ │ │ ┌──────────┐ ┌──────────────────┐ │ │ │ 用户管理 │ │ 策略引擎 │ │ │ │ 组织架构 │ │ 排他登录/设备绑定 │ │ │ └──────────┘ └──────────────────┘ │ └──────────┬─────────────────────────┘ │ ┌───────────────┼───────────────┐ ▼ ▼ ▼ ┌──────────┐ ┌──────────────┐ ┌────────────┐ │ 达梦数据库│ │ ESB 总线/Redis│ │ 零信任网关 │ │ 业务/日志 │ │ 会话/缓存层 │ │ 深信服aTrust│ └──────────┘ └──────────────┘ └────────────┘

### 核心价值

- 统一入口：以员工工号为全系统唯一身份标识，消除多套系统多套账号
- 协议适配：7 大主流协议全覆盖，兼容新老系统认证需求
- 安全底座：多因子认证、设备绑定、零信任、审计日志构成安全防线
- 开放能力：多语言 SDK + 标准化 API，降低第三方系统接入成本

## 二、核心能力矩阵

能力域 | 子能力 | 需求要求
--- | --- | ---
认证方式 | 基础认证 | 账号密码、短信验证码、APP 扫码
生物识别 | 指纹识别、人脸识别
硬件/网络 | USBKey 证书认证、IP 认证
协议支持 | 企业 SSO | CAS、SAML 2.0
OAuth 生态 | OAuth 2.0、OpenID Connect
传统协议 | REST Protocol、Digest Authentication、Remote Address
策略控制 | 终端策略 | PC/移动端分别配置默认鉴权方式
会话策略 | 排他登录、强制手机绑定、设备绑定与数量限制
安全策略 | 密码规则、错误锁定、验证码切换
集成对接 | 应用集成 | 多语言 SDK（Android/iOS/JSP/JAVA/ASP/PHP/C/C#/VB）
基础设施 | 零信任集成、短信模块、ESB 数据同步

## 三、多元化身份认证技术解析

### 3.1 认证方式矩阵

认证方式 | 技术原理 | 适用场景 | 安全等级
--- | --- | --- | ---
账号密码 | 用户输入预设凭证，服务端校验哈希 | PC 端基础登录、密码代填底层 | 中
短信验证码 | 服务端生成随机码通过短信网关下发，限时校验 | 移动端快捷登录、忘记密码重置 | 较高
APP 扫码登录 | PC 端展示动态二维码 → App 扫码确认 → 服务端关联两端的 session | PC 端免密登录，安全且体验好 | 较高
IP 认证 | 基于 Remote Address，信任内网 IP 段直接放行或降级验证 | 内网办公免登录、零信任内外网判断依据 | 低（需配合其他因子）
指纹识别 | 移动端调用系统生物识别 API（Android BiometricPrompt / iOS LocalAuthentication） | 移动端快捷二次验证 | 较高
人脸识别 | 移动端摄像头采集 → 本地/云端活体检测 + 特征比对 | 高安全场景二次认证 | 较高
USBKey 证书 | 基于 X.509 数字证书，私钥存储在硬件 USBKey 中，TLS 客户端证书认证 | 管理后台、高安全等级操作 | 高

### 3.2 终端自适应认证策略

需求要求"基于系统用户工作方式不同，分别配置 PC 端与移动端的默认鉴权方式"。这体现了一个核心设计理念： 认证方式不全局统一，而是按终端类型分别配置默认值。

设计意义
PC 端以键盘输入为主，默认推荐账号密码或 USBKey；移动端具备生物识别能力，默认推荐指纹/人脸。 系统管理员在后台为每种终端配置默认方式，用户可在允许范围内切换。

## 四、SSO 协议体系

### 4.1 协议对比

协议 | 类型 | 数据格式 | 典型场景 | 方向
--- | --- | --- | --- | ---
CAS | SSO 协议 | Ticket (ST/TGT) | Web 应用统一认证，企业/高校主流 | 中心化
OAuth 2.0 | 授权框架 | JSON + JWT | API 授权、第三方应用接入、移动端 | 去中心化
OpenID Connect | 身份认证层 | JWT (ID Token) | 基于 OAuth 2.0 的身份认证，现代 Web/Mobile App | 去中心化
SAML 2.0 | SSO 协议 | XML | 企业级跨域 SSO，政企系统常用 | 联邦化
REST Protocol | API 认证 | JSON | RESTful API 的 Token 认证 | API 级别
Digest Authentication | HTTP 认证 | HTTP Header | 浏览器原生认证，替代 Basic Auth | 点对点
Remote Address Auth | 网络层认证 | IP 地址 | 内网信任、零信任内外网判断 | 网络级别

### 4.2 CAS 协议核心流程

CAS（Central Authentication Service）是本项目最核心的协议——需对接 7 套已建系统 + 3 套待建系统：

① 用户访问业务系统 → ② 业务系统检查无本地 Session → ③ 重定向到 CAS 认证中心 → ④ 用户在 CAS 中心完成认证 → ⑤ CAS 颁发 Service Ticket → ⑥ 业务系统验证 ST 并建立 Session

## 五、零信任登录技术解析

### 5.1 什么是零信任

零信任（Zero Trust）的核心理念是 "永不信任，始终验证"（Never Trust, Always Verify）。 传统安全模型假设"内网即安全"，而零信任认为无论用户在内网还是外网，每一次访问请求都需要经过身份认证和授权。

### 5.2 深信服 aTrust 零信任体系

需求中明确要求集成深信服零信任（aTrust），实现用户无感登录并判断内外网逻辑。深信服 aTrust 的核心能力：

核心能力 | 说明
--- | ---
流量身份化 | 不再以网络位置（内网 IP）决定访问权限，所有访问主体（人/设备/应用）都需要身份标识
动态自适应访问控制 | 根据用户身份、设备状态、地理位置、行为基线等多维度进行持续信任评估，动态调整访问权限
网络隐身 | 业务系统不对外暴露端口和 IP，只有通过零信任认证的用户才能建立连接
终端环境检测 | 检测终端设备安全状态（是否越狱、杀毒软件是否运行等），作为信任评估因子

### 5.3 本项目零信任登录流程

需求中"内网无需调用零信任认证，外网需要通过零信任认证"的内外网判断流程：

① App 发起登录请求 → ② 判断网络环境（内网/外网） → ③a 内网：直接走统一认证 → ③b 外网：先通过零信任认证 → ④ 统一身份认证 → ⑤ 颁发 Token，无感登录

### 5.4 零信任与 SSO 的关系

SSO 提供的是"一次登录、多系统通行"的便利，而零信任提供的是"持续验证、动态授权"的安全。 两者不是对立关系，而是互补关系：

- SSO 作为身份提供者（IdP），负责首次认证和令牌颁发
- 零信任网关作为策略执行点（PEP），在每次资源访问前验证令牌有效性和上下文安全
- 本项目中：深信服 aTrust 与统一认证中心对接，aTrust 可作为 CAS 的 Service Provider 消费认证

集成要点
深信服 aTrust 支持通过 CAS/OAuth2 协议与统一身份认证平台对接。App 端需集成 aTrust SDK， 实现"内外网自动判断 → 外网触发零信任认证 → 认证后无感访问业务系统"的完整流程。

## 六、密码代填方案

### 6.1 什么是密码代填

密码代填（Password Filling / Form-Fill SSO）是一种为不支持标准 SSO 协议的老旧系统 实现单点登录的技术手段。需求明确要求"以密码代填方式接入平台的老旧系统若干"。

原理：用户先通过统一认证中心登录 → 认证中心代管该用户的业务系统凭据 → 用户点击老旧系统时，认证中心自动导航到其登录页面 → 自动填充用户名和密码字段 → 自动提交表单。

### 6.2 代填登录流程

① 用户统一登录到 IAM → ② 点击老旧系统入口 → ③ IAM 代管凭据注入代理页面 → ④ 代理页自动填充表单并提交 → ⑤ 用户无感进入老旧系统

### 6.3 安全风险与缓解

风险 | 缓解措施
--- | ---
凭据在 IAM 中明文或弱加密存储 | 使用 AES-256 加密存储，密钥与数据分库存放
老旧系统本身不支持 MFA | 在 IAM 侧增加前置 MFA 校验，代填后再过一层
老旧系统登录页面结构变更 | 代填模板支持配置化（字段选择器、提交 URL），便于维护
代填过程可能被中间人攻击 | 代理页面与老旧系统间强制 HTTPS 通信

定位
密码代填应作为过渡方案。长期应推动老旧系统改造为标准 CAS/OAuth2 接入。 需求中乙方已承诺承担第三方系统改造费用，这为推进老旧系统升级提供了预算保障。

## 七、CAS 对接架构

### 7.1 对接规模

- 7 套已建系统：安全生产综合管控平台、承包商系统、设备完整性系统、EAM 设备管理系统、实时数据库系统、生产调度指挥系统、综合管理平台
- 3 套待建系统：OA 办公系统、华锦邮箱、档案管理系统（建成后免费接入）
- 若干老旧系统：非 CAS 认证，以密码代填方式接入

### 7.2 统一身份标识

以员工工号作为全系统唯一身份标识。这意味着：

- CAS 认证中心的用户表以工号为主键或唯一标识
- 各业务系统需支持通过工号映射本地用户
- ESB 同步组织架构时，工号是关联字段

### 7.3 对接模式分类

对接模式 | 适用系统 | 实现方式
--- | --- | ---
CAS 原生对接 | 支持 CAS Client 的系统 | 业务系统集成 CAS Client SDK，验证 Service Ticket
SAML/OAuth2 桥接 | 仅支持 SAML 或 OAuth 的系统 | IAM 作为协议桥接器，将 CAS 认证转换为目标协议
密码代填 | 不支持标准协议的老旧系统 | 表单自动填充 + 代理转发

## 八、多语言 SDK 体系

需求要求第三方接入支持多种语言和平台，涵盖以下范围：

SDK 类型 | 支持语言/平台 | 用途
--- | --- | ---
移动端 SDK | Android SDK、iOS SDK | 移动端 App 集成认证、扫码登录、生物识别
Java 系 | Java、JSP | Java Web 系统（Spring/Servlet）接入 CAS/OAuth
.NET 系 | ASP、C#、VB | .NET 业务系统接入统一认证
PHP | PHP | PHP 业务系统接入
C/C++ | C、C++ | 底层系统或嵌入式设备接入
标准化 API | RESTful API（语言无关） | 任意语言通过 HTTP 调用认证接口

实现建议
核心认证服务对外暴露标准 RESTful API，各语言 SDK 本质是对这些 API 的封装。 建议优先提供 Java、.NET、PHP 的官方 SDK（覆盖 90%+ 的业务系统）， C/C++ 等通过 REST API 直接调用，无需额外 SDK。

## 九、候选开源项目总览

基于需求中对协议支持（CAS + OAuth2 + SAML + 7 大协议）、多因子认证、多语言 SDK、国产化适配、10000+ 并发等要求， 筛选出以下 5 个主流开源 IAM 项目进行匹配度分析：

Keycloak
Red Hat 维护，市场占有率第一
Casdoor
Go 语言，Casbin 生态，轻量高效
MaxKey
国产 IAM，Apache-2.0，协议全覆盖
Apereo CAS
CAS 协议创始者，企业/高校标准
Apache Syncope
Apache 基金会，身份治理与生命周期

## 十、Keycloak 深度分析

维度 | 详情
--- | ---
维护方 | Red Hat → Linux Foundation（2024 年移交）
技术栈 | Java / Quarkus
协议支持 | OAuth 2.0、OIDC、SAML 2.0（CAS 需通过代理/插件）
多因子认证 | WebAuthn、TOTP、OTP、短信、邮件
用户联合 | LDAP、Active Directory、Kerberos、Social Login
扩展机制 | SPI（Service Provider Interface），高度可定制
社区规模 | 最大开源 IAM 社区，GitHub 22k+ Stars
安可适配 | Java 跨平台，可运行于麒麟 OS + 达梦数据库（需 JDBC 适配）

### 匹配度评估

需求项 | Keycloak 支持度 | 说明
--- | --- | ---
CAS 原生支持 | 部分 | 不原生支持 CAS Server，可作 CAS Client 或通过 SPI 扩展
SAML 2.0 | ✅ 原生 | 原生支持 SAML IdP 和 SP
OAuth 2.0 / OIDC | ✅ 原生 | 完整支持
多因子认证 | ✅ 原生 | WebAuthn、TOTP、OTP 等
密码代填 | ❌ 不支持 | 需额外部署网关（如 F5 APM）
多语言 SDK | 社区 | 官方不提供 SDK，社区有 Java/JS/Go 等
10000+ 并发 | 集群可达 | 单节点约 2000-3000 并发，需集群部署
移动端 SDK | 社区 | Android/iOS SDK 由社区维护

总结
Keycloak 是功能最完善的开源 IAM，但 CAS 非原生支持是其与本项目需求最大的 gap。 需要通过 SPI 扩展或部署 CAS 代理层（如 Apereo CAS 作为前置）来补齐。

## 十一、Casdoor 深度分析

维度 | 详情
--- | ---
维护方 | Casdoor 开源社区（Casbin 团队）
技术栈 | Go（前端 React）
协议支持 | OAuth 2.0、OIDC、SAML、CAS（原生）、LDAP、SCIM
多因子认证 | TOTP、短信、邮件、WebAuthn
权限引擎 | 内置 Casbin（支持 ACL、RBAC、ABAC）
第三方登录 | 微信、钉钉、GitHub、Google、GitHub 等 30+ 平台
社区规模 | GitHub 10k+ Stars
安可适配 | Go 编译为二进制，天然支持麒麟 OS；支持达梦数据库（需驱动适配）

### 匹配度评估

需求项 | Casdoor 支持度 | 说明
--- | --- | ---
CAS 原生支持 | ✅ 原生 | 原生 CAS IdP，直接兼容需求中的 7 套系统对接
SAML 2.0 | ✅ 原生 | 支持 SAML IdP
OAuth 2.0 / OIDC | ✅ 原生 | 完整支持
多因子认证 | ✅ 原生 | TOTP、短信、WebAuthn 等
密码代填 | ❌ 不支持 | 需自行开发代理填充模块
多语言 SDK | ✅ 官方 | 官方提供 Go、Java、Python、PHP、Node.js、C#、Swift 等 SDK
10000+ 并发 | ✅ 单节点可达 | Go 高并发特性，单节点可支撑 10000+ 并发
移动端 SDK | 部分 | Swift SDK 支持 iOS，Android 可用 REST API 集成
设备绑定 | 可配置 | 通过自定义字段和策略实现

总结
Casdoor 是协议覆盖最全的开源 IAM——CAS、OAuth2、SAML 全部原生支持。 Go 语言在性能和安可适配上具有天然优势。社区 SDK 丰富度也最高。 主要短板：密码代填和设备绑定需二次开发。

## 十二、MaxKey 深度分析

维度 | 详情
--- | ---
维护方 | Dromara 开源社区（国产 IAM 第一品牌）
技术栈 | Java / Spring Boot
协议支持 | CAS（原生）、OAuth 2.x / OIDC、SAML 2.0、JWT、SCIM 2.0
多因子认证 | 图片验证码、短信验证码、TOTP/HOTP（Google/Microsoft Authenticator）、二次密码
第三方登录 | 微信、钉钉、新浪微博
社区规模 | Gitee + GitHub，Dromara 社区活跃
安可适配 | Java 跨平台，天然支持麒麟 OS + 达梦数据库
最新本 | 4.1.6（2025-02），持续迭代中

### 匹配度评估

需求项 | MaxKey 支持度 | 说明
--- | --- | ---
CAS 原生支持 | ✅ 原生 | 原生 CAS Server，直接兼容
SAML 2.0 | ✅ 原生 | 支持 SAML IdP
OAuth 2.0 / OIDC | ✅ 原生 | 完整支持
多因子认证 | ✅ 原生 | 验证码、短信、TOTP 全覆盖
密码代填 | ❌ 不支持 | 需自行开发
多语言 SDK | Java 为主 | Java/CAS Client 完善，其他语言依赖 REST API
10000+ 并发 | 集群可达 | Java/Spring Boot，单节点性能中等，需集群部署
国产化亲和度 | ✅ 国产 | 国产开源，中文文档完善，Dromara 社区国内活跃
排他登录/设备绑定 | ✅ 原生 | 支持会话管理、并发登录控制

总结
MaxKey 是国产化适配最友好的选择——CAS/SAML/OAuth 全部原生支持，中文文档完善， 国内社区活跃。排他登录、会话管理等需求功能原生具备。 短板同样在于密码代填和多语言 SDK 丰富度不如 Casdoor。

## 十三、Apereo CAS 深度分析

维度 | 详情
--- | ---
维护方 | Apereo 基金会（原耶鲁大学开发）
技术栈 | Java / Spring Boot
协议支持 | CAS（创始者）、SAML 2.0、OAuth 2.0、OIDC、REST
多因子认证 | Duo、Google Authenticator、FIDO2/WebAuthn、Radius、短信
用户联合 | LDAP、Active Directory、JDBC、MongoDB、REST
社区规模 | 企业/高校广泛使用，社区成熟

### 匹配度评估

需求项 | Apereo CAS 支持度 | 说明
--- | --- | ---
CAS 原生支持 | ✅ 创始者 | 本身就是 CAS 协议的参考实现
SAML 2.0 / OAuth2 | ✅ 原生 | 完整支持
多因子认证 | ✅ 原生 | 自适应 MFA，支持多种因子
密码代填 | ❌ 不支持 | 需配合外部网关
用户管理 UI | 较弱 | 侧重认证，用户管理功能不如 Keycloak/Casdoor 完善
移动端 SDK | 无 | 无官方移动端 SDK
门户集成 | 无 | 纯认证引擎，无门户/待办聚合能力

总结
Apereo CAS 是 CAS 协议的标准和参考实现，认证能力极强，但它是一个纯认证引擎， 缺乏用户管理 UI、门户集成、移动端 SDK 等项目所需的全栈能力。 更适合作为认证引擎与其他平台（如 Apache Syncope）组合使用。

## 十四、Apache Syncope 深度分析

维度 | 详情
--- | ---
维护方 | Apache 软件基金会
技术栈 | Java / Spring
核心定位 | 身份治理与生命周期管理（非纯认证）
协议支持 | 可对接 CAS/Keycloak 作为认证层
核心能力 | 身份生命周期（入职/转岗/离职）、Provisioning、多系统同步、合规审计

### 匹配度评估

定位差异
Apache Syncope 的核心优势是身份治理和生命周期管理，而非认证引擎。 它可以与 Keycloak 或 Apereo CAS 组合使用：Syncope 管身份数据和同步，Keycloak/CAS 管认证和 SSO。 对于本项目来说，如果选型 Keycloak，可以后续用 Syncope 补充用户生命周期管理能力。

## 十五、开源项目匹配度总对比

### 15.1 需求-项目匹配矩阵

需求维度（权重） | Keycloak | Casdoor | MaxKey | Apereo CAS
--- | --- | --- | --- | ---
CAS 原生支持 必须 | 插件 | ✅ 原生 | ✅ 原生 | ✅ 创始者
SAML 2.0 必须 | ✅ | ✅ | ✅ | ✅
OAuth 2.0 / OIDC 必须 | ✅ | ✅ | ✅ | ✅
多因子认证 高 | ✅ 丰富 | ✅ | ✅ | ✅ 丰富
密码代填 高 | ❌ | ❌ | ❌ | ❌
多语言 SDK 高 | 社区 | ✅ 官方 8+ | Java 为主 | 无
移动端 SDK 中 | 社区 | Swift SDK | 无 | 无
排他登录/设备绑定 中 | ✅ | 可配置 | ✅ | 可配置
10000+ 并发 高 | 集群 | ✅ 单节点 | 集群 | 集群
安可适配 必须 | Java 可配 | ✅ Go 二进 | Java 可配 | Java 可配
国产化社区支持 中 | 国际 | 国际化 | ✅ 国产 | 国际

### 15.2 综合评分

项目 | 综合匹配度 | 优势 | 短板
--- | --- | --- | ---
Casdoor | 88% | CAS/SAML/OAuth 全原生、Go 高性能、官方 SDK 丰富、安可适配最佳 | 密码代填/设备绑定需二开、项目相对年轻
MaxKey | 82% | CAS/SAML/OAuth 全原生、国产化最友好、排他登录原生、中文文档完善 | 密码代填需二开、多语言 SDK 较少、社区规模偏小
Keycloak | 72% | 社区最大、功能最全、生态最成熟、SPI 扩展能力强 | CAS 非原生、Java 资源消耗大、移动端 SDK 非官方
Apereo CAS | 60% | CAS 协议创始者、认证能力最强、自适应 MFA 成熟 | 纯认证引擎、无用户管理 UI、无移动端 SDK、无门户能力

## 十六、选型建议

### 16.1 推荐方案：Casdoor + 自研密码代填模块

综合匹配度最高的是 Casdoor，理由如下：

- 协议全覆盖：CAS、SAML、OAuth2 全部原生支持，直接满足 7 套系统 CAS 对接 + 多协议兼容需求
- Go 语言优势：单节点即可支撑 10000+ 并发，减少集群部署复杂度；编译为二进制文件，安可适配最简单
- SDK 生态：官方提供 8+ 语言 SDK，覆盖需求中要求的 Java、PHP、C# 等
- Casbin 权限引擎：内置 RBAC/ABAC，可直接支撑门户平台的差异化权限展示需求
- 轻量部署：单二进制文件 + 数据库即可运行，运维成本低

### 16.2 需自研的部分

自研模块 | 原因 | 工作量评估
--- | --- | ---
密码代填引擎 | 所有候选项目均不原生支持 | 中（2-3 周）
设备绑定/排他登录增强 | 需结合需求细化策略配置 | 小（1 周）
Android/鸿蒙 SDK | Casdoor 有 REST API，移动端封装 | 中（2-3 周）
门户待办聚合 | 属于平台层功能，不在 IAM 范围内 | 大（独立模块）
深信服零信任集成 | 需对接 aTrust SDK | 小（1 周）
审计日志仪表盘 | Casdoor 有基础日志，需增强可视化 | 中（2 周）

### 16.3 备选方案

- 备选 A：MaxKey——如果团队更看重国产化属性和中文社区支持，MaxKey 是最佳备选。协议覆盖同样完整，排他登录等需求功能原生具备。
- 备选 B：Keycloak + Apereo CAS 组合——Keycloak 作为 IAM 核心，Apereo CAS 作为前置 CAS 认证层。适合已有 Keycloak 使用经验的团队，但架构复杂度更高。

### 16.4 架构蓝图

┌──────────────────────────────────────────────────────────────────┐ │ 推荐架构 │ │ │ │ ┌────────────────────────────────────────────────────────────┐ │ │ │ Casdoor（IAM 核心） │ │ │ │ ┌───────────┐ ┌───────────┐ ┌────────────────────────┐ │ │ │ │ │ CAS IdP │ │ SAML IdP │ │ OAuth 2.0 / OIDC │ │ │ │ │ └───────────┘ └───────────┘ └────────────────────────┘ │ │ │ │ ┌───────────┐ ┌───────────┐ ┌────────────────────────┐ │ │ │ │ │ MFA 引擎 │ │ Casbin │ │ 用户/组织管理 │ │ │ │ │ │ (TOTP/ │ │ (RBAC/ │ │ + ESB 同步 │ │ │ │ │ │ 短信/ │ │ ABAC) │ │ │ │ │ │ │ │ WebAuthn)│ └───────────┘ └────────────────────────┘ │ │ │ │ └───────────┘ │ │ │ └────────────────────────────────────────────────────────────┘ │ │ ▲ │ │ ┌────────────────────┼────────────────────┐ │ │ │ │ │ │ │ ┌──────▼──────┐ ┌───────▼───────┐ ┌───────▼───────┐ │ │ │ 密码代填引擎 │ │ 深信服 aTrust │ │ 自研 SDK 层 │ │ │ │ (Form-Fill │ │ (零信任网关) │ │ Android/鸿蒙 │ │ │ │ 代理模块) │ │ │ │ Java/PHP/C# │ │ │ └─────────────┘ └───────────────┘ └───────────────┘ │ │ │ │ ┌────────────────────────────────────────────────────────────┐ │ │ │ 数据层 │ │ │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ │ │ 达梦数据库 │ │ Redis 缓存 │ │ │ │ │ │ (业务 + 日志 │ │ (Session/ │ │ │ │ │ │ 分库分表) │ │ Token) │ │ │ │ │ └──────────────┘ └──────────────┘ │ │ │ └────────────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────┘