前面 13 天我們介紹了常見並適用大多數系統的元件, 從 資料保存, Database, API Service, Notification (包含 Email, SMS, 瀏覽器), Email Server, 使用者驗證 到 支付服務, 總共 6 大元件

我們將各元件的關係呈現如下

圖一: General System Components

0. Database 從 Storage System 存取資料, 如果我們將 Storage System 和 Database 分別放在不同 伺服器, 則此操作通常是 "非同步" 的, 故用第 0 步表示
1. 使用者 透過 客戶端 (瀏覽器, Native App 等等) 發送請求給 API Service
2. API Service 像 Authentication Service 驗證 使用者 身份, 以確認 使用者 能夠使用後續服務
   3.a API Service 從 Database 拿出 使用者請求的資料
   3.b API Service 發送請求給 通知服務, 通知服務 透過 Server Push 技術發送通知給 客戶端
   3.c API Service 發送請求給 支付服務, 支付服務 依照支付方式進行後續確認

一個沒有服務受傷的世界達成了 🎉

然而看到進度條就知道並沒有這麼簡單, 後面還有 16 天要寫呢囧

到今天我們僅僅完成了 Functional Spec (功能可以正常使用)
然而, 對於有野心的開發者來說, 還有非~常~多~的問題需要考慮
比如

• 目前所有服務都暴露在網路上, 容易被人攻擊
• 若我們任一 伺服器 掛掉, 我們的服務就不能使用了 💀
• 若 Storage System 遭遇硬體故障, 資料就全部不見了 😱
• 若有大量使用者使用我們的服務, 一台 伺服器 可能會過載, 好一點只是回覆速度比較慢, 慘的話伺服器可能直接熱當就下線了

除此之外, 我們也想優化系統的處理速度, 讓使用者能夠更快獲得反饋

由於上面的需求著重的是 "系統的穩健性", 而非 "功能性", 所以我們稱為 Non-functional Spec

本系列後續的文章將基於圖一繼續擴展 (盡量XD)

這邊先給個範例
比如上面提到, 我們將所有服務暴露在網路上, 很容易遭受攻擊, 所以根據 Day 6 提到的方式, 我們將 API Service 分為 Public API 和 Internal API, 並將除了 Public API 以外的服務都搬進 內部網路 (或是後端), 如圖二所示

圖二: 區分 Public API 和 Internal API

相較於圖一, 我們可以先透過 Public API 初步篩選 使用者請求, 或是標準化請求格式等等, 這就是 API Gateway!

這裡就帶出了一個 系統設計 中很重要的概念: 責任

每個元件在系統中扮演不同但很重要的角色, 這也是為什麼本系列以 "元件" 作為開頭介紹

各種新技術層出不窮, 但總是在系統中扮演了某個角色, 承擔某個責任
就像第一天提到的, 系統設計是基於 "選擇", 每個元件都有他擅長與不擅長的部分, 比如前面介紹各種元件實作的差別

設計時搞清楚當前的元件在整體系統中扮演什麼角色, 有助於幫助我們建立更穩健可靠的系統!

灌完雞湯了, 明天正式進入 Scaling!

Reference

• What is Amazon API Gateway?