深度探秘

一句話定義，藏著三個逃不掉的後果

分散式系統到底是什麼

課本給的定義其實很樸素：

分散式系統 (distributed system) 是指：位於網路上不同電腦的硬體或軟體元件，只能靠傳遞訊息 (passing messages) 來溝通與協調動作的系統。

注意「只能靠傳訊息」這幾個字，它是整個學科的關鍵。這些電腦沒有共享的記憶體、沒有共享的時鐘，要合作就只能把資料打包成訊息，丟到網路上送給對方。它們可能在同一個房間，也可能在不同大陸。

從這個簡單定義，會必然推導出三個重要特性：

• 並行 (Concurrency)：網路上一堆電腦同時在跑程式是常態。我在我的電腦工作、你在你的工作，需要時才共享網頁或檔案。想要更多處理能力？再加電腦進來就好。但同時動作就會搶資源，於是「協調並行」變成反覆出現的主題。
• 沒有全域時鐘 (No global clock)：要合作就要對「事情何時發生」有共識，但網路上的電腦無法把時鐘對得完全一致，沒有一個單一、正確的全域時間。這直接來自「只能傳訊息」這件事。
• 獨立失效 (Independent failures)：每台電腦、每個程式都可能各自壞掉，而其他元件不會馬上知道。網路斷了、某台當機了，活著的程式甚至分不清對方是壞了還是只是變慢。

這三點不是缺點清單，而是這類系統的『物理定律』，後面所有章節都在處理它們帶來的後果。

生活妙喻

一群只能用對講機聯絡的登山隊

把分散式系統想成一支登山隊

想像一支登山隊，隊員分散在不同山頭，彼此看不到對方，只能用對講機 (傳訊息) 聯絡——這正是分散式系統。

• 並行：每個隊員都在各自路段同時往前走，沒有人需要等別人。要走更快？多派幾個人分頭進行。
• 沒有全域時鐘：你問「我們三點集合好嗎」，但每個人手錶都有點誤差，對講機講話也有延遲，於是隊伍永遠無法擁有一個完全一致的『現在幾點』。
• 獨立失效：如果有個隊員的對講機沒電了，他其實還在山上走，只是你聽不到他；你無法分辨他是『摔下山了』還是『只是收訊不好』。

對比一下：如果全隊綁在一條繩子上、肩並肩走（共享記憶體的單機程式），這些問題大多不存在。一旦『散開、只能喊話』，麻煩就全來了。這就是為什麼分散式系統這麼有挑戰性。

實用超能力

用三大特性當『體檢清單』分析任何系統

拿三大特性去『體檢』你身邊的系統

學會這三點，你就能快速判斷一個系統是不是分散式、會踩哪些坑。試著問三個問題：

1. 元件是不是只靠傳訊息溝通？ 是 → 它就是分散式系統。例如手機 App 與雲端後端、多台網頁伺服器之間。
2. 會不會有並行衝突？ 例如兩個人同時搶最後一張票，系統要避免兩人都買到。
3. 某個元件壞了，別人會不會誤判？ 例如 App 連不到伺服器，要分辨是『伺服器掛了』還是『我網路差』。

以一個訂票網站為例，用清單體檢：

下次看到任何網路服務，先用這三題掃一遍，你就抓得到它最可能出事的地方。

深度探秘

三個經典範例，三種不同的設計壓力

分散式系統長什麼樣

課本用三個範例，讓你看到分散式系統的多樣性與規模，而且每個範例都對設計者施加不同的壓力：

1. 網頁搜尋 (Web Search)

每月超過百億次搜尋，要為上百億個網頁建索引。Google 為此打造了史上最龐大複雜的分散式系統之一，重點包括：

• 遍佈全球資料中心的大量網路電腦
• 為超大檔案最佳化的分散式檔案系統
• 提供快速存取的結構化分散儲存系統
• 提供分散式鎖與一致同意的鎖服務
• 管理超大規模平行運算的程式設計模型

壓力來源：資料量極大、要高速持續讀取。

2. 大型多人線上遊戲 (MMOGs)

上萬名玩家同時沉浸在同一個虛擬世界。最大的 EVE Online 反而用 client-server，把世界狀態集中在伺服器叢集，再依負載把『星系』分配到不同電腦；EverQuest 則用多伺服器分散架構；學界還在研究 peer-to-peer 的去中心化做法。

壓力來源：快速回應與一致的共享世界。

3. 金融交易 (Financial Trading)

強調事件 (events) 的傳遞與處理：股價下跌、失業數據發布都是事件，要可靠、即時地送給大量關注者。系統用 adapter 把各種格式 (Reuters、FIX) 轉成共同格式，再用複雜事件處理 (CEP) 找出交易機會自動下單。

壓力來源：異質事件來源與即時樣式偵測。

生活妙喻

圖書館、線上桌遊、新聞快訊台

用三個生活場景理解三個範例

• 網頁搜尋 = 一座超大圖書館的編目團隊：書 (網頁) 多到上百億本，還不斷新增。要讓你『搜一個詞就秒回相關書名』，背後得有一支龐大團隊、特製的書架與索引系統日夜整理。重點是『東西太多』。

• MMOGs = 一場萬人同桌的線上桌遊：所有人要看到同一個棋盤，而且你一動別人馬上看到。為了不卡，主辦方把棋盤分區 (星系) 交給不同桌長 (電腦) 管理；玩家走到哪區就由那桌長負責。重點是『又要快、又要大家看到一致畫面』。

