對接技術方案Plan B === RTI、TP FE、TP BE交互情境 --- **最左邊的E指的是情境* ```sequence Note left of RTI: E:TP從RTI訂閱賠率 RTI->TP Backend: GraphQL 訂閱賽事、賠率 RTI->TP Backend: 賽事、賠率更新 Note right of TP Backend: 沒有調賠，將數據源當成S水 Note right of TP Backend: 更新DB&Redis(S水) Note right of TP Backend: 推送新水給訂閱方 TP Backend->TP Frontend: 最新的S水+Config TP Backend->RTI: 最新的S水 Note left of RTI: E:數據源賠率更新 RTI->TP Backend: 賽事、賠率更新 Note right of TP Backend: 沒有調賠，將數據源當成S水 Note right of TP Backend: 更新DB&Redis(S水) Note right of TP Backend: 推送新水給訂閱方 TP Backend->TP Frontend: 最新的S水+Config TP Backend->RTI: 最新的S水 Note left of RTI: E:操盤手調賠(成功) TP Frontend->TP Backend: 送出賠率調整(Config) Note right of TP Backend: Validator Note right of TP Backend: Config存入DB Note right of TP Backend: 數據源＋Config後，得出S水 Note right of TP Backend: 更新DB&Redis(S水) Note right of TP Backend: 推送新水給訂閱方(FE+RTI) TP Backend->TP Frontend: 最新的S水+Config TP Backend->RTI: 最新的S水 TP Backend->TP Frontend: 調賠Response，提示調整成功 Note left of RTI: E:數據源賠率更新(需混水) RTI->TP Backend: 賽事、賠率更新 Note right of TP Backend: 數據源＋Config後，得出S水 Note right of TP Backend: 更新DB&Redis(S水) Note right of TP Backend: 推送新水給訂閱方(FE+RTI) TP Backend->TP Frontend: 最新的S水+Config TP Backend->RTI: 最新的S水 Note left of RTI: E:操盤手調賠(失敗) TP Frontend->TP Backend: 送出賠率調整(Config) Note right of TP Backend: Validator Note right of TP Backend: Config存入DB(*失敗*) TP Backend->TP Frontend: 調賠Response，提示調整失敗 Note left of RTI: E:操盤手調賠(失敗) TP Frontend->TP Backend: 送出賠率調整(Config) Note right of TP Backend: Validator Note right of TP Backend: Config存入DB Note right of TP Backend: 數據源＋Config後，得出S水(*失敗*) Note right of TP Backend: DB Config Rollback TP Backend->TP Frontend: 調賠Response，提示調整失敗 Note left of RTI: E:操盤手調賠(失敗) TP Frontend->TP Backend: 送出賠率調整(Config) Note right of TP Backend: Validator Note right of TP Backend: Config存入DB Note right of TP Backend: 數據源＋Config後，得出S水 Note right of TP Backend: 更新DB&Redis(S水)(*失敗*) Note right of TP Backend: DB Config Rollback TP Backend->TP Frontend: 調賠Response，提示調整失敗 Note left of RTI: E:操盤手調賠(成功) TP Frontend->TP Backend: 送出賠率調整(Config) Note right of TP Backend: Validator Note right of TP Backend: Config存入DB Note right of TP Backend: 數據源＋Config後，得出S水 Note right of TP Backend: 更新DB&Redis(S水) Note right of TP Backend: 推送新水給訂閱方(FE+RTI)(*失敗*) Note right of TP Backend: 發Slack通知技術端 TP Backend->TP Frontend: 調賠Response，提示調整成功 Note left of RTI: E:用戶發起Query TP Frontend->TP Backend: 發起Query Note right of TP Backend: 到Redis取得對應資料 TP Backend->TP Frontend: 返回S水 ``` ### 主要問題： - 訂閱RTI數據源後，TP需要自己保留、管理一份賠率資料 - S水的路徑是RTI -> TP -> 混水 -> RTI -> Inno路徑較長 ### 優點： - 兩套系統耦合度低很多，架構也相對單純 - 操盤手的操作，在TP裡面包transaction，可以明確知道成功失敗 - 關於混水、調賠的規則，不需要兩邊都做 - 前端邏輯減少，對接的後端or服務，收斂到TP Backend一個 - 減少技術棧數量，Realtime DB是目前公司尚未使用的技術 - 新的需求加入，僅需調配TP的人力及時程安排 - Trouble Shooting時，權責劃分很清楚，只要S水有問題，都是找TP先