Open-Bank 开放银行平台

📌 业务逻辑详述

1. 请求接收与路由匹配：API Gateway 监听 8188 端口，接收所有外部 HTTPS/HTTP 请求。请求到达后，Spring Cloud Gateway 根据 URL 路径匹配预配置的路由规则（RouteDefinition）。路由配置可从数据库动态加载（通过 RouteService 定时刷新），支持谓词匹配（Path/Method/Header/Query）和过滤器链。[B级: FopGatewayController.java]
2. 认证授权（AuthGlobalFilter, order=-100）：网关的第一道防线，根据请求特征自动识别三种认证模式：
     • OAuth2 模式：检测 Authorization: Bearer {token} 头，调用 OAuth2 Server 校验 token 有效性、过期时间、scope 权限范围
     • SDK 模式：检测 appKey/timestamp/sign 参数，从数据库查询 appSecret 后验签（HMAC-SHA256），校验时间戳防重放攻击（15分钟窗口）
     • H5 模式：移动端 H5 场景的简易 Token 认证（降低集成复杂度）
   认证失败直接返回 401/403 错误，不继续后续处理。[B级: AuthGlobalFilter.java]
3. 限流熔断（RateLimitGlobalFilter, order=-50）：通过 Alibaba Sentinel 实现多维度限流：   • 按 AppKey 维度：限制单个应用的 QPS（如 1000 次/秒）   • 按 API 维度：限制单个接口的并发数   • 按 IP 维度：限制单 IP 的请求频率（防爬/防 DDOS） 触发限流返回 429 Too Many Requests，触发熔断返回降级响应。[B级: RateLimitGlobalFilter.java]
4. IP 黑名单检查（IpBlacklistFilter, order=0）：查询 Redis 中的 IP 黑名单缓存（定时从数据库加载），若请求 IP 在黑名单中则直接拒绝返回 403 Forbidden。[B级: IpBlacklistFilter.java]
5. 交易日志记录（TranLogFilter, order=100）：在请求处理前后记录完整的交易日志，包括：请求头（Authorization/X-Forwarded-For/User-Agent）、请求体、请求时间戳、目标 API 路径、AppKey、开发者 ID、响应状态码、响应体、耗时毫秒数。日志异步写入 MySQL 和 Elasticsearch，用于审计追溯和问题排查。[B级: TranLogFilter.java ~400行]
6. 后端服务调用：认证和限流通过后，根据路由配置将请求转发到后端服务：   • 若目标是 fop-parent 的 Dubbo Service → 通过 DubboInvoke 封装进行 RPC 调用，传入 DefaultDubboModel（包含 appId/tableName/sqlId/parameterList 等）   • 若目标是 ijep-clouds 微服务 → 通过 HTTP REST 调用[B级: FopGatewayController.java]
7. 响应返回：后端服务返回 BusinessOutput 或标准 JSON 响应，网关统一封装为标准格式返回给调用方：

{
  "code": "000000",
  "message": "success",
  "data": { ... },
  "traceId": "xxxxxxxx",
  "timestamp": 1716873600000
}

📌 业务逻辑详述

1. API 注册（创建草稿）：API 提供者（通常是银行内部技术人员）在管理后台录入 API 基本信息：
     • 基本信息：API 名称、英文名称、所属分类、描述
     • 技术信息：请求路径（apiPath）、HTTP 方法（GET/POST/PUT/DELETE）、Content-Type、版本号（version，默认 v1.0）
     • 请求参数：定义请求头（Headers）、路径参数（Path Variables）、查询参数（Query Params）、请求体（Body JSON Schema）
     • 响应定义：响应码（成功/各错误码）、响应体结构（JSON Schema）、示例值
     • 其他：调用示例代码（Java/Python/JavaScript/C# 等）、标签/分类、是否需要签名
   系统自动赋值 state=00（草稿）、创建时间、创建人。[B级: FopApiBookPo.java ~350行]
2. 提交审核：API 提供者确认信息无误后点击"提交审核"，state 变更为 01（待审核）。系统通知运营管理员进行审核。[D级: 对标通用 API 管理流程]
3. 审核（通过/驳回）：运营管理员在管理后台查看待审核 API 列表，逐个审核：
     • 审核要点：API 命名规范、路径唯一性（同版本内 apiPath 不可重复）、参数定义完整性、响应示例正确性、安全合规性（是否包含敏感字段、是否需要额外鉴权）
     • 审核通过：state → 02（审核通过），记录审核人/审核时间
     • 审核驳回：state → 03（审核驳回），必须填写驳回原因（如"路径不规范"/"参数缺失示例值"/"响应码不完整"），系统通知提供者修改
   ⚠️ 具体的审核校验规则代码层面未深入分析，以上为基于行业通用做法的推断。[D级]
4. 发布上线：审核通过的 API 由运营管理员（或 API 提供者有权限时自行）执行发布操作，state → 04（已发布），记录发布时间/发布人。发布后 API 在开放门户前台对已授权的开发者可见并可调用。[D级]
5. 版本管理：当 API 需要变更（新增参数/修改响应结构/变更业务逻辑）时，不允许直接修改已发布的版本，而是创建新版本（version 自增，如 v1.0 → v1.1 → v2.0）。新版本重新走"草稿→审核→发布"流程。旧版本可在过渡期并行运行一段时间后再下线。[B级: FopApiBookPo.version 字段]
6. 下线归档：不再使用的 API 执行下线操作，state → 05（已下线）。下线后的 API 不再对外提供服务，已有调用方会收到"API 已下线"的错误提示。下线的 API 数据保留归档用于历史审计。[D级]