• 金融交易 = 一間新聞快訊編輯台：四面八方的快訊 (股價、數據) 用不同語言 (格式) 湧進來，編輯台先用翻譯員 (adapter) 統一成同一種語言，再用自動偵測員 (CEP) 盯著『若 A 發生接著 B 發生，就立刻行動』的樣式。重點是『把雜亂事件即時整理成行動』。

同樣是『一群電腦合作』，但圖書館怕的是量、桌遊怕的是慢、快訊台怕的是亂與慢。

實用超能力

先問『主要壓力是什麼』，再選架構

拿到一個系統，先問它『最怕什麼』

這三個範例教我們一個實用思路：架構沒有最好，只有最適合。先辨認主要壓力，再選架構。

主要壓力是『資料量極大、要高速讀』
   → 走分散式儲存 + 大規模平行運算 (像搜尋)

主要壓力是『即時回應 + 一致畫面』
   → 可考慮集中式 client-server 叢集，靠分區降載 (像 EVE Online)

主要壓力是『大量異質事件即時處理』
   → 走事件導向 (event-based) + 複雜事件處理 (像金融)

值得注意的反直覺一課：最大的線上遊戲 EVE Online 反而選了集中式 client-server，因為單一份世界狀態更好管理、更容易維持一致，再用『把高負載星系分到專屬電腦』來解決效能。這提醒我們：

去中心化不一定比較好；集中式換來的『一致性與好管理』有時更值錢。

下次設計系統時，別急著套流行架構，先問：『我最大的壓力是量、是快、還是亂？』

深度探秘

把各種網路黏成一片，再讓裝置隨處連線、自動找服務

兩股趨勢：網路無所不在、運算無所不在

普及網路與現代 Internet

現代 Internet 是一大堆不同種類網路互連而成：有線、WiFi、WiMAX、Bluetooth、3G 行動網路…種類還一直增加。它最了不起的成就，是用一套共同的 Internet 協定，讓『任何地方的程式都能對任何地方的程式送訊息』，把底層五花八門的網路差異遮蔽 (abstract over) 掉。

幾個關鍵角色：

• intranet (內部網路)：公司或組織自管的子網路，常用 firewall (防火牆) 保護。
• firewall：靠過濾進出訊息來保護 intranet，可依來源、目的或服務類型過濾。最強的防火牆其實是『根本不連上 Internet』。
• ISP：提供寬頻與連線，讓個人與小組織接上 Internet。
• backbone (骨幹)：高傳輸量的網路連線 (光纖、衛星等)，把各 intranet 串起來。

行動與無所不在運算

裝置變小、無線普及，催生兩個重疊但不同的概念：

• 行動運算 (Mobile computing)：使用者在移動中或在外地仍能透過隨身裝置存取資源；衍生出情境感知 (location/context-aware) 運算。挑戰是連線時有時無、甚至斷線。
• 無所不在運算 (Ubiquitous computing):把許多小而便宜的運算裝置藏進日常環境 (家裡、辦公室)，小到讓人幾乎察覺不到。

兩者的差別：行動運算強調『人在移動』，無所不在運算強調『裝置藏在環境裡』。而當訪客帶著裝置走進陌生環境、要臨時用當地的印表機時，就需要 spontaneous interoperation (自發互通) 與 service discovery (服務發現)。

生活妙喻

萬國通用的郵政系統，加上隨身翻譯機

兩個比喻

Internet 像萬國通用的郵政系統

世界上有飛機、貨船、卡車、機車快遞 (各種網路)，速度規格都不同。但只要你把信寫好、貼上標準地址 (Internet 協定)，郵政系統就能把它從任何角落送到任何角落，你完全不用管中途換了幾種交通工具——這就是『遮蔽底層差異』。

• intranet = 一棟有門禁的公司大樓
• firewall = 大樓警衛，檢查誰能進出
• backbone = 城際高速公路
• ISP = 幫你家接上馬路的承包商

行動 vs 無所不在運算：旅人 vs 智慧旅館

• 行動運算像一位帶著隨身翻譯機到處旅行的人：不管走到哪個國家，都能繼續處理自己的事，重點在『人會動，服務跟著走』。
• 無所不在運算像一間到處藏著感應器的智慧旅館：燈、冷氣、窗簾自己感應你而動作，你幾乎不會注意到有電腦。重點在『裝置藏在環境裡』。

當這位旅人走進這間智慧旅館，想用房間裡的印表機印登機證——他的手機得臨時跟陌生印表機搭上線 (自發互通)，還要先找到那台印表機 (服務發現)。

實用超能力

看穿一個情境用到了哪些角色與機制

拆解一個真實情境

課本給了經典情境：一位訪客帶著筆電、手機、數位相機到別的公司開會。我們用一張圖看清各裝置走哪條路、用到哪些機制：

flowchart TD
  A[訪客的筆電] -->|host 無線 LAN 經 gateway| B[host intranet]
  C[訪客的手機] -->|3G 行動網路| D[Internet]
  E[訪客的數位相機] -->|個人區域無線網路 約十公尺| F[會議室印表機]
  B --> D
  F --> B
  D --> G[home intranet 的資源]

從這張圖你能讀出實用觀念：

