Web應用程式調整
-
Web伺服器：從原本Server-side動態網頁改成前
後端分離的SPA（Single Page Application）或是Mobile App，拆解成靜態網頁檔案和動態內容API，且靜態檔案內容還可透過CDN（Content Delivery Network）託管，讓公有雲服務來傳送這些靜態檔案傳輸，避免占用到本地端頻寬。 -
Session認證機制：為了降低Mobile App的行動網路傳輸成本，且配合後端RESTful API的
無狀態原則，使用者登入後的認證資訊就不適合存放在伺服器端Session，需要改成Client端的JWT（JSON Web Token）認證方式，每次檢查其Token內容是否正確，是否逾時。 -
應用伺服器：從XML/SOAP服務，改成輕量簡單的JSON/REST API，且API內容配合前端AJAX渲染網頁，
調整成Entity操作，並且可以依照流程，將使用量大但異動少的Entity內容使用Redis快取儲存，減少應用伺服器和資料庫的負載，並達成資料外部化或無狀態化，這樣應用伺服器才能橫向擴展，專注在業務邏輯運算。
內部服務瓶頸
當特定業務邏輯成為瓶頸點時，就須考慮把這業務邏輯切出成為另一個單獨服務，讓此單獨服務數量增加，服務與服務間可用REST API或gRPC溝通；
外部服務瓶頸
若這外部相依服務成為瓶頸時，可考慮使用非同步方式，如圖3所示，
(1) Client使用結帳API，
(2)結帳API寫入Queue
(3)透過topic訂閱的對外專用API收到通知
(4)對外專用API呼叫Partner信用卡API
(5)外部信用卡API回傳結果
(6)對外專用API收到結果寫入資料庫
(7)結帳API查詢交易結果。
不只是外部API可採用非同步方式，像Email發送或App推播也可相同模式來設計，因發送結果與交易無關，採用Fire & Forget方式可避免同步API造成回應時間過久。
圖3 以非同步呼叫外部Partner API。
- 資料庫：當Web伺服器和應用伺服器都可橫向擴展後，資料庫就會成為瓶頸，連線數量增加，CPU衝高，回應時間過久，但資料庫是無法輕易擴展，這涉及到資料一致性和分散交易等複雜問題，因此有三種非同步方案可解決資料庫瓶頸問題（圖4），
- A方案是先寫到Queue，以Queue來當緩衝，資料寫入API再逐步寫入資料庫，為加速甚至可以增加資料寫入API的數量；
- B方案是利用Cache I/O頻寬大的優勢，先將資料寫入到Cache，適合預約登記或搶紅包的業務情境，避免所有Requests都打到Queue（ESB）和DB，再以整批方式讀取Cache資料寫入資料庫，這可降低資料庫連線數，避免共用資料庫時，影響到其他系統；
- C方案也是利用Cache I/O頻寬優勢，但寫入資料庫是採用CDC（Change Data Capture）方案，監看Cache變化，自動依照對應規則寫入到資料庫表格內，因此無須實作資料庫寫入API。
圖4 三種以非同步寫入資料庫。
資料庫的操作大多是讀取，約占八成，寫入占兩成，80:20法則，因此為了減緩資料庫的負載，可以設計讀寫分離架構（Command Query Responsibility Segregation，CQRS），如圖5所示，1～4步驟是圖4的寫入A方案，早期多採用API分別寫入DB和Cache的A方案，但這資料寫入API需要控制兩者一致性，隨著異質CDC方案出現（Debezium），B方案雖增加CDC元件，卻可減少資料寫入API的程式量，當須寫入Cache的資料量持續增加時，B方案維護成本會是比較低的，建議大型系統採用B方案。
圖5 CQRS讀寫分離的兩種方式。