📌 业务逻辑详述

1. 创建应用：开发者在 openportal 开放门户或 jepWeb 管理后台创建新应用，填写：   • 应用名称（如"XX 支付小程序"）   • 应用类型（Web/App/H5/Server-to-Server）  &td;• 应用描述（用途说明）   • 回调地址（OAuth2 授权回调 URL，用于接收授权码）   • 应用图标/Logo（上传到 FastDFS）   • 联系人和联系电话 创建后 state=00（待提交），开发者可随时编辑。[B级: FopAppBookPo.java]
2. 提交审核：开发者确认应用信息无误后提交审核，state→01（待审核）。系统通知运营管理员。
3. 运营审核：运营管理员审核应用：   • 审核要点：应用名称是否规范（不得包含违禁词/银行品牌词）、回调地址是否合法（不得是内网 IP/localhost）、应用类型与回调地址是否匹配、开发者资质是否满足（实名认证状态）   • 通过：state→02（审核通过），系统自动生成：     - appKey（应用标识，公开，用于标识调用方身份）     - appSecret（应用密钥，仅显示一次！用于 SDK 签名计算 HMAC） ⚠️ appSecret 安全策略：首次生成后明文展示一次，之后无法再次查看（只能重置）。重置后旧 secret 立即失效。   • 驳回：state→05（驳回），需填写驳回原因[B级: FopAppBookPo.java + TokenPo.java]
4. 配置 API 权限：审核通过后，开发者可为应用申请调用特定 API 的权限（Scope）。运营管理员也可批量授权常用 API 权限。权限粒度：   • API 级别：允许调用哪些 API（如 user.info / payment.create / account.query）   • 操作级别：对该 API 可执行哪些操作（读/写/全部） 权限变更需要重新审核（防止滥用）[D级: RBAC 权限模型推断]
5. 调用 API：应用获得 appKey/appSecret 并被授权 API Scope 后，即可开始调用：   1. 使用 appSecret + 时间戳 + 请求内容计算 sign 签名   2. 将 appKey/timestamp/sign 附加到请求头或参数   3. 发送请求到 API Gateway :8188   4. Gateway 验签通过后检查 appKey 对应的 app 是否正常（state=03）、是否有目标 API 的 scope 权限   5. 全部通过后转发到后端服务执行   6. 返回结果[B级: SdkAuthController + AuthGlobalFilter]
6. 应用管理：开发者可在控制台查看：   • 应用基本信息和 appKey   • 已授权的 API 列表和 Scope   • 调用统计（今日/本周/本月调用量、成功率、平均响应时间）   • 计费信息（调用量套餐/费用明细/账单） • 重置 appSecret（立即生效，旧 Secret 失效，需同步更新所有调用方配置）⚠️

📌 业务逻辑详述

1. 注册：开发者在 openportal 开放门户首页点击"注册"，填写：   • 手机号或邮箱（作为登录账号）   • 登录密码（前端 AES 加密传输）   • 确认密码   • 图形验证码（Kaptcha 生成，防机器人注册）   • 用户协议勾选（必须同意《开放平台服务协议》） 提交后 Portal 后端 ShiroService 通过 Dubbo 调用后端创建账户。[B级: fop-portal RequestController.regist()]
2. 登录：   • Portal 登录：用户名 + 密码（AES 加密）→ Shiro OAuth2Filter 拦截 → OAuth2Realm 验证 → Redis Session 存储（30分钟超时）→ 设置 Cookie   • 前台 AJAX 登录：Vue 前端 Axios POST /login → 后端校验 → 返回 JWT Token → Vuex 存储 → Axios 拦截器自动附加 Token 到后续请求 Header[B级: ShiroConfig + OAuth2Realm]
3. 实名认证：注册后需完成实名认证才能创建应用和调用生产环境 API（沙箱环境可能不需要）：   • 个人开发者：真实姓名 + 身份证号 + 身份证正反面照片（上传 FastDFS）   • 企业开发者：企业名称 + 统一社会信用代码 + 营业执照照片 + 法人信息 ⚠️ 具体的实名认证对接方式（人工审核/三方自动核验？）代码层面未明确发现，需进一步确认。[D级]
4. 权限管理：基于 RBAC 模型：   • 默认角色：普通开发者（可浏览 API 市场、查看文档、使用沙箱）   • 高级角色：认证开发者（可创建应用、调用生产 API）— 需实名认证   • 特殊角色：合作机构（享有更高的调用量限额和优先支持）[B级: RBAC 权限模型]

1. 产品打包：运营管理员将多个相关的 API 打包成一个"金融产品"。例如：   • "支付产品包" = 创建订单 API + 支付结果查询 API + 退款 API + 对账单下载 API   • "账户产品包" = 查余额 API + 交易明细查询 API + 开户 API 产品包含：名称、描述、包含的 API 列表、定价策略、适用对象（个人/企业开发者）、SLA 承诺[B级: FopProductBookPo.java]
2. 定价模型（推断）：   • 免费套餐：每月 N 次免费调用量（吸引开发者试用）   • 按量付费：超出免费额度后按次收费（如 0.01 元/次）   • 包月套餐固定月费，包含一定调用量（如 99 元/月含 10000 次） ⚠️ 具体的计费规则代码层面未深入分析，以上为基于行业通用模式的推断。[E级]
3. 销售统计：产品维度的销售数据统计（订阅开发者数量/总调用量/总收入）[B级: 统计相关代码]