• 同一個人可能同時用三種無線連線，各走各的路徑。
• 相機直接連印表機，只需要兩者之間的無線連線，不必經過整個網路。
• 要讓訪客的裝置在陌生網路馬上能用當地服務，挑戰在於讓自發互通又快又方便——這就是 service discovery 要解決的事。

實務上，當你在咖啡廳用筆電投影、用手機 GPS 導航、用 AirDrop 傳照片給旁邊的人，你正在同時體驗『普及網路 + 行動 + 無所不在 + 自發互通』。學會這套詞彙，你就能精準說出每個動作背後的機制。

深度探秘

會跑的媒體要趕時間，運算可以像水電一樣租

兩個趨勢：分散式多媒體、把運算當公用事業

分散式多媒體系統

多媒體支援指『以整合方式支援多種媒體類型』。媒體分兩種：

• 離散媒體 (discrete media)：圖片、文字訊息等，沒有時間維度。
• 連續媒體 (continuous media)：音訊、視訊等，有時間維度。

連續媒體最關鍵的特性是：它的完整性取決於保留元素間的即時時間關係。例如視訊要維持一定的每秒幀數 (throughput)，即時串流還要保證每幀的最大延遲 (latency)。如果幀來得忽快忽慢，影片就會卡頓、不同步——這正是服務品質 (Quality of Service, QoS) 的一個例子。

Webcasting (網路廣播) 就是典型應用：把連續媒體 (音訊/視訊) 在 Internet 上廣播。它對底層基礎設施提出要求：支援多種編碼/加密格式、提供 QoS 機制、做資源管理與排程、在無法滿足 QoS 時提供適應 (adaptation) 策略。

把分散式運算當成公用事業

隨基礎設施成熟，業界把分散式資源視為商品或公用事業 (utility)，就像水或電——資源由供應商提供，使用者用租的而非買斷。可租的包括：

• 實體資源：儲存、運算節點、資料中心。關鍵技術是作業系統虛擬化 (virtualization)，你拿到的可能是虛擬節點而非實體機器。
• 軟體服務：email、行事曆等，靠 web services 等標準互通。

這個願景的名字就是雲端運算 (cloud computing)——把『運算當服務、按用量付費』。雲端通常建在叢集電腦 (cluster computer) 上：一群緊密合作、對外像一台高效能電腦的互連電腦，常用便宜的商品硬體 (如一堆 Linux PC 或 blade server) 拼出規模。

生活妙喻

傳送帶上的壽司 vs 自來水

兩個比喻

連續媒體像迴轉壽司的傳送帶

• 離散媒體像一張照片：你慢慢看、隨時看都行，沒有時間壓力。
• 連續媒體像迴轉壽司的傳送帶：壽司 (影格) 要以穩定速度、準時送到你面前。如果忽快忽慢，畫面就會卡頓；如果太慢，你就會餓 (緩衝不足、影片轉圈圈)。

『保證壽司準時、穩定地送來』這件事，就是 QoS。要做到，廚房得事先保留好食材與人力 (保留資源)；做不到時，就得改上比較簡單的菜 (adaptation，例如自動降畫質)。

雲端運算像用自來水

以前你想用水，得自己挖一口井 (買伺服器)：花大錢、要自己維護、用不用都得養著。

雲端運算把運算變成自來水：你只要打開水龍頭 (連上服務)，用多少算多少錢，不用煩惱水從哪來、水塔多大。背後的自來水廠就是叢集電腦——很多便宜管線與幫浦 (商品 PC / blade) 合力供應大量的水。虛擬化則像把一條大水管分裝成很多戶人家各自的水表，彈性又好管理。

實用超能力

判斷一個需求要不要 QoS、適不適合上雲

兩個實用判斷

判斷一：這個需求需要 QoS 嗎?

問自己：資料有沒有時間維度、晚到會不會毀掉體驗?

只要是『串流、即時、會卡頓影響體驗』的，就要認真規劃 QoS 與 adaptation。

判斷二：這個服務適合上雲嗎?

雲端的核心價值是『租用、按用量付費、不必自己養硬體』。它特別適合：

• 負載會大起大落：用叢集 + 虛擬化彈性擴縮，省得自己買一堆閒置機器。
• 想讓終端裝置很輕薄：因為運算放雲端，連簡單的桌機或平板都能用上強大資源。

需求負載忽高忽低、不想養機房
   → 上雲，靠叢集 + 虛擬化彈性租用
需求是即時連續媒體
   → 先確認雲端與網路能提供足夠 QoS，否則準備 adaptation

把這兩把尺記住，你看任何產品需求時，就能立刻說出『要不要 QoS、適不適合上雲』。

深度探秘

資源被關在電腦裡，只能透過一扇『服務之窗』存取

為什麼資源要透過服務存取

建構分散式系統最主要的動機就是共享資源 (resource sharing)。我們天天在共享：印表機 (硬體)、檔案 (資料)、搜尋引擎 (特定功能)。

但有個物理事實：資源被實體封裝在某台電腦裡，其他電腦只能透過通訊來存取它。所以課本給了幾個關鍵詞：

• 服務 (service)：系統中管理一組相關資源、並把功能對外呈現的部分。我們透過 file service 存取共享檔案、透過 printing service 列印。
• 我們對服務的唯一存取方式，就是它對外提供的那組操作 (operations)。例如 file service 提供 read、write、delete。

為什麼要限制成『一組明確操作』? 一半是良好的軟體工程習慣 (封裝)，一半是物理現實：資源在別台電腦，必須由一個程式提供通訊介面，才能可靠、一致地被存取與更新。

