從單體架構到規模化分散式系統：網站架構演進實戰

網站架構並不是一開始就必須使用複雜的微服務、分散式資料庫或多機房部署。對大多數專案而言，最合理的做法，是先從簡單、容易理解和容易維護的單體架構開始，再根據流量、資料量、可用性與團隊需求逐步演進。

第一篇將從單體與集中式架構出發，說明網站如何從一台應用伺服器和一個資料庫開始運作。早期網站通常由 Tomcat、Web 應用程式和資料庫組成，所有請求集中在同一台機器上。當使用者數量增加後，CPU、記憶體與 I/O 會互相競爭，資料庫也可能成為整個網站的瓶頸。因此，架構會先演進為 Web 伺服器與資料庫分離，再逐步加入快取，降低資料庫的讀取壓力。

快取雖然能改善效能，卻也帶來新的問題。本篇會介紹本地快取與分散式快取的差異，以及 Memcached、Redis 和 Tair 在網站中的應用。同時也會說明快取穿透、快取擊穿、快取雪崩、熱點資料失效，以及快取和資料庫之間的一致性問題，讓讀者了解效能優化並不是單純把資料放進 Redis。

第二篇則進入網站規模化與資料庫拆分的階段。當單台應用伺服器無法承受流量時，可以透過無狀態設計、反向代理和負載均衡，將請求分配到多台 Web 伺服器。搭配 Session 共享、Nginx、HAProxy、LVS、F5 和 Keepalived，可以建立具備擴展能力與容錯能力的網站入口。再進一步結合 DNS 輪詢、CDN 和異地多活，處理跨地區流量與機房故障。

當資料量和交易量持續成長，資料庫也需要進行高可用和水平擴展。讀寫分離可以降低主資料庫的查詢壓力，垂直分庫可以依照業務拆分資料，分庫分表則能處理大型資料表和持續增加的資料量。不過拆分之後，也會產生分散式事務、跨庫 Join、資料一致性和查詢整合等代價。

這兩篇文章將以網站實際運作流程為主軸，帶領讀者理解架構為什麼需要演進、每個技術解決了什麼問題，以及又引入了哪些新的複雜度。重點不是追求最複雜的架構，而是在正確的時機，選擇符合網站規模與業務需求的解決方案。

從網站與客戶端的互動，重新面對一個又一個的問題，做出一個又一個的做法，處理網購的訂單服務，而且還有容許錯誤的狀況，也不會因為流量過多而癱瘓，這些都是時間的累積，造成技術的推進。