如何設計高流量的系統設計架構

更新 發佈閱讀 7 分鐘

討論這個議題似乎有些抽象,當我們的系統初次上線時,實際上有高達 80% 的時間處於低流量狀態。我們就舉例像是:購物網、社群平台這類特定類型的網站,比較有可能面臨高流量的情況。

然而,我們不能等到問題發生後才急忙改變架構,那樣的後果不堪設想。既然如此,為何不在一開始就規劃一個能夠應對未來可能出現的高流量情況的穩健架構呢?


設計一套能夠應對高流量情況的系統,需要從多個維度進行考慮與規劃。為了確保系統的穩定性與擴展性,以下是一些實用且被廣泛認可的策略和最佳做法:

  1. 水平擴展:通過在多個服務器上分散負載,水平擴展允許系統隨著需求增加而增加更多的資源。這可以通過增加更多的應用伺服器或資料庫節點來達成,從而有效應對高流量的挑戰,並保障系統在需求增加時的靈活擴展。
  2. 負載均衡:負載均衡器能夠將入站流量平均分配至多個服務器,以防止任何單一節點的過載,從而提升系統的整體可用性與穩定性。Nginx、HAProxy 以及 Amazon AWS 的 Application Load Balancer 等都是常見的選擇。
  3. 快取策略:適當地使用快取可以顯著減少對後端資料庫的直接請求,從而提高系統的響應速度和整體性能。Redis 和 Memcached 是極佳的快取解決方案。對於靜態內容,如圖片和前端資源,使用 CDN 進行快取也能有效減輕後端的壓力。
  4. 資料庫性能優化:透過合理使用索引、資料庫分區以及資料庫分片等技術,可以顯著提升資料庫的處理能力與查詢效率。此外,根據應用的具體需求選擇最合適的資料庫系統(關係型或非關係型)也至關重要。
  5. 採用微服務架構:將一個大型應用拆分成多個小的、獨立的微服務,可以使系統更易於管理與擴展。每個微服務都可以獨立部署和擴展,從而使系統能夠更靈活地應對各個服務的具體需求。
  6. 限流與熔斷:限流可以預防系統因突發的大流量而過載,熔斷則可以保護系統在某個部分出現故障時,避免故障蔓延導致整個系統的崩潰。這兩種機制對於維持系統的穩定運行至關重要。

透過這些策略的實施,不僅可以提升系統對高流量的承受能力,還能保證在面臨不同規模的用戶需求時,系統的平滑運行和高可用性。


raw-image

在實務上

當你負責的系統已經穩定運行了數月並且有了一定程度的流量,或者當你被賦予任務去設計一個能夠應對高流量的系統時,那麼「水平擴展」和「負載均衡」無疑是非常直接且有效的策略。

這兩個策略能夠透過增加『資源』來達成將流量分散的效果,而具體要如何分流,則需視系統的瓶頸所在來決定,可能的焦點包括:

  • 網站服務:若網站本身的請求處理能力不足,可以透過增加更多的網站服務器並透過負載均衡器分散請求來提升整體處理能力。
  • 資料庫系統:資料庫是常見的系統瓶頸之一,可以考慮透過資料庫集群、讀寫分離或資料庫分片等策略來增強其處理高流量的能力。
  • 網路架構:網路設備與架構也可能成為流量瓶頸,此時可以透過升級網路設備或優化網路架構來改善。


補充一下

關於為什麼「快取」可能不是所有情況下的首選解決方案:

實際上,是否採用快取要看你的系統主要服務是什麼。像是涉及到實時更新的「銷售類」網站,顯示的是商品的即時庫存,這種情況下用快取就不太合適,因為資訊需要實時反映最新狀態。

另一方面,對於以內容展示為主的網站,比如說:像是「方格子」,快取就非常有用了。畢竟,當一篇文章成為熱門內容,被大量訪問時,文章本身的內容是不會改變的,這時候使用快取能有效減輕伺服器壓力。至於文章的互動部分,如留言和點讚等,則可以採用其他方法進行動態更新,不必依賴快取。

所以,選擇是否使用快取,得根據系統的具體需求和特點來決定,並非所有場景都適用。


水平擴展 (Horizontal Scaling)