client、server 與 remote invocation

• server (伺服器)：在網路電腦上執行的程式 (process)，接受其他電腦程式的請求、執行服務並回應。
• client (用戶端)：發出請求的程式。整套做法叫 client-server computing。
• 當 client 請求某操作，我們說它對 server 發起一次操作 (invokes an operation)；從送出請求到收到回應的完整來回，稱為遠端呼叫 (remote invocation)。

幾個容易考的細節：

• client 與 server 是『角色』而非機器：同一個程式可以既是 client 又是 server (server 有時會去呼叫別的 server)。這兩個詞只針對單一次請求而言。
• client 主動 (發請求)、server 被動 (收到請求才醒來)；server 持續運行，client 只活在它所屬應用程式存在的期間。
• 在物件導向的分散式系統裡，資源可封裝成物件 (object)，由 client object 對 server object 呼叫方法 (method)。

瀏覽器就是 client，它向 web server 請求網頁——這正是下一章 WWW 案例的核心。

生活妙喻

餐廳的點餐窗口

把服務想成餐廳的點餐窗口

想像一間餐廳：

• 廚房裡的食材與廚具 (資源) 你不能直接伸手去拿——它們被封裝在廚房裡。
• 你只能透過點餐窗口 (服務)，用菜單上有的選項 (一組明確操作) 來互動：你能『點餐、加點、退單』，但不能說『讓我進廚房自己翻冰箱』。
• 你 (client) 主動走到窗口點餐 (發請求)；廚房/服務生 (server) 平常待命，收到點單才動作 (被動回應)。
• 從你『開口點餐』到『餐點送到面前』這一整個來回，就是一次 remote invocation。

幾個對應得很妙的細節：

• 角色不是身分：一位服務生可能對顧客是 server，但他轉身向廚房點貨時，他又變成廚房的 client。角色只看『這一次互動』。
• 菜單就是介面：你只能點菜單上有的東西 (read/write/delete)，這保證了廚房能可靠、一致地出餐，不會被亂搞。

這個比喻幫你記住核心觀念：封裝資源、只開放明確操作、主動點餐 vs 被動出餐。

實用超能力

在任何系統裡指出 client、server 與操作介面

用 client-server 視角拆解真實系統

學會這套詞彙，你就能把任何網路系統畫成清楚的角色圖。以瀏覽器看網頁為例：

flowchart LR
  A[瀏覽器 client] -->|請求 取得網頁| B[web server]
  B -->|回應 網頁內容| A
  B -->|它自己也當 client| C[資料庫 server]
  C -->|回傳查詢結果| B

從這張圖讀出三個實用重點：

1. 找出操作介面：web server 只回應一小組操作 (主要是取得資源)。指認介面，你就知道『這個服務能做什麼、不能做什麼』。
2. 角色會切換：web server 對瀏覽器是 server，但它去查資料庫時又變成 client。分析系統時要逐次請求判斷角色。
3. 主動 vs 被動：瀏覽器關掉了，網站照樣運行 (server 持續存在、client 短命)。

實務檢核清單，拿到任何系統先問:

• 誰主動發請求 (client)? 誰待命回應 (server)?
• 這個服務對外開放哪些操作 (介面)? 哪些被刻意封起來?
• 有沒有哪個元件同時扮演兩種角色?

回答完這三題，你就掌握了這個系統的互動骨架，也為理解後面所有架構打好地基。

深度探秘

東西五花八門 (異質性)，還要能不斷加裝與重做 (開放性)

挑戰一：異質性 (Heterogeneity)

異質性就是『變化與差異』。它出現在五個層面：

• 網路 (Ethernet、WiFi…)
• 電腦硬體 (例如整數的位元組順序 byte ordering 有兩種)
• 作業系統 (UNIX 與 Windows 的訊息收發 API 不同)
• 程式語言 (字元、陣列、紀錄的表示法不同)
• 不同開發者的實作 (沒有共同標準就無法互通)

如何弭平這些差異? 兩大武器：

• 共同標準：例如所有連上 Internet 的電腦都用 Internet 協定溝通，網路差異就被遮蔽。
• 中介軟體 (middleware)：一層軟體，提供程式設計抽象，同時遮蔽底層網路、硬體、OS、語言的異質性。例如 CORBA (跨語言)、Java RMI (單一語言)。中介軟體還提供統一的運算模型，如 remote object invocation。

另一個相關概念是行動程式碼 (mobile code)：能從一台電腦傳到另一台執行的程式碼 (如 JavaScript)。難點在於執行檔通常綁定特定指令集與 OS。虛擬機器 (virtual machine) 是解法：編譯器產生 VM 的程式碼而非特定硬體碼，例如 Java 編譯成 bytecode 由 JVM 解譯，每種電腦只要實作一次 JVM。

挑戰二：開放性 (Openness)

開放性決定系統能否被擴充與重新實作。對分散式系統而言，主要看『能否加入新的資源共享服務、並被各種 client 使用』。

達成開放性的關鍵步驟：

公開 (publish) 關鍵軟體介面的規格與文件。

例如 Internet 的設計者推出 RFC (Requests For Comments) 系列文件，公開通訊協定規格；W3C 公開 Web 相關標準。介面公開後，不同人寫的元件才能整合。

開放系統的三個重點：介面被公開、提供統一通訊機制與公開介面存取資源、可由不同廠商的異質軟硬體組成 (但每個元件都須仔細測試是否符合標準)。

