回憶一下 Day 16 的基本系統架構

可以看到我們只有一台對外的 API Service, 所有的請求都會透過此服務轉給我們內部的服務, 當使用量很大時可能會有以下問題

• 單點失效 (Single Point of Failure, SPOF)
• 效能瓶頸
• 維護困難

上述問題任何的服務都可能遇到, 但是根據服務類型會有不同解法和其他衍生的問題
這裡先以 API Service 為例

效能瓶頸 和 維護困難 比較直覺, 前者會影響 可用性, 後者則會造成升級或除錯的困難
故底下僅針對 SPOF 說明

SPOF

SPOF 是指在整個系統中, 只要任一節點故障, 就會造成整個系統故障
對於需要長期在線的服務如 電商, 雲端服務, 支付服務等, 通常會著重在系統的可用性, 也就是上篇提到的 AP 系統

那麼要怎麼解決呢?

Redundancy

由於外部的 API Service 通常是無狀態的 (Stateless), 這讓服務有很好的擴展性 (不用同步狀態)
我們可以部署多個 API Service, 當任一台伺服器下線了, 我們就可以將流量轉給剩餘的伺服器, 保證系統的可用性

那麼問題來了, 既然每個 API Service 是無狀態的, 誰會負責轉移流量和檢查每個服務的健康狀況呢?

負載均衡器 (Load Balancer)

一種方式是透過 負載均衡器 分配流量, 比如透過輪詢 (round-robin), 最少連接等策略檢查服務的狀態
並在服務下線時將流量導向其餘的伺服器

常見的有 nginx, traefik proxy, HAProxy 等

...看到這裡你可能會想, 負載均衡器 是不是也有 SPOF 的問題? 這樣豈不是沒完沒了?
沒錯! 負載均衡器也會有 SPOF 的問題, 所以也需要部署多個 負載均衡器 來避免 SPOF

所以問題又來了...誰會負責轉移流量給 負載均衡器 呢?

DNS 負載均衡器

DNS 負載均衡器通常負責將流量分配給多個負載均衡器, DNS 伺服器根據流量, 地理位置, 健康狀態等策略, 將域名解析到不同的負載均衡器 IP 地址

由於這牽涉到路由器的工作原理, 這邊僅簡單說明

1. 當客戶端如瀏覽器, 請求訪問流量負載器時, 會先向本地 DNS Resolver 發送查詢請求
2. 本地 DNS Resolver 會向權威 DNS 伺服器 (或通過中繼 DNS 伺服器) 查詢流量負載器的 IP 位置

常見的有 AWS Route 53, Cloudflare DNS, Google Cloud DNS

(題外話: 電腦或路由器都有設定好 DNS 伺服器 IP 或是 DNS Table, 所以我們不用特別處理)

(題外話2: Route 53 的規模是全球性的, 讓各國的使用者能夠請求到 "地理上" 最近的 DNS 伺服器, 極度改善使用者體驗, 但一般服務不需要到這個程度...可以用 ISP 給的就好XD)

(題外話3: ISP 給的 DNS 伺服器會有用戶瀏覽紀錄或是封鎖某些網站, 所以如果有需求的話可以用下面幾個公開的 DNS 伺服器

Google Public DNS: 8.8.8.8, 8.8.4.4
Cloudflare DNS: 1.1.1.1, 1.0.0.1
OpenDNS：208.67.222.222, 208.67.220.220)

Reference

• Amazon Route 53
• Cloudflare DNS
• Google Cloud DNS