解決新系統必須整合舊的 HTTP service 時遇到的同步問題

1. HTTP CALLBACK BRIDGE
Phoenix Su

2. 現況
Clients Backend
Service
Ex: Web ServerEx: Desktop、Mobile
Request
Polling

3. 現況
 優點：
 implement 容易，架構單純
 HTTP library 很普遍
 缺點：
 產生extra的connection/request (conditional get
可解，但仍然需要一次 request)
 不知 Backend 端資料是否改變，所以需要不斷
request or 設定 expire

4. Think about…
 如何知道Backend端資料已改變？
 資料改變時如何將資料送給 Clients 或通知
Clients 重抓資料？
 改成 Keep connection service 將Clients「黏」
住可以解決，但會不會改太大？
 在 Backend 到 Clients 端搭一座單向的橋，
是否可以通知 Clients 資料改變？

5. HTTP callback + bridge
Clients
Backend
Service
Ex: Web ServerEx: Desktop、Mobile
Request
黏住Clients
的 Service
Ex: Socket Server
CallbackNotify

6. HTTP callback + bridge
 Socket Server 對 Backend 以 HTTP request 方式做類似
註冊+Alive的動作
 例如 Socket Server 對Web Server 送出http://<Server
>/register? callback=http://<Server>/recv/userdata
 當有其他人透過Web Server 改變資料時，Web Server
就會呼叫 http://<Server>/recv/userdata?user=David
 Socket Server 便可以通知 David 的 Client 重新抓資料

7. 需求
 bridge的角色需具備 HTTP service 的能力
(Socket Server orWeb Socket Server 皆有)
 Backend service 需 implement：
 Register
 Alive & Auto expire
 HTTP request to callback address

8. Question
 有多台 Backend 時
 Solution A: bridge 對每台 backend 皆註冊
 Solution B: Backend 共用一個 register/callback pool
 Solution C: Backend 之間可互相溝通，當某個 user
資料被改變時，通知所有提供相同服務的 Backend
Service
 只適用 Server to Server，不適用 Server to End
User

9. Optimize
 HTTP callback 的 timeout 越短越好
 HTTP callback 的單次傳送資訊越多越好，例如
http://<Server>/recv?user=David,Amy,James,Calvin
 HTTP callback 的動作要是 non-blocking 的