生活妙喻

聯合國同步口譯 vs 公開規格的樂高

兩個比喻

異質性與中介軟體像聯合國的同步口譯

聯合國裡各國代表講不同語言 (硬體、OS、語言的差異)，彼此根本聽不懂。但只要每個人戴上同步口譯耳機 (中介軟體)，講英文的、講法文的都能順暢開會——耳機遮蔽了語言差異，還提供統一的『開會方式』。

而 mobile code + 虛擬機器像一份『用世界語寫的劇本』：劇本 (bytecode) 本身不分國籍，只要每個劇團都養一位該語言的導讀員 (JVM)，同一份劇本就能在任何國家上演。

開放性像規格公開的樂高

樂高為什麼能無限擴充? 因為它的凸點規格是公開的 (published interface)。

• 任何廠商只要照規格做積木，就能跟現有積木拼在一起 (加入新服務、被各種 client 使用)。
• 你不會被單一廠商綁死 (獨立於個別 vendor)。
• 但前提是：每塊積木都得確實符合規格，否則拼不起來 (元件須測試是否符合標準)。

相反地，若某個玩具的接頭規格保密，別人就無法做相容配件——那就是封閉系統。Internet 的 RFC、Web 的 W3C 標準，就是那份『公開的樂高凸點規格』。

實用超能力

用一張圖看懂中介軟體站在哪、判斷系統夠不夠開放

中介軟體站在哪一層?

flowchart TD
  A[分散式應用程式] --> B[中介軟體 middleware]
  B --> C[作業系統]
  C --> D[電腦硬體與網路]
  B -. 遮蔽 OS 語言 硬體差異 .-> A

中介軟體夾在『應用程式』與『OS』之間，向上提供統一的程式設計模型，向下吸收各種異質差異。寫應用的人因此可以少操心底層是誰。

實務判斷一個系統夠不夠開放

問三個問題：

1. 關鍵介面有沒有公開? 有公開文件/規格 → 偏開放；藏起來 → 偏封閉。
2. 第三方能不能加入新服務、做相容元件? 能 → 開放；只能用原廠的 → 封閉。
3. 會不會被單一廠商綁死? 能換廠商 → 開放的好處之一。

想讓系統未來能不斷擴充、被很多人接
   → 先把關鍵介面公開 (像 RFC W3C)
想讓不同語言 不同 OS 的元件互通
   → 引入中介軟體吸收異質性

下次評估一個平台或 API，先看它『介面公不公開、能不能被第三方擴充』，你就能一眼判斷它的開放程度與長期擴充潛力。

深度探秘

資訊要守住三件事，系統要在暴增時還撐得住

挑戰三：安全 (Security)

分散式系統裡的資訊往往很有價值，安全因此至關重要。資訊安全有三個要素：

• 機密性 (Confidentiality)：防止洩漏給未授權者。
• 完整性 (Integrity)：防止被竄改或破壞。
• 可用性 (Availability)：防止存取資源的手段被干擾。

在分散式系統中，client 把請求透過網路送給 server，挑戰有兩層：

1. 安全地傳遞敏感資訊 (如信用卡號)；
2. 正確辨識遠端的使用者或代理人身分 (server 要確認對方真的是醫師；user 要確認對方真的是那家銀行)。

這兩者都能靠加密技術 (encryption) 解決，已廣泛用於 Internet。但有兩個尚未完全解決的安全挑戰：

• 阻斷服務攻擊 (Denial of Service, DoS)：用海量無意義請求灌爆服務，讓正常使用者無法使用。目前多靠事後抓人懲處，並非根本解法。
• 行動程式碼的安全：收到的執行檔 (如 email 附件) 可能表面顯示有趣圖片，實際卻在偷存取本機資源或參與 DoS。

挑戰四：可擴展性 (Scalability)

系統若在資源數與使用者數大幅增加時仍維持有效，就稱為可擴展。設計可擴展系統的挑戰：

• 控制實體資源成本：n 個使用者所需資源量最多應為 O(n) (與 n 成正比)。例如 1 台檔案伺服器支援 20 人，2 台就該支援 40 人。
• 控制效能損失：管理大小與使用者成正比的資料時，階層式結構比線性結構好。階層式存取時間為 O(log n)，效能損失不應比這更糟。
• 防止軟體資源耗盡:例如 32 位元 IP 位址不夠用，只好改用 128 位元 (IPv6)。但過度為未來預留也有代價 (佔更多空間)。
• 避免效能瓶頸:演算法應去中心化。例如 DNS 把名稱表分割給遍佈各地的伺服器、在地管理，取代了早期單一主檔的瓶頸。常熱門的資源可用快取 (caching) 與複製 (replication) 提升效能。

生活妙喻

保險箱三道防線 vs 連鎖店展店

兩個比喻

安全像保險箱的三道防線

• 機密性像保險箱鎖好不讓外人看見內容。
• 完整性像在文件上加防偽封條，一旦被動過手腳就看得出來。
• 可用性像確保鑰匙與通道暢通，需要時你拿得到東西。

而兩個難解問題：

• DoS 像一群人故意擠爆銀行大門，讓真正要辦事的客戶進不去——你很難只靠『門口檢查』擋掉，因為他們看起來都像顧客。
• 行動程式碼風險像有人塞給你一個包裝精美的禮物盒，你不知道拆開後是蛋糕還是炸彈。

