iT邦幫忙

2024 iThome 鐵人賽

DAY 22
0

上篇我們介紹了擴展對外 API Service 的方式, 現在我們可以透過路由分散大量的請求減輕負擔和避免 SPOF 了
既然對外的 API Service 沒問題了, 壓力就給到 內部的 API Service 了

以前面的訂房系統為例, 我們目前所有的服務都是透過內部的 一台 API 伺服器 處理, 所以我們的負載均衡器流量都還是導向同一個位置...跟沒有一樣囧

然而相較於外部 API Service 只是簡單的將請求發給內部伺服器, 所以是無狀態且很容易擴展的
內部 API Service 則會牽涉到業務邏輯, 所以複雜許多 (或者說 "責任不同")
比如目前的責任包含了 使用者登入, 檢查庫存請求, 付款請求, 訂房請求等等, 所以也容易遇到效能瓶頸

Redundancy

一種解決方式是像上篇一樣用 Redundancy, 並讓負載均衡器分散流量給不同的伺服器
上篇提過這裡就不贅述

Microservice Architecture

另一種就是最常聽到 微服務架構 (Microservices Architecture) 了, 透過將每個服務拆開獨立部署, 再分別 scaling, 就能極大的減少整體系統的效能瓶頸和 SPOF

然而, 雖然 微服務架構 聽起來很炫炮, 但是該架構的一個核心應用場景是 "跨團隊合作開發", 所以大公司或業務量很大的產品採用 微服務架構 才會利大於弊
由於服務間的溝通是透過事先定義好的 API Service, 每個團隊只需要專注開發自己的服務即可, 因此可以使用不同的技術棧實作自己的服務, 將各個團隊解綁

有興趣請見 Microservice Architecture

(題外話: 花了很多時間在研究 Saga Pattern, 推薦這個影片 Applying the Saga Pattern • Caitie McCaffrey • GOTO 2015, 今天偷懶一下XD)

Reference


上一篇
[Day 21] Scaling API Service (一)
下一篇
[Day 23] Message Queue (一)
系列文
30 天 系統設計 學習筆記:建立思考的 SOP30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言