思考的問題

有哪些經典系統架構設計模式可以參考？

由於前人已經針對常見議題有了許多經典的解決方案。
因此在設計架構時，通常會希望參考經典的設計模式。
常見的架構模式包含：伸縮、快取、微服務、事件驅動、分層負責、業務模組化

垂直伸縮

描述

當伺服器有較高的系統負載需求時(例如：CPU, 記憶體, 硬碟空間)，如果是實體機器，直接換上更高的記憶體或硬碟空間。如果是虛擬機器，則動態調整分配給VM更多的系統資源。

優點

• 架構單純: 只要增加單一伺服器更多系統資源，就可以應對更多的系統需求

缺點

• 停機時間：如果是實體機器需要安裝新的設備；如果是虛擬機器，可能需要重新開機。
• 有限的伸縮能力：垂直伸縮仍然受限於單一伺服器的硬體限制，當系統需求超過此限制時，無法提供更多的系統需求。

水平伸縮

描述

水平伸縮是一種系統資源管理策略，當系統的資源需求動態上升或下降時，通過增加或減少伺服器或容器的數量，以有效地利用系統資源，提高系統效能。這可以通過根據流量預測進行自動排程，或根據系統負載量的偵測啟動自動伸縮。

優點

• 最佳化系統資源利用率：當系統資源利用率低時，可以動態降低伺服器數量，以節約成本。
• 避免單點故障：多個伺服器或容器共同服務，搭配負載平衡與監控機制可以避免單點故障，提高系統可用性。
• 無須中斷服務：水平伸縮通常在運行期間進行，通過增加更多的伺服器或容器來應對高流量需求，無需停機或中斷服務。

缺點

• 架構較複雜：需要考慮如何監控和管理伺服器或容器的數量和狀態。
• 非所有系統都適用：進行水平伸縮可能需要對系統進行重新設計，以確保各個元件能夠適應動態變化的環境。
• 網路和通信成本：由於系統由多個伺服器或容器組成，需要額外的通信流量和協調成本。

案例

• 容器環境：像是Kubernetes、Docker等容器環境提供了彈性的伸縮功能，可以根據需求自動調整容器的數量。
• 分布式資料庫：在分布式資料庫中，可以根據負載和數據量的變化來調整節點的數量，以提供更好的效能和可靠性。
• 分布式儲存：將數據存儲在多個節點上，可以根據數據量和存儲需求進行伸縮，以確保高效的數據存取和容量管理。

快取

描述

快取是在取得資料後，暫時保存資料。在資料過期前，不再重複向後端取得資料。

優點

• 減少伺服器的負擔：存取資料都需要消耗系統資源，而且往往需要經過多個節點才能得到結果，因此減少重複計算可大幅減少整個系統的負擔
• 減少網路流量：存取資料需要網路流量，而網路頻寬是有成本存在的。避免冗餘的網路流量可降低頻寬需求
• 加快回應使用者的速度：由於減少重複的資料存取，因此可較快速的回應使用者。這可增進使用者滿意度。

缺點

• 快取過期風險：由於資料並非每次取得即時資料，因此有使用過期資料的風險。

快取管理策略

• 設定到期時間：透過定義合適的到期時間，到期後再更新快取的資料。
• 檔案更名以強制更新快取：由於不同的檔名會重新計算快取時間，因此透過更改檔名可在檔案未過期前，強制更新快取
• Write Through策略：更新後端資料時，一併更新快取。由於需要更新兩處，因此速度較慢。
• Write Back策略：先更新快取，等到伺服器有空的時候再更新資料庫。此策略回應速度快，但是有資料損失風險。

案例

• 瀏覽器快取：瀏覽器本身的indexdb、localstorage、sessonstorage都可以儲存資料。不過由於空間限制，只適合存取少量資料。
• Load balance快取：在到Web server之前，Load balance伺服器就可以進行快取
• Web Server快取：Web Server可以快取後端資料庫的資料或是需要費時的計算結果
• 資料庫快取：資料庫端雖然是存取資料的終端，但是有些需要費時的計算，也是可以快取
• 快取伺服器：將快取資料放置於獨立的伺服器，通過Redis等方式進行快取管理。這樣多台Server都可以讀取同一個快取伺服器的資料，進一步的減少資料庫的負擔
• 分佈式快取：如果需存取快取伺服器的伺服器數量過多，需要使用多台快取伺服器建構分佈式快取。並透過同步機制管理各伺服器的快取資料。