可擴展性像連鎖店展店

一家餐廳生意太好排隊排到天邊，怎麼辦?

• 控制成本 O(n)：客人加倍，分店數大致也加倍就好，不該『客人加倍卻要蓋十倍的店』。
• 避免瓶頸 (去中心化)：別讓全國訂位都打到同一支總機 (單一主檔的瓶頸)，改成各分店自己接訂位 (DNS 把名稱表分割、在地管理)。
• 快取與複製：最熱賣的招牌菜先大量備好放在每家分店 (replication)、或把常被問的菜單貼在門口 (caching)，省得每次都跑回中央廚房。

實用超能力

用 CIA 三要素稽核安全、用瓶頸思維設計擴展

工具一：用 CIA 三要素稽核任何系統的安全

拿到一個需求，逐項問：

再加一句提醒：身分辨識同樣關鍵——不只要藏好訊息，還要確定對方真的是他宣稱的人。

工具二：用『瓶頸思維』設計可擴展系統

問 1 使用者加倍 資源成本會不會也只加倍 (O(n))?
   不會 → 重新設計, 別讓成本爆炸
問 2 有沒有一個所有請求都會打到的單點?
   有 → 去中心化 (像 DNS 分割名稱表)
問 3 有沒有被超熱門存取的資源?
   有 → 用快取與複製分散壓力

實戰例子：設計一個全球用戶都會查的『商品名稱對應資料』服務，照課本智慧——名稱用階層式設計 (O(log n) 存取)、把資料分割並複製到各地伺服器在地服務，就能在使用者暴增時把效能損失壓到最低、避開單點瓶頸。

把 CIA 與瓶頸思維變成你的反射動作，安全與擴展兩大挑戰你就抓得住七成。

深度探秘

壞了只壞一部分、多人會搶資源、把分散藏起來、還要準時

挑戰五：錯誤處理 (Failure handling)

分散式系統的失效是部分失效 (partial)——有些元件壞了，其他還在跑，這讓處理特別困難。對付失效有五招：

• 偵測 (Detecting)：有些能偵測 (如 checksum 抓出損壞資料)，有些 (如遠端伺服器當機) 難以偵測，挑戰是『懷疑卻無法確定』時還能撐住。
• 遮蔽 (Masking)：把已偵測的失效藏起來或減輕，例如訊息沒到就重傳、資料寫到兩顆硬碟。但不保證最壞情況有效。
• 容忍 (Tolerating)：有些失效乾脆讓 client 容忍。例如瀏覽器連不到伺服器，不會讓你永遠空等，而是告知問題、讓你稍後再試。
• 復原 (Recovery):設計軟體讓當機後資料能回復或『回滾 (roll back)』到一致狀態。
• 冗餘 (Redundancy)：用備援元件容錯，例如路由間至少兩條路徑、DNS 名稱表至少複製在兩台伺服器、資料庫複製到多台。

分散式系統因此能在硬體故障時維持高可用性 (availability)：某元件壞了，只影響正在用它的工作。

挑戰六：並行 (Concurrency)

多個 client 可能同時存取共享資源。若把每個請求一次處理一個，吞吐量太低；於是通常允許並行處理。但若多個執行緒在同一物件內未受控地交錯操作，就可能產生不一致結果 (課本的拍賣例子：兩筆出價交錯後金額被張冠李戴)。

任何代表共享資源的物件，都必須負責在並行環境下仍正確運作。

做法是把操作同步 (synchronize)，例如用 semaphore 等技術，讓資料保持一致。

挑戰七：透通性 (Transparency)

透通性是『對使用者與程式設計師隱藏元件的分散事實』，讓系統看起來像一個整體。RM-ODP 定義八種透通性：存取、位置、並行、複製、失效、移動 (mobility)、效能、擴展。其中存取透通性與位置透通性最重要，合稱網路透通性。例如 email 位址不必知道對方實體位置 (位置+存取透通)；email 會一直重試直到送達 (失效透通)。

挑戰八：服務品質 (Quality of Service)

有了功能還要問品質。主要的非功能性質是可靠性、安全性、效能，再加適應性。QoS 後來特指系統滿足時限 (timeliness) 保證的能力，例如準時顯示每一幀視訊。要做到，關鍵資源必須被保留 (reserve)，由資源管理者提供保證；無法滿足的保留請求會被拒絕。

生活妙喻

公司部門、共用白板、隱形管家、預約包廂

四個比喻

部分失效像一間公司某個部門請假

如果是單機程式，像一個人感冒就全身癱瘓；分散式系統像一間公司，會計部請假，業務部照常上班 (部分失效)。麻煩的是——你打電話到會計部沒人接，分不清是請假還是只是去洗手間 (難以偵測的失效)。對策：重要文件多印幾份放不同部門 (冗餘)、電話沒人接就告知並請稍後再撥 (容忍)。

並行像大家搶寫同一塊白板

兩個人同時上去改同一行字，若沒人協調，最後白板上會是東拼西湊的錯字 (拍賣金額被張冠李戴)。解法是裝一支白板筆，誰拿到筆才能寫 (同步 / semaphore)。

透通性像一位隱形管家

你說『幫我拿那份檔案』，管家自己跑去不知哪個房間 (哪台伺服器) 拿來，你完全不必知道它放哪、是不是有副本、中途有沒有出小狀況——這就是把分散細節藏起來。最重要的兩種：用一樣的方式拿東西 (存取透通)、不必知道東西放哪 (位置透通)。

