系統架構與資料流
本頁說明
講什麼：系統邊界與技術棧、32 個微服務的分層關係、資料庫架構與同步管線、服務間通訊協議與延遲分析、一筆入金/出金從發起到完成經過哪些服務和資料表、銀行流水採集頻率、請求鏈路追蹤示例、監控與告警體系，以及常見延遲瓶頸與排查思路 適合誰：需要理解系統技術全貌的產品經理和運營人員 前置閱讀：新人導讀預計閱讀：12 分鐘 負責人：出入金產品團隊
核心要點：系統由 32 個微服務組成，按 PHP 業務邏輯層、Go/Python 銀行對接層、Python SBA 編排層三級分工——理解分層關係是定位問題和評估變更影響的關鍵。
技術棧概覽
| 層級 | 技術 | 組件 | PM 關注點 |
|---|---|---|---|
| 業務邏輯 | PHP/Lumen 5.5 | 入金(deposit/)、出金(withdraw/)、銀行卡(bankcard_service/)、現金(cash/) | 核心業務 API，延遲敏感——直接影響 App 響應速度 |
| 銀行接入 | Go + Python 混合 | Go：中銀流水、廣發FPS、渣打、黑白名單、天星網關；Python：SBA編排、匯豐、工銀、招行、民生 | 銀行通道多語言異構——排查時需找對語言棧的日誌 |
| 通訊協議 | Protobuf RPC + HTTP REST | SRPC（內部同步）、HTTP（CRM/外部）、SM2 Socket（招行/民生） | SRPC 超時 → 單筆入金/出金卡住；HTTP 超時 → CRM 操作失敗 |
| 銀行協議 | B2E XML / MT910 / SFTP+GPG / SM2 加密 / REST API | 每家銀行一種協議 | 不同協議決定了流水獲取速度和自動化程度 |
| 儲存 | MySQL（分表）+ Elasticsearch（Canal 同步）+ Redis | 主庫分 100 表、ES 全文搜尋、Redis 快取+鎖 | CRM 搜尋走 ES（秒級延遲），不直接查資料庫 |
| 訊息 | Redis 事件佇列 + RabbitMQ | 內部非同步事件 + 跨服務解耦 | 佇列積壓 → 批量入金/出金延遲 |
32 個微服務分類
完整服務清單
核心業務（4 個）
| 服務 | 語言 | 端口 | 職責 | 對外介面 |
|---|---|---|---|---|
deposit/ | PHP | 20001 | 入金申請、銀行流水、匹配、審批、在途資金、對帳 | SRPC + HTTP REST |
withdraw/ | PHP | 20002 | 出金申請、三步審批（Audit→Confirm→Remittance）、銀行通道 | SRPC + HTTP REST |
cash/ | PHP | 20003 | 現金服務 API 和批處理 | HTTP REST |
bankcard_service/ | PHP | 20005 | 銀行卡全生命週期管理（綁定/驗證/解綁） | HTTP REST |
銀行接入層（13 個）
| 服務 | 語言 | 銀行 | 職責 | 通訊方式 | 呼叫方向 |
|---|---|---|---|---|---|
bochk_flow_go/ | Go | 中銀 | B2E 協議解析、流水轉換 | B2E XML | moomoo → 銀行（主動拉取） |
bochk_deposit_mgr/ | Python | 中銀 | 入金編排管理 | SRPC | 內部呼叫 |
bochk_fts_mgr/ | Python | 中銀 | FTS（匯款）管理 | SRPC | 內部呼叫 |
bochk_relay/ | Python | 中銀 | 請求轉發代理 | HTTP | 內部轉發 |
hsbc_bank_flow_service/ | Python | 匯豐 | MT910 流水解析、SFTP 拉取、GPG 加密 | SFTP+GPG | 銀行 → moomoo（推送+拉取） |
hsbc_edda_report/ | Python | 匯豐 | eDDA 報表下載 | SFTP | moomoo → 銀行（定時拉取） |
sba_hsbc_eddi/ | Python | 匯豐 | eDDA/eDDI 入金代扣整合 | REST API | moomoo → 銀行（發起+輪詢） |
sba_hase_eddi/ | Python | 恒生 | eDDA/eDDI 入金代扣整合 | REST API | moomoo → 銀行（發起+輪詢） |
scb_service/ | Go | 渣打 | FPS RPC 介面 | SRPC | moomoo → 銀行 |
cgb_fps_service/ | Go | 廣發 | FPS 即時轉帳 | SM2 加密 | moomoo → 銀行 |
icbc_be_relay/ | Python | 工銀 | 銀企互聯中繼 | RSA 驗簽 | moomoo → 銀行 |
cmb_stock_trans/ | Python | 招行 | 銀證轉賬（Socket 二進位雙向鏈路） | SM2 Socket | 雙向即時 |
ms_stock_bank_transaction/ | Python | 民生 | 銀證轉賬 | SM2 Socket | 雙向即時 |
SBA 編排層（3 個）
| 服務 | 語言 | 職責 | 狀態數 |
|---|---|---|---|
sba_deposit_system/ | Python | 入金編排：建立→審核→風控變更→入帳，支援 6 種入金模式 | 6 |
sba_cash_withdraw_system/ | Python | 出金編排：凍結→扣款→轉帳→釋放，支援 4 階段 17 種狀態 | 17 |
sba_fund_withdraw/ | Python | 基金出金：貨幣基金贖回→出金一鍵編排 | — |
風控（3 個）
| 服務 | 語言 | 職責 | 運營關聯 |
|---|---|---|---|
hk-deposit-blacklist-go/ | Go | 入金黑名單（批量增刪查） | 命中時入金被攔截，Procedure → manual_confirm |
hk-deposit-whitelist-go/ | Go | 入金白名單 | 白名單內使用者走快速通道，跳過人工審核 |
hk-withdraw-blacklist-go/ | Go | 出金黑名單 | 命中時出金進入人工審核佇列 |
其他（9 個）
| 服務 | 語言 | 職責 | 狀態 |
|---|---|---|---|
bank-card/ | PHP | 銀行卡基礎 API | 遺留服務，逐步遷移到 bankcard_service |
cash_service/ | PHP | 現金服務擴展 | 活躍 |
refund/ | PHP | 退款處理 | 活躍 |
airstar_service/ | Go | 天星銀行支付網關（Mandate 授權/入金/出金） | 活躍——天星 BST 的核心 |
sync_bst_data_helper/ | Python | 招行異常流水恢復 | 補償服務——招行 Socket 斷連時使用 |
tools-pic-upload/ | Go | 憑證圖片上傳 | 活躍 |
bank_conn_doc/ | - | 銀行對接規範文件（匯豐/中銀/恒生/工銀/EWB/浦發） | 文件倉庫 |
procedure_system/ | Python | 流程編排系統（SBA 核心框架） | 活躍——SBA 的底層引擎 |
資料庫架構
三個核心資料庫
| 資料庫 | 歸屬服務 | 核心表 | 分表策略 | 預計資料量 |
|---|---|---|---|---|
| 主庫（cash_deposit / cash_withdraw） | deposit/、withdraw/、cash/、refund/ | applys、flows、matches、tasks、queue | applys 按 uid 取模分 100 表；flows 按銀行類型+月份分表 | 百萬級/月 |
| web_account | bankcard_service/ | bank_card、bank_info、bank_card_certificate、bank_card_asb_bst、bank_card_edda | 不分表 | 十萬級 |
| SBA Procedure 庫 | procedure_system/、sba_*_system/ | proc_info、proc_cash_deposit、proc_cash_withdraw、flow | 不分表 | 百萬級/月 |
三個庫物理隔離，服務之間透過 RPC 呼叫而非直接跨庫查詢。
分表對運營的影響
入金申請表 applys 按使用者 ID 分了 100 張表（applys_00 到 applys_99）。CRM 搜尋不受影響（走 ES），但如果需要直接查庫排查，需要先算出使用者 ID 對應的表後綴：uid % 100。
銀行流水表 flows 按銀行+月份分表（如 flows_bochk_202604），跨月查詢需要指定正確的月份。
出金任務表 tasks 不分表，但資料量大時按 created_at + status 建索引查詢。
SBA Procedure 表 proc_info 不分表，透過 id 或 nn_uid + biz_type 查詢。
資料同步管線（Canal CDC → Elasticsearch）
CRM 運營後台支援按卡號、使用者名稱、銀行流水號等做模糊搜尋——這不是直接查資料庫，而是查 Elasticsearch。資料透過 Canal（阿里開源的 MySQL Binlog 訂閱工具）即時同步：
PM 視角：CRM 搜尋結果幾乎即時（秒級延遲）。如果搜尋結果「找不到」，不一定是資料不存在——可能是 Canal 同步延遲，等幾秒再搜通常就有了。
Canal 同步的實體
| 實體 | 源表 | ES 索引用途 | 支援的搜尋欄位 | CRM 搜尋入口 |
|---|---|---|---|---|
ApplySync | 入金申請 applys | CRM 入金列表搜尋 | uid, 銀行卡號, 金額, 狀態, 建立時間 | 入金管理 → 搜尋框 |
FlowSync | 銀行流水 flows | CRM 流水搜尋、匹配排查 | 流水號, 金額, 銀行, 幣種, 入帳時間 | 流水管理 → 搜尋框 |
TaskSync | 出金任務 tasks | CRM 出金列表搜尋 | uid, 目標卡號, 金額, 狀態, 建立時間 | 出金管理 → 搜尋框 |
FileSync | 憑證檔案 | CRM 憑證搜尋 | 檔名, 上傳時間, 關聯 uid | 憑證管理 |
DepositSbaListSync | 入金 SBA 關聯 | 入金-Procedure 關聯查詢 | apply_id, procedure_id | 入金詳情 → SBA 關聯 |
ApplyAdditionSync | 入金附加資訊 | 補充搜尋欄位 | 備註, 附加標記 | 入金詳情 → 附加資訊 |
搜尋不到記錄時的排查順序：
- 等 5-10 秒重新搜尋（Canal 同步延遲）
- 換搜尋條件試（如用 uid 代替卡號）
- 檢查 Canal Consumer 日誌是否有報錯
- 直接查資料庫確認資料是否存在
服務間通訊方式
| 協議 | 使用場景 | 典型呼叫 | 特點 | PM 意義 |
|---|---|---|---|---|
| SRPC（Protobuf RPC） | 核心服務 ↔ SBA / 風控 | deposit/ 呼叫 CashDepositCreate | 同步、強型別、毫秒級 | 超時直接影響使用者等待時間 |
| HTTP REST | 銀行卡服務 / 天星網關 / CRM | CRM 呼叫 /bank_card/get_list | 標準 Web API | 易於監控和除錯 |
| SM2 Socket | 招行/民生銀證 | 二進位雙向鏈路 | 長連線、即時推送 | 銀行側結果秒級到達 |
| REST API（輪詢） | 天星銀證 / 匯豐恒生 eDDA | AsbBstCreateResultJob 輪詢 | 需主動查詢 | 使用者等待時間更長 |
| RabbitMQ | 交易通知→風控；跨服務非同步 | RmqReportMsg 觸發風控更新 | 非同步解耦 | 佇列積壓影響批量處理 |
通訊方式對延遲的影響
| 場景 | 通訊鏈路 | 典型延遲 | 延遲原因 | 影響範圍 |
|---|---|---|---|---|
| BST 入金（招行/民生） | SM2 Socket 即時推送 | 秒級 | 銀行主動推送結果 | 單筆 |
| BST 入金（天星） | REST API + 輪詢 | 秒~分鐘級 | 需輪詢最多 60 次 | 單筆 |
| BST 出金（天星） | REST API + 輪詢 | 秒~分鐘級 | 需輪詢最多 10 次 | 單筆 |
| eDDA 代扣入金 | REST API + 輪詢 | T+0~T+1 | 銀行非同步處理 | 單筆 |
| 普通入金匹配 | 定時任務 | 3 分鐘一輪 | 匹配引擎定時掃描 | 批量 |
| 網銀出金 | 人工操作 | 小時~天級 | 依賴運營在銀行網銀轉帳 | 單筆 |
| CRM 搜尋 | Canal CDC → ES | 秒級 | Binlog 同步延遲 | CRM |
PM 視角：如果一筆入金延遲異常，瓶頸可能在 SRPC 同步呼叫（如 SBA 建立 Procedure 超時）或 Canal 非同步佇列積壓。SRPC 問題影響單筆，佇列積壓影響批量。
入金資料流：一筆錢如何到帳
普通入金（使用者視角）
| 步驟 | 使用者操作 | 使用者感知 | 預計耗時 |
|---|---|---|---|
| 1 | 在 App 選擇銀行卡，獲取入金帳戶資訊 | 看到 moomoo 收款帳號 | 即時 |
| 2 | 在銀行 App/網銀轉帳到 moomoo 帳戶 | 銀行顯示轉帳成功 | 1-5 分鐘 |
| 3 | 等待系統匹配入帳 | App 顯示「入金處理中」 | 3 分鐘~數小時 |
| 4 | 入金完成 | App 餘額增加，收到通知 | — |
系統視角
入金資料經過的核心表
| 階段 | 表名 | 分表規則 | 說明 | 運營查看位置 |
|---|---|---|---|---|
| 1. 使用者申請 | applys_{00-99} | uid % 100 | 一條 = 一筆入金申請 | CRM → 入金管理 |
| 2. 銀行流水 | flows_{bankType}_{YYYYMM} | 銀行類型 + 月份 | 一條 = 一筆銀行流水 | CRM → 流水管理 |
| 3. 匹配 | matches_{shard} | — | Flow 與 Apply 的關聯記錄 | CRM → 匹配記錄 |
| 4. 入金任務 | deposits_{shard} | — | 已匹配的入金任務 | CRM → 入金列表 |
| 5. 異常 | abnormal_deposits | 不分表 | 異常流水單獨追蹤 | CRM → 異常入金 |
| 6. SBA | proc_info + proc_cash_deposit | 不分表 | Procedure 追蹤記錄 | CRM → SBA 管理 |
入金 Procedure 的完整狀態機和欄位說明 → SBA 資金編排 § 入金 Procedure 狀態機
出金資料流：一筆錢如何匯出
出金（使用者視角）
| 步驟 | 使用者操作 | 使用者感知 | 預計耗時 |
|---|---|---|---|
| 1 | 在 App 選擇出金銀行卡和金額 | — | 即時 |
| 2 | 確認出金 | 可用餘額減少（凍結） | 即時 |
| 3 | 等待系統處理 | App 顯示「出金處理中」 | BST 秒級 / 網銀 小時級 |
| 4 | 出金完成 | 收到出金成功通知 | — |
| 5 | 銀行到帳 | 銀行卡收到資金 | 1-3 個工作日 |
系統視角
出金資料經過的核心表
| 階段 | 表名 | 說明 | 運營查看位置 |
|---|---|---|---|
| 1. 建立任務 | tasks | 出金任務核心記錄 | CRM → 出金管理 |
| 2. 操作流水 | flows | 每步審批的操作日誌（staff_id, action, step） | CRM → 操作記錄 |
| 3. 事件佇列 | queue | 非同步事件（銀證同步、高風險檢查等） | 系統內部 |
| 4. SBA 追蹤 | sba_list | 出金 Task ↔ SBA Procedure 關聯 | CRM → SBA 狀態 |
| 5. 銀證設定 | auto_settings | 按銀行×幣種的自動審批餘額/上限配置 | CRM → 銀證設定 |
| 6. 銀行流水 | cmb_list / ms_list | 招行/民生銀行側發起的出金記錄 | CRM → 銀證出金 |
出金 Procedure 的完整狀態機（17 個狀態）和凍結-轉帳-釋放模式 → SBA 資金編排 § 出金 Procedure 狀態機
銀行流水採集頻率
不同銀行的流水資料獲取方式和頻率差異很大——這直接影響入金到帳速度：
| 銀行 | 採集方式 | 頻率 | 說明 | 入金到帳預期 | 自動化程度 |
|---|---|---|---|---|---|
| 中銀 BOCHK | B2E 主動拉取 | 每日 3 次（06:00/07:00/08:00）+ 2 小時轉換 | TodayActivity→AcctStatement→AcctActivity | T+0（當日） | 半自動 |
| 匯豐 HSBC | MT910 即時推送 + SFTP 拉取 | 即時 + 批量兜底 | Transaction Reference Number 去重 | 分鐘級 | 全自動 |
| 工銀 ICBC | 銀企互聯主動拉取 | 每日即時拉取 | 按日期區間查詢，RSA 驗簽 | T+0 | 半自動 |
| 招行 CMB | 雙���鏈路被動接收 | 事件驅動（即時） | 銀行發起時即時接收 | 秒級 | 全自動 |
| 民生 MS | 雙向鏈路被動接收 | 事件驅動（即時） | 銀行發起時即時接收 | 秒級 | 全自動 |
| 天星 ASB | REST API 輪詢 | 輪詢（最多 60 次） | 入金建立後輪詢結果 | 秒~分鐘級 | 全自動 |
| 恒生 HASE | eDDA 代扣 + REST API | 代扣發起後輪詢 | 透過 sba_hase_eddi 處理 | T+0~T+1 | 全自動 |
| EWB | CSV + BAI2 檔案 | 按需上傳 | CSV 去重 + BAI2 補充名稱 | 人工處理 | 手動 |
| 其他銀行 | 入金匹配任務掃描 | 每 3 分鐘 | CCB Asia、DBS、眾安等 | 3 分鐘~小時級 | 半自動 |
流水獲取延遲 ≠ 到帳延遲
流水獲取只是入金流程的第一步。之後還需要匹配引擎比對（每 3 分鐘一輪）、SBA 建立 Procedure、風控變更等步驟。BST 銀證通道跳過了匹配步驟（直接建立 Procedure），所以到帳最快。
各環節延遲疊加估算：
| 入金通道 | 流水獲取 | 匹配 | SBA + 風控 | 總計 |
|---|---|---|---|---|
| BST（招行/民生） | 秒級 | 跳過 | 毫秒級 | 秒級 |
| BST（天星） | 秒~3 分鐘 | 跳過 | 毫秒級 | 秒~3 分鐘 |
| eDDA（恒生/匯豐） | T+0~T+1 | 跳過 | 毫秒級 | T+0~T+1 |
| 普通入金（匯豐） | 分鐘級 | 3 分鐘 | 毫秒級 | 3~10 分鐘 |
| 普通入金（中銀） | 當日 3 次 | 3 分鐘 | 毫秒級 | 小時級 |
| 普通入金（其他） | 3 分鐘 | 3 分鐘 | 毫秒級 | 6~30 分鐘 |
請求鏈路追蹤
入金鏈路示例：一筆招行 BST 入金
使用者在招行App發起銀證入金 10,000 HKD
↓
① cmb_stock_trans 收到 SM2 Socket 推送（< 1秒）
→ 解密報文，提取：卡號、金額、幣種、市場
↓
② deposit/ 收到入金通知（SRPC，< 100ms）
→ 建立 Apply 記錄（applys_xx 表）
→ 黑名單/白名單檢查（並行 RPC）
↓
③ sba_deposit_system/ 建立 Procedure（SRPC，< 100ms）
→ proc_info + proc_cash_deposit 寫入
→ 自動審核（deposit_type = TRANS_AUTO）
↓
④ 風控系統 資產變更（SRPC，< 200ms）
→ 餘額增加 10,000 HKD
↓
⑤ Procedure → end_ok(deposit_ok)（< 50ms）
→ 回寫 Apply 狀態 → DONE
→ Canal 同步到 ES（< 3秒）
↓
⑥ 使用者在 App 看到餘額增加
總耗時：約 1-3 秒出金鏈路示例：一筆網銀出金
使用者在 moomoo App 發起出金 50,000 HKD 到恒生銀行
↓
① withdraw/ 建立 Task（< 100ms）
→ 黑名單檢查
→ 銀行卡驗證（bankcard_service/ HTTP）
→ Step 1 Audit: 自動通過（普通範本）
→ Step 2 Confirm: 參數確認
→ Step 3 Remittance: 建立 SBA Procedure
↓
② sba_cash_withdraw_system/ 凍結資金（< 200ms）
→ 風控系統凍結 50,000 HKD
→ Procedure: new(freeze) → new(waiting) → new(blank)
↓
③ 扣款（< 200ms）
→ 風控系統正式扣減 50,000 HKD
→ Procedure: pending(deduct_done)
↓
④ 進入人工轉帳（恒生走企業網銀）
→ Procedure: pending(transfer_manual)
→ **等待運營在恒生企業網銀完成轉帳**
↓
⑤ 運營在銀行網銀轉帳完成後（小時~天級）
→ CRM 點擊「確認轉帳完成」
→ SetManualTransferDone
→ Procedure: end_ok(transfer_done)
↓
⑥ 使用者 1-3 個工作日後收到資金
總耗時：數小時~1 個工作日（取決於運營處理速度）監控與告警體系
核心監控指標
| 指標 | 監控方式 | 告警閾值 | 影響 |
|---|---|---|---|
| 入金到帳時間 | SBA Procedure 建立到 end_ok 的時間差 | BST > 5 分鐘 / 普通 > 1 小時 | 使用者體驗 |
| 出金處理時間 | Task 建立到 end_ok 的時間差 | BST > 10 分鐘 / 網銀 > 24 小時 | 使用者體驗 |
| 匹配引擎執行 | 定時任務執行日誌 | 超過 6 分鐘未執行 | 批量入金延遲 |
| Canal 同步延遲 | ES 最新記錄時間 vs MySQL 最新記錄時間 | 延遲 > 30 秒 | CRM 搜尋不到最新資料 |
| SM2 Socket 連線 | 心跳檢測（招行/民生） | 心跳超時 > 60 秒 | 銀證通道不可用 |
| 輪詢任務超時 | Job retry_count | 入金 > 60 / 出金 > 10 | 天星 BST 交易卡住 |
| 凍結未釋放 | Procedure 在 pending(unfreeze) 停留時間 | > 5 分鐘 | 使用者資金卡住 |
| 補回失敗 | Procedure 在 pending(return) 停留時間 | > 5 分鐘 | 使用者資金「消失」 |
告警通知方式
| 級別 | 告警方式 | 回應時效 | 典型場景 |
|---|---|---|---|
| P0 嚴重 | 飛書群 + 電話 | 15 分鐘內 | 凍結未釋放、補回失敗、SM2 Socket 斷連 |
| P1 重要 | 飛書群 | 30 分鐘內 | 輪詢超時、匹配引擎停止、Canal 同步長時間延遲 |
| P2 一般 | 飛書群 | 2 小時內 | 單筆入金/出金延遲超預期 |
詳細告警規則配置、定時任務清單和 Dashboard 地址 → 定時任務與監控
常見延遲瓶頸與排查
當入金或出金出現延遲時，問題通常出在以下環節：
| # | 瓶頸環節 | 表現 | 排查方式 | 影響範圍 | 嚴重程度 |
|---|---|---|---|---|---|
| 1 | 銀行流水未到 | Apply 已建立但無匹配流水 | 檢查對應銀行接入服務日誌；確認銀行側是否已完成轉帳 | 單筆 | P2 |
| 2 | 匹配引擎延遲 | 流水已入庫但未匹配到 Apply | 檢查匹配定時任務是否正常運行（每 3 分鐘） | 批量 | P1 |
| 3 | SBA Procedure 建立超時 | 匹配成功但 Procedure 未建立 | 檢查 SBA 服務是否正常、SRPC 是否超時 | 單筆 | P1 |
| 4 | 風控變更失敗 | Procedure 建立成功但狀態為 end_reject | 查看 Procedure 的 reason 欄位 | 單筆 | P2 |
| 5 | Canal 同步延遲 | CRM 搜尋不到已存在的記錄 | 等幾秒重新搜尋；檢查 Canal Consumer 是否正常 | CRM | P2 |
| 6 | 銀證輪詢超時 | 天星 BST 入金/出金長時間處理中 | 檢查輪詢任務重試次數（入金 60 / 出金 10） | 單筆 | P1 |
| 7 | 定時腳本未運行 | 出金 Procedure 卡在 new(waiting) | 檢查出金定時腳本是否正常執行 | 批量 | P0 |
| 8 | 人工轉帳未確認 | 出金 Procedure 卡在 pending(transfer_manual) | 提醒運營在銀行網銀完成轉帳後確認 | 單筆 | P2 |
| 9 | SM2 Socket 斷連 | 招行/民生銀證通道完全不可用 | 檢查 cmb_stock_trans / ms_stock_bank_transaction 服務狀態 | 通道級 | P0 |
| 10 | RabbitMQ 積壓 | 多筆入金/出金批量延遲 | 檢查佇列深度和消費者狀態 | 批量 | P1 |
快速排查決策樹
系統間呼叫關係
讀完之後
| 我想... | 去看 |
|---|---|
| 了解系統管什麼不管什麼 | 新人導讀 § 30 秒全景 |
| 深入了解 SBA 編排 | SBA 資金編排 |
| 深入了解銀行卡體系 | 銀行卡與授權 |
| 看各銀行接入方式 | 銀行能力矩陣 |
| 看告警和定時任務 | 定時任務與監控 |
這個頁面有幫助嗎？