前言
整理了一下大流量的網站架構設計，看起來大多的共通性都是把大拆小 "拆"，把工作或瓶頸拆分出去，讓系統或服務夠容易水平擴展，避免在在單點上過載，造成系統瓶頸，其實就和真實世界的大型組織一樣，遇到發展瓶頸都得拆。
前端
- 前端優化，如:最佳化圖片、JS、CSS、延遲載入、頁面靜態化。
- 使用 CDN ，將靜態內容搬到CDN上，減少主伺服器的 IO 壓力。
後端
- 採用成熟的程式語言框架，並採用非同步的方式撰寫，讓其 CPU 及 IO 利用率極大化，不需要的資料，就不要傳到前端，可以在一個request 要到，就不需要多個request。
- 採分散式架構 - 把應用拆解成多個獨立服務，避免一個服務卡住造成系統瓶頸。 如: 金流模組、物流模組
- 採用一些佇列技術 - 當系統在短時間內接收到大量請求時，佇列可以將這些請求暫時存放，然後按照系統的處理能力逐步處理，避免瞬間使用率對系統造成衝擊
- 可以透過一些程式的演算，來消化瞬間的效能瓶頸，融斷、隔離、重試、降級、超時、限流(令牌桶、等候室、漏桶)
資料庫
- 資料庫效能優化。如:建立索引、語法優化、反正規化，減少Join、表垂直拆分或使用快取伺服器，將不常變動的資料，快取起來，不要每次從Db 撈取等。
- 可以將資料庫進行分片（Sharding）或分庫，將數據分散到多個數據庫上進行處理。
- 讀寫分離 - 將資料庫讀寫分離，透過主從複製(Master Slave Replication)來處理大量讀請求。
- 使用 NoSQL 資料庫，NoSQL 能有效地分區、分片，並具備水平擴展特性，特別適合處理大規模數據，例如:會員資料。
- 確保交易一致性，使用鎖機制
快取
- 前端快取 - 開啟 Client side cahce ，用戶端讓要過的檔案，沒有變更，就不需要重覆在請求。
- 後端快取 - 對於不常變更、但頻繁查詢的資料，可利用快取伺服器進行快取，或採用 Redis Cluster 進行資料分片（適合 Redis Key 連續的場景）。
運維
- 負載平衡器 - 負載平衡的核心原理是透過反向代理機制，將流量和任務分攤至多台伺服器上。如果 QPS 小於 10k，建議使用軟體反向代理（例如 nginx 或 yarp），因為硬體負載平衡設備的晶片經過額外設計，可以承載更高的流量負荷。當 QPS 超過 10k 時，就需要考慮採購硬體負載平衡器，例如 F5。
- 採用現代化系統運維架構(K8s)，可以依據 QPS 或系統資源擴容及縮容。
- 服務監控 (Health Check) - 及時偵測並回應服務異常，確保服務穩定運行。例如：Uptime-Kuma
- 應用服務可觀測性 - 提供應用性能的可視化與分析，方便問題診斷與效能優化。例如：Signoz、Prometheus
- 日誌服務器 (Log Server) - 集中管理與分析日誌，便於查找與追溯問題來源。例如：Grafana、SEQ
安全
- 使用 Cloudfalre 之類的網站防護的服務，避免一些惡意攻擊。如:DDoS
- 防範 CSRF 攻擊以增強系統安全。
最後
其實有些功能，我也沒實作過，但整理出來是希望自己有個概念，當遇到時，至少有個解決方案，但不是每個網站都需要這樣的架構設計，拆的太細的架構也會增加維護成本，而是考量未來的生意量，評估這種網站架構，會更適合。
留言