QoS 像預約餐廳包廂

你要辦一場準時開始的活動，不能『有空位再說』。你得事先預訂包廂與人手 (保留資源)，餐廳才能保證準時上菜 (時限保證)；若資源被訂滿，預約直接被拒絕，而不是讓你到場撲空。

實用超能力

對失效備好五招、看穿系統有哪些透通性

工具一：面對失效，備齊五招清單

flowchart TD
  A[元件可能失效] --> B{能偵測嗎}
  B -->|能| C[遮蔽 重傳或寫雙硬碟]
  B -->|難偵測| D[容忍 告知用戶稍後再試]
  C --> E[復原 當機後回滾到一致狀態]
  D --> E
  E --> F[冗餘 多條路徑 多份複製持續提供服務]

設計時別只想『不要壞』，而是假設一定會壞，然後問：能偵測嗎? 偵測不到怎麼撐? 壞了如何回復? 要不要備援?

工具二：替系統盤點透通性

拿一個系統，逐項檢查它『藏住了什麼』：

記住：存取 + 位置 = 網路透通性，最關鍵。

工具三：要不要做 QoS?

只要需求帶『時限』(每秒幾幀、幾毫秒內回應)，就要保留資源並準備在資源不足時拒絕新請求或降級。把這三套工具內化，你就能系統化地處理失效、並行、透通與品質四大挑戰。

深度探秘

一個開放的超文本系統，站在三根標準柱子上

World Wide Web 是什麼

Web 是一個不斷演化、用來發布與存取資源/服務的系統，1989 年誕生於 CERN，最初是物理學家交換文件的工具。它的關鍵特色是超文本 (hypertext) 結構：文件裡含有連結 (hyperlinks)，指向其他文件與資源，織成一張遍及全球的『連結之網』。

Web 是一個開放系統 (open system)，能在不破壞既有功能下被擴充與重做。它的開放展現在兩方面：

• 運作建立在自由公開、廣泛實作的通訊與內容標準上：任何符合標準的瀏覽器都能向任何符合標準的伺服器取資源。
• 對可發布的資源類型開放：發明新格式 (如新圖檔)，立刻就能發布在 Web 上，瀏覽器再用 helper / plug-in 支援呈現。

三大標準技術元件

Web 的基本架構從沒大改，建立在三根柱子上：

• HTML (HyperText Markup Language)：描述網頁的內容與版面。用標籤 (tags)(以角括號包住，如 <p>) 標示標題、段落、表格、圖片與連結。重點：只有瀏覽器 (不是伺服器) 會解讀 HTML；伺服器只負責告知內容類型 (常從副檔名 .html 推斷)。
• URL (Uniform Resource Locator)：用來識別與定位資源。每個完整 URL 有兩大部分：scheme : scheme-specific-identifier。scheme 宣告類型 (http、ftp、mailto、tel…)，這讓 Web 對『可存取的資源類型』保持開放。
• HTTP (HyperText Transfer Protocol)：規定瀏覽器等 client 如何與 web server 互動。

HTTP URL 的一般形式：

http:// servername [:port] [/pathName] [?query] [#fragment]

方括號內為選填。沒寫 port 預設 80；沒寫 pathName 就取預設首頁;? 後是查詢字串;# 後是片段識別碼 (由瀏覽器下載整份檔案後自行尋找)。

生活妙喻

雜誌排版 vs 門牌地址 vs 取貨對話

用三個生活場景記住三大基石

把『請朋友幫你拿一本書』整個流程拆開：

HTML 像雜誌的排版指示

HTML 就是寫給排版師的指示：這裡放標題、這段是內文、這裡插一張圖、這個詞做成可點的連結。注意一個關鍵：排版指示只有排版師 (瀏覽器) 看得懂並照著畫出來；印刷廠 (伺服器) 只負責把這份稿子原封不動寄出，並在外面貼張標籤說『這是 HTML 稿』(內容類型)。

URL 像門牌地址

URL 就是資源的完整地址：

http://  www.cdk5.net  /WebExample/moon.html
  ↑          ↑               ↑
用哪種協定   哪一棟 (伺服器)   裡面哪個房間 (路徑)

• scheme (http/ftp/mailto) = 用哪種交通方式 (走路、坐船、寄信)。
• servername = 哪一棟樓 (哪台伺服器)。
• pathName = 樓裡哪個房間 (哪份資源)。
• #fragment = 房間裡哪一頁 (文件中的某段)，由你進房後自己翻到。

HTTP 像取貨的標準對話

HTTP 就是你跟櫃台的固定問答腳本：你說『我要 moon.html 這份』(request)，櫃台找得到就把內容遞給你 (reply)，找不到就回你一句熟悉的『404 找不到』。

實用超能力

親手拆解一個 URL、看懂一次取頁流程

工具一：把任何 HTTP URL 拆成零件

拿課本的例子練手：