在談到水平擴展 (Horizontal Scaling)的具體做法時,確保應用的無狀態運作是關鍵。以下是針對在 Laravel 框架中實踐無狀態應用服務的一些建議,以助於應對高流量情境:

  1. 無狀態應用服務:讓你的 Laravel 應用成為無狀態的,這樣就能在多台機器間分散使用者請求。重點在於,要將 session 資訊存放在像是 Redis 或 Memcached 這樣的中央儲存系統,確保各服務間的狀態同步。
  2. Session 的集中式管理:將 session 存放在集中式的儲存系統,不論使用者接觸到哪一台伺服器,都能獲得一致的 session 資訊。Laravel 提供了容易設置的選項來實現這一點:
    // config/session.php
    'driver' => env('SESSION_DRIVER', 'redis'),

    // config/database.php
    'redis' => [
    'client' => env('REDIS_CLIENT', 'predis'),
    'default' => [
    'host' => env('REDIS_HOST', '127.0.0.1'),
    'password' => env('REDIS_PASSWORD', null),
    'port' => env('REDIS_PORT', 6379),
    'database' => env('REDIS_DB', 0),
    ],
    ],
  3. 避免使用本地存儲:對於需要被多個應用實例訪問的資料,不應該將其存儲在本地檔案系統。改用雲儲存服務如 Amazon S3 或 Google Cloud Storage,或者是使用網絡檔案系統(NFS)來實現資料的共享。
  4. 應用邏輯與狀態分離:盡量將應用邏輯與用戶狀態分離開來,將必要的狀態資訊存儲於資料庫或其他中央管理的服務。
  5. 採用無狀態認證方式:如 JWT 等無狀態認證機制可以跨服務共享使用者身份,無需在每次請求時都驗證狀態。
  6. 應用的容器化:使用 Docker 等容器技術部署應用,可以確保在不同環境中應用的一致性,並且容器的快速部署與銷毀特性非常適合動態擴展。
  7. 無狀態的 API 設計:確保 API 的每次請求都是自包含的,即包含了完成請求所需的所有資訊,這樣 API 就可以在多個伺服器上無縫運作。
  8. 利用消息隊列與後台處理:對於耗時的任務,將其放入後台隊列中處理,可以減輕前端伺服器的壓力,並且隊列服務本身也可以根據任務量進行擴展。
  9. 性能優化:使用各種中間件(middleware)、快取和數據預加載等技術,減少對狀態的依賴,從而降低單點壓力,提升整體性能。

透過上述的策略和技術,你的 Laravel 應用將更加適合於水平擴展,從而提高應對高流量情境的能力。


提到的這些建議,只是入門的一步。實際上,每個系統的情境都有其獨特性,不可能單靠套用幾個策略就能解決所有問題。要真正優化系統,除了這些大方向的架構調整外,還需要深入到程式碼層面,細心審視每一行程式的效能,以及資料存取方式的合理性。只有透過全面的檢視和不斷的調整,才能使系統更加穩健,應對各種挑戰。


註:負載均衡是另一種應用/傳輸層的結構處理,以後有機會再發篇文章說明~