微服務

描述

微服務是一種軟體架構模式，藉由將大的系統拆成多個小的模組，以實現鬆耦合的系統架構。各微服務有獨立的業務邏輯，並連接到自有的資料庫。微服務之間通過HTTP等輕量化通信協定進行溝通。

使用情境

• 複雜的大型系統，希望減少耦合度
• 希望彈性的水平部屬系統

優點

• 減少耦合度 : 藉由拆分不同的系統，避免內部直接呼叫，以減少耦合度
• 易於水平擴展 : 猶豫不同的系統可以有獨立的容器，針對高流量需求的系統，可以動態部屬更多容器
• 技術獨立 : 不同的系統可以依照其特性使用不同的軟體架構與技術選型

缺點

• 無法直接跨系統呼叫 : 由於已經拆分為不同的系統，因此無法直接直接呼叫其商業邏輯
• 需要較多的網路流量 : 各微服務之間以網路進行通信，可能會增加網路流量需求
• 部屬與維運較複雜: 因為拆分為多個子服務，各自需要獨立部屬。而且需要偵測各自流量需求，動態水平伸縮，因此管理上較為複雜。

事件驅動

描述

事件驅動模式是一種以註冊事件並指定事件發生時預期執行的邏輯的程式設計模式。該模式中，事件處理邏輯與事件觸發點解耦合，不需要在程式碼中直接指定事件觸發的位置，而是通過事件註冊和觸發系統來動態連接事件觸發點和處理邏輯。

優點

• 解耦合：事件處理邏輯與事件觸發點解耦合，使得程式結構更靈活且易於維護。
• 非同步：事件觸發程式不需要等待事件處理邏輯完成，可以快速回應使用者，提高系統的反應速度。

缺點

• 處理流程不明確：由於事件註冊和觸發系統動態呼叫事件處理邏輯，因此後續的事件流程可能不容易理解和追蹤。
• 交易控制困難：因為各個事件處理邏輯相互獨立，無法在某個事件處理邏輯中追蹤和控制之前事件處理階段的結果。
• 效能影響：由於需要動態觸發事件並處理大量的事件，系統的效能可能受到影響。需要適當地設計和管理事件註冊，以避免性能問題。

描述

分層架構 (Layed Architecture) 分割不同關注點的程式到不同的位置。

優點

• 程式理解性：由於程式只關注在單一目標上，因此提升程式的可理解性。
• 易於維護：程式開發時只需專注目前功能，而無須擔心影響其他程式。
• 可抽換：只要確保通信格式一致，便可依需求抽換不同層，甚至於不同平台進行。
• 易於測試：由於事先定義各層的通信格式，因此易於撰寫測試腳本。這可確保程式功能修改後，皆能自動進行相關測試
• 易於擴展：由於系統的耦合度下降，而且獨立不同功能的模組。因此可以依照實際需求，動態擴增較高需求的模組。

缺點

• 複雜性：程式功能分割為多層分別進行，由於各層之間交互連動，這可能會增加系統管理的複雜度。
• 性能開銷：需要更多的伺服器或容器以進行不同的任務，而且各層之間通常經由網路進行通信，這需要較多的性能開銷。

常見案例

• 表現層：提供使用者介面，可能是桌面應用程式、網頁應用程式、手機應用程式
• 控制層：接收與回應使用者請求，啟動對應服務層
• 服務層：應用程式的核心商業邏輯
• 資料層：負責管理與儲存資料

業務模組化

描述

對不同業務功能進行模組化，以降低系統的耦合度。
同樣達到低耦合目標，模組化是水平分割系統，分層架構是垂直分割系統。
業務模組化的優缺點，因此也與分層架構的優缺點類似。

常見案例

• 使用者資訊模組：負責使用者認證與授權
• 商品資訊模組：紀錄商品資訊並提供訂貨功能
• 金流模組：進行付款、收管及帳務管理