看懂邊界符號 (/、?、#)，你就能立刻讀懂瀏覽器網址列在做什麼。

工具二：跟著走一次取頁流程

flowchart LR
  A[使用者點 Moon 連結] --> B[瀏覽器查出對應 URL]
  B --> C[對 web server 發 HTTP 請求]
  C --> D[server 找到資源回傳內容並標示類型]
  D --> E[瀏覽器解讀 HTML 並渲染成網頁]
  E --> F[遇到圖片再各發一次請求取得]

這條流程把三大基石串起來：連結文字背後是 URL → 用 HTTP 一問一答 → 拿回 HTML 由瀏覽器渲染。

為什麼 Web 這麼成功?

課本歸納三點，值得當設計準則：(1) 發布資源很容易、(2) 超文本結構適合組織各類資訊、(3) 系統架構開放——而且標準簡單、早早公開。下次你設計任何平台，想要它長壽又能被廣泛採用，這三點就是黃金範本。

深度探秘

URL 不只指向檔案，還能指向會跑的程式

從『取檔案』到『用服務』

前一節談的是取出存在檔案裡的網頁 (靜態內容)。但使用者更多時候是在和服務互動：在網路商店填表單、送出查詢。這時：

• 表單 (web form) 是一個含輸入元件 (文字框、核取方塊) 的網頁。送出時，瀏覽器把使用者填的值打包成 HTTP 請求送給伺服器。
• 因為結果取決於使用者輸入，所以 URL (或其開頭) 指向的是伺服器上的一支程式，而非一個檔案。
• 小量參數常用 GET 放在 URL 的 query 部分；也可用 POST 當作額外資料夾帶。

例如 http://www.google.com/search?q=obama 會在伺服器執行名為 search 的程式、傳入查詢字串 obama，程式產生 HTML 當輸出。關鍵洞見：

靜態檔案內容與動態產生的內容，對瀏覽器是透通的 (transparent)——它不知道也不在乎內容是讀檔還是程式現產的。

伺服器用來產生內容的程式稱為 CGI (Common Gateway Interface) 程式，常會查或更新資料庫。

把程式碼下載到瀏覽器執行

有時程式碼要跑在使用者的瀏覽器內：

• JavaScript：常隨網頁下載，提供比 HTML 標準元件更好的互動 (如即時檢查輸入)，還能只更新網頁的一部分而不重抓整頁。當資料的到達與使用者動作無關時，稱為非同步 (asynchronous)，對應技術即 AJAX (Asynchronous JavaScript And XML)。
• Applet：用 Java 寫、由瀏覽器自動下載執行的程式，可存取網路、提供客製介面。

Web Services 與 REST

瀏覽器之外，程式也能當 Web 的 client。但 HTML 不適合程式間互通——它是為『呈現給人看』而設計的。XML (Extensible Markup Language) 則用來以標準、結構化、自我描述的方式表示資料，可在應用間攜帶。

Web 資源提供服務專屬操作 (如下單、查訂單狀態)。REST (REpresentational State Transfer) 架構主張：每個資源都有 URL、且回應同一組操作 (GET、POST、PUT、DELETE)，以此換取擴展性；缺點是軟體運作可能較不嚴謹。

生活妙喻

點餐機 vs 現做料理 vs 萬用插座

三個比喻

靜態 vs 動態：超商貨架 vs 現點現做

• 靜態網頁像超商貨架上已經做好的便當：你拿了就走，每個人拿到的都一樣 (讀檔案)。
• 動態網頁像餐廳的現點現做：你填了點餐單 (表單)，廚房 (伺服器上的程式 / CGI) 依你的需求現場做一份給你 (依輸入產生 HTML)。

妙的是——你 (瀏覽器) 拿到餐點時，根本分不出是貨架上拿的還是現做的，這就是『靜態與動態對瀏覽器透通』。

下載程式碼到瀏覽器：把小幫手帶回家

JavaScript / applet 像餐廳附贈一個小幫手讓你帶回家：你在家填單時，小幫手當場幫你檢查有沒有填錯 (即時驗證)，不必每次都跑回餐廳問。AJAX 則像小幫手只去廚房補一道菜，而不是把整桌重做一遍 (只更新部分網頁)；而且這道菜什麼時候到不一定跟你的動作同步 (非同步)。

XML 與 REST：萬用插座與自帶說明的包裹

• XML 像一個自帶完整標籤說明的包裹：拆開就知道裡面是什麼、什麼型別、怎麼組裝 (自我描述)，所以不同機器 (程式) 都能讀懂，不像 HTML 只為『給人看』。
• REST 像規定每個房間都用同一款萬用插座：每個資源都有自己的地址 (URL)，而且都接受同一組標準操作 (GET/POST/PUT/DELETE)，誰來都能插，超好擴充。

實用超能力

判斷該用 GET/POST、程式碼放哪邊跑

工具一：這次互動該用 GET 還是 POST?

參數量很小 且只是查詢取資料
   → 用 GET, 把參數放在 URL 的 query 部分 (如 ?q=obama)
參數較多 或在送出資料 改變狀態
   → 用 POST, 把資料放在請求本體

工具二：這段程式碼該在哪邊跑?

口訣：要產生內容、碰資料庫 → 伺服器端；要即時回饋使用者 → 瀏覽器端。

工具三：設計 API 時要不要走 REST?

如果你希望 API 容易擴充、每個東西都有一致的存取方式，REST 很合適：給每個資源一個 URL、用統一的 GET/POST/PUT/DELETE。代價是較不嚴謹，需要額外文件說明各操作細節 (這也是後續 web services 框架要補的)。

把這三套判斷內化，你就能把第一章學到的所有觀念——client-server、資源、透通性、開放性——具體落地到真實的 Web 開發決策上。這正是用 WWW 當案例的用意：讓抽象概念變成你手上的工具。