留言
avatar-img
留言分享你的想法!
avatar-img
詹姆士的軟體易開罐
27會員
89內容數
這是一系列以軟體開發為主題的輕鬆分享,內容涵蓋了技術選擇、開發經驗、實戰應用等多方面的議題。無論是如何在眾多框架中做出選擇,還是如何應對技術轉移的挑戰,這裡有幽默、有趣的對話風格,將複雜的技術問題轉化為易懂的故事。
2025/01/14
「如果資料庫出問題,能不能快速恢復?」 這或許是許多工程師在面對資料庫維運時心中的疑問。就我而言,遇到伺服器故障或有人誤刪資料表時,最慶幸的就是事先做好備份。這次要分享的是 MySQL 中常用的備份指令 mysqldump,讓大家能在需要時把握關鍵的「救命繩」。 為什麼需要備份? 在商業專案
Thumbnail
2025/01/14
「如果資料庫出問題,能不能快速恢復?」 這或許是許多工程師在面對資料庫維運時心中的疑問。就我而言,遇到伺服器故障或有人誤刪資料表時,最慶幸的就是事先做好備份。這次要分享的是 MySQL 中常用的備份指令 mysqldump,讓大家能在需要時把握關鍵的「救命繩」。 為什麼需要備份? 在商業專案
Thumbnail
2024/08/25
這篇文章反映了平台改版後使用者面臨的多項問題,包括文章編輯功能異常、分類顯示異常及最新內容資料呈現問題。本人從個人經驗出發,詳細描述了這些問題的具體情況,期望官方重視使用者反饋,以改善平台使用體驗。
2024/08/25
這篇文章反映了平台改版後使用者面臨的多項問題,包括文章編輯功能異常、分類顯示異常及最新內容資料呈現問題。本人從個人經驗出發,詳細描述了這些問題的具體情況,期望官方重視使用者反饋,以改善平台使用體驗。
2024/07/20
2024年7月19日…,一場前所未有的全球性大事件悄然降臨。這次事件波及了機場、車站,以及無數依賴關鍵系統的商店與公司。聽起來像是科幻小說中的場景,然而,這真真切切地發生在昨天。世界各地的運營陷入混亂,人們的生活被突如其來的技術故障打亂。 這一切都要從一間公司開始說起——CrowdStrike
Thumbnail
2024/07/20
2024年7月19日…,一場前所未有的全球性大事件悄然降臨。這次事件波及了機場、車站,以及無數依賴關鍵系統的商店與公司。聽起來像是科幻小說中的場景,然而,這真真切切地發生在昨天。世界各地的運營陷入混亂,人們的生活被突如其來的技術故障打亂。 這一切都要從一間公司開始說起——CrowdStrike
Thumbnail
看更多
你可能也想看
Thumbnail
本文介紹了在網站開發中如何運用狀態機的原則和設計方法。通過具體案例分析,以及狀態和數據的區分,詳細介紹了狀態機的設計原則和應用。讀者可以通過本文瞭解如何將狀態機應用於實際的網站開發中。
Thumbnail
本文介紹了在網站開發中如何運用狀態機的原則和設計方法。通過具體案例分析,以及狀態和數據的區分,詳細介紹了狀態機的設計原則和應用。讀者可以通過本文瞭解如何將狀態機應用於實際的網站開發中。
Thumbnail
在網路速度有限的情況下,依序記錄不斷產生的資訊,能統計使用者在頁面上操作了哪些功能。
Thumbnail
在網路速度有限的情況下,依序記錄不斷產生的資訊,能統計使用者在頁面上操作了哪些功能。
Thumbnail
本書介紹了戰略設計、管理領域複雜度、實際應用領域驅動設計等主題。透過對核心子領域、支持子領域、限界上下文等概念的探討,提供了領域驅動設計的相關知識。這篇文章中還涉及了微服務、事件驅動架構和資料網格等相關主題,提供了設計系統和應用領域驅動設計的指導。
Thumbnail
本書介紹了戰略設計、管理領域複雜度、實際應用領域驅動設計等主題。透過對核心子領域、支持子領域、限界上下文等概念的探討,提供了領域驅動設計的相關知識。這篇文章中還涉及了微服務、事件驅動架構和資料網格等相關主題,提供了設計系統和應用領域驅動設計的指導。
Thumbnail
觀察者模式透過主題訂閱/訊息通知的機制,極度增強系統的可擴展性、靈活性以及降低組件間的耦合度。概念直觀簡單,是非常實用的設計模式。
Thumbnail
觀察者模式透過主題訂閱/訊息通知的機制,極度增強系統的可擴展性、靈活性以及降低組件間的耦合度。概念直觀簡單,是非常實用的設計模式。
Thumbnail
軟體系統的發展歷程大多相似,首重解決基本需求、提供操作介面,進而提升安全性、擴充功能、優化操作。
Thumbnail
軟體系統的發展歷程大多相似,首重解決基本需求、提供操作介面,進而提升安全性、擴充功能、優化操作。
Thumbnail
討論系統架構時,我們常忽略低流量時期的準備,但真正的挑戰在於怎樣在突發高流量時保持穩定。我們深入探討了如何透過水平擴展、負載均衡、快取策略等多維度規劃,來強化系統對高流量的承受力,確保系統的靈活擴展與高可用性。
Thumbnail
討論系統架構時,我們常忽略低流量時期的準備,但真正的挑戰在於怎樣在突發高流量時保持穩定。我們深入探討了如何透過水平擴展、負載均衡、快取策略等多維度規劃,來強化系統對高流量的承受力,確保系統的靈活擴展與高可用性。
Thumbnail
確保沒有遺漏或錯誤 程式的完整資訊資料對於程式設計至關重要。這是因為只有透過完整的資訊,我們才能確保在程式設計中沒有任何遺漏或錯誤。最終,後台管理扮演著管理系統中所有動作和行為是否符合特定標準的重要角色。 採取不符合預期的行動 這種符合性的重要性在於,當我們設計程式時,希望使用者按照預期的方式
Thumbnail
確保沒有遺漏或錯誤 程式的完整資訊資料對於程式設計至關重要。這是因為只有透過完整的資訊,我們才能確保在程式設計中沒有任何遺漏或錯誤。最終,後台管理扮演著管理系統中所有動作和行為是否符合特定標準的重要角色。 採取不符合預期的行動 這種符合性的重要性在於,當我們設計程式時,希望使用者按照預期的方式
Thumbnail
系統的分析與規劃 在談到程式設計時,首要的是進行系統的分析與規劃。程式設計的起點通常是系統分析與規劃,這涉及到如何分析和設計系統的大原則和方向。為了達到預期效果,重要的是擁有對產業的清晰邏輯認識和深入了解。 進行深入了解 若要進行系統分析,必須對企業的設計和程式設計的對象進行深入了解,以充分理
Thumbnail
系統的分析與規劃 在談到程式設計時,首要的是進行系統的分析與規劃。程式設計的起點通常是系統分析與規劃,這涉及到如何分析和設計系統的大原則和方向。為了達到預期效果,重要的是擁有對產業的清晰邏輯認識和深入了解。 進行深入了解 若要進行系統分析,必須對企業的設計和程式設計的對象進行深入了解,以充分理
追蹤感興趣的內容從 Google News 追蹤更多 vocus 的最新精選內容追蹤 Google News