架構演化

從一台伺服器開始

系統設計面試不需要一開場就搬出最複雜的分散式架構。

先用單一伺服器加單一資料庫建立一個可運作的最小方案。

這個最小方案是後續所有演化的起點。每加一個元件，都應該有理由。

演化的驅動力

架構不會自己長大，是需求推著它長。

主要有三股力量：使用者成長、流量增加，以及可用性需求。

沒有這些壓力，就不需要加元件。過早優化只是替自己增加複雜度。

常見的演進路徑

當壓力出現，元件通常依一個常見順序加入。

先是負載平衡與快取，接著是資料庫讀寫分離與分片，最後是非同步佇列與多區部署。

這不是死規則，而是一條可以幫你排序的參考路線。

先說瓶頸，再談方案

每一次演化，都要先說明目前的瓶頸。

例如伺服器 CPU 不足、資料庫讀取過慢，或尖峰流量造成服務不穩定。

說清楚瓶頸之後，再提出對應的改善方案。順序反過來，就變成在堆砌技術名詞。

需求到設計的思考迴圈

這種思考方式是一個可以重複跑的迴圈。

從需求出發，找出瓶頸，選一個對應方案，然後再看新的瓶頸在哪裡。

每跑一圈，系統就往前演化一步，而且每一步都說得出理由。

避免過早優化

最常見的失誤，是在還沒有瓶頸時就加元件。

分片、多區部署都有代價。沒有需求支撐，它們只是增加複雜度。

那麼，什麼時候加才算剛好？

帶走這三件事

從最小方案開始：單一伺服器與單一資料庫先跑起來。

先講瓶頸再講方案：伺服器 CPU 不足、讀取過慢、尖峰不穩，各有對應解法。

呈現取捨：由需求、瓶頸到設計選擇的結構化思考，比堆砌技術名詞更有說服力。

設計系統的最小可運作方案時，應採用單一伺服器加單一資料庫嗎？

• 是
• 否

答案: 是

是。系統應先從單一伺服器與單一資料庫開始，之後再依需求和瓶頸加入元件。

在壓力逐步出現時，一條常見參考路線是：先加入_____來分散請求，再加入_____保存常用結果；之後以_____分開資料庫讀取與寫入，並以_____切分資料；最後用_____延後處理，配合_____跨區提供服務。

答案: 在壓力逐步出現時，一條常見參考路線是：先加入負載平衡來分散請求，再加入快取保存常用結果；之後以讀寫分離分開資料庫讀取與寫入，並以分片切分資料；最後用非同步佇列延後處理，配合多區部署跨區提供服務。

這是一條常見的演進參考路線，不是無條件套用的固定規則。每個元件仍需由實際需求與瓶頸支持。

一台伺服器的 CPU 已不足，導致服務在流量增加時變慢。下一個較應優先考慮的方案是什麼？

• 加入負載平衡
• 加入資料庫讀寫分離
• 加入資料庫分片
• 直接部署多個區域

答案: 加入負載平衡

負載平衡可以把請求分散到多台伺服器，直接緩解單台伺服器的 CPU 壓力。快取、讀寫分離與分片主要處理其他類型的瓶頸。