分散式系統是什麼：三個讓它與眾不同的特性
一群電腦，只靠傳訊息合作——從這句簡單定義，會必然長出三個貫穿全書的「物理定律」
先把定義釘死：只能「傳訊息」，不能「共用記憶體」
你的筆電裡好幾個程式同時在跑，彼此靠共享記憶體互通有無——這不算分散式系統。課本給的定義很樸素：分散式系統是指，位於網路上不同電腦的元件，只能靠傳遞訊息（message passing）來溝通與協調動作的系統。
這些電腦可能在同一個房間，也可能在不同大陸——距離不是重點，重點是它們沒有共享的記憶體、沒有共享的時鐘，要合作就只能把資料打包成訊息，丟到網路上送給對方。
想像一支登山隊，隊員散在不同山頭，彼此看不到對方，只能靠對講機（傳訊息）聯絡——這正是分散式系統。如果全隊綁在一條繩子上、肩並肩走（單機、共享記憶體），大部分麻煩根本不存在。一旦「散開、只能喊話」，麻煩就全來了。
從這句簡單定義，會必然推導出三個重要特性——它們不是缺點清單，而是這類系統的「物理定律」，後面所有章節都在處理它們帶來的後果。
直接讀原文，旁邊就是白話
這是本章開場對「分散式系統」最直球的定義，附帶三個必然結果。原文放左邊，白話導讀放右邊——不逐句對齊，先讀懂原文的氣口，再看整段在說什麼。
這幾句話幾乎是整個學科的起點：分散式系統的元件「只能」靠傳訊息溝通協調——沒有共享記憶體、沒有近路可抄。作者接著指出，這個簡單定義會必然帶來三個後果：一是網路上一堆電腦同時在跑程式是常態（並行）；二是電腦彼此的時鐘永遠對不到完全一致，沒有一個放諸四海皆準的「現在幾點」（沒有全域時鐘）；三是每個元件都可能各自壞掉，而其他還活著的元件不會馬上知道（獨立失效）。這三點不是三個獨立的巧合，而是「只能傳訊息」這一件事，同時逼出來的三個必然結果。
「只能傳訊息」→ 沒有共用時鐘 → 沒有全域時間；「只能傳訊息」→ 偵測不到對方在幹什麼 → 獨立失效。三大特性全部源自同一個限制，不是三件不相干的事。
招牌互動：看三個節點各跑各的，還要協同
下面三個節點各自在忙自己的事。按「下一步」，看看「並行」「沒有全域時鐘」「獨立失效」怎麼在同一個場景裡輪番上演。
節點C故障後，A和B的程式沒辦法立刻判斷：C是當機了？網路斷了？還是只是暫時變慢？這正是獨立失效最麻煩的地方——就像對講機沒電的隊員，他可能還在山上走，只是你聽不到他。
把三大特性定格成一句話
動畫跑太快？這是它的靜態總結——三個從同一個定義長出來的必然特性。
網路上一堆電腦同時執行程式是常態，需要時才共享資源。想要更多處理能力？加電腦進來就好——但同時動作就會搶資源，協調並行是反覆出現的主題。
要合作就要對「事情何時發生」有共識，但網路上的電腦無法把時鐘對得完全一致——沒有一個單一、正確的全域時間。這是「只能傳訊息」的直接後果。
每台電腦、每個程式都可能各自壞掉，而其他元件不會馬上知道。活著的程式甚至分不清對方是壞了，還是只是變慢。
真實世界裡合作的電腦，往往連硬體、作業系統、程式語言都不一樣，這叫異質電腦（heterogeneous computers）——你不能假設對方跟你長得一樣，這也是後面章節反覆要處理的難題。
動手配配看：哪個案例最能體現哪個特性？
把下面三個真實案例，拖到它「最」能體現的那個特性上。配完按「對答案」。
三大特性其實同時存在每個案例裡——Google 搜尋一樣有節點會故障，遊戲伺服器一樣要並行處理成千上萬玩家。這個練習只是幫你抓住「這個案例最典型在說哪件事」。
同樣是「一群電腦合作」，怕的東西完全不同
課本用三個範例，讓你看到分散式系統的多樣性與規模，而且每個範例都對設計者施加不同的壓力。
每月超過百億次搜尋，要為上百億個網頁建索引。Google 為此打造了史上最龐大複雜的分散式系統之一：全球資料中心的大量電腦、專為超大檔案優化的分散式檔案系統、鎖服務、超大規模平行運算的程式設計模型。壓力來源：資料量極大、要高速持續讀取。
上萬名玩家同時沉浸在同一個虛擬世界。反直覺的是，最大的 EVE Online 反而用用戶端-伺服器（client-server），把世界狀態集中管理、依負載把「星系」分配到不同電腦。壓力來源：快速回應與一致的共享世界。
強調事件（events）的傳遞與處理：股價下跌、數據發布都是事件，要可靠、即時送給大量關注者。系統用 adapter 把各種格式統一，再用複雜事件處理（CEP）找出交易機會自動下單。壓力來源：異質事件來源與即時樣式偵測。
EVE Online 這個「最大的線上遊戲」，反而選了集中式架構——因為單一份世界狀態更好管理、更容易維持一致，再用「把高負載星系分到專屬電腦」解決效能問題。下次設計系統別急著套流行架構，先問：我最大的壓力是量、是快、還是亂？
小試身手
抓住這三大特性，你就摸到分散式系統的骨架了。來兩題：
先看看是什麼「趨勢」把我們推向這裡。往下捲。
推動分散式系統的趨勢：從隨身上網到雲端
網路變得無所不在、裝置變得又小又多——四股力量，把分散式系統從「教科書名詞」推成「你每天的日常」
為什麼是「現在」？
上一站我們認識了分散式系統的樣子。這一站要回答一個更根本的問題：這些系統為什麼會變成今天的規模、長成今天的樣子？書上指出，背後其實是幾股一直在加速的力量在推——
有線、WiFi、行動網路交織成一張無所不在的網，裝置隨時隨地都能連上。
裝置越做越小、越做越便宜，人可以帶著它移動，環境裡也藏著它。
大家要看直播、要視訊會議、要即時串流，這對系統提出全新的時間要求。
運算資源開始像水電一樣，被當成「用租的、按用量付費」的服務——也就是雲端運算。
你早上出門，手機自動從家裡 WiFi 切到行動網路；到了公司又自動接上公司 WiFi；用手機叫車、開視訊會議、把照片存上雲端相簿——這一整套「無縫」的體驗，正是這四股趨勢加在一起的結果。它們不是各自獨立的技術新聞，而是同一台巨大機器的四個齒輪。
直接讀原文，旁邊就是白話：普及網路
先看書上怎麼描述「現代 Internet」這件事——它的成就不是速度多快，而是把底層一堆不同的技術「藏」起來。
現代 Internet 其實是一大堆不同種類網路（有線、WiFi、行動網路……）硬湊在一起的大雜燴。它真正了不起的地方，是設計出一套共同的 Internet 協定——不管底層是光纖還是衛星訊號，程式完全不用管，訊息照樣送得到。書上把公司或組織自己管的那一塊子網路叫做 intranet，靠 firewall（防火牆） 過濾進出訊息來自保；而串起各個 intranet 的高速幹道，就叫 backbone（骨幹）。
世界上有飛機、貨船、卡車、機車快遞——速度和規格全不一樣。但只要信封上貼著標準地址（Internet 協定），郵政系統就能把信從任何角落送到任何角落，你完全不必管中途換了幾種交通工具。intranet 就像一棟有門禁的公司大樓，firewall 是站在門口檢查的警衛，backbone 是城際高速公路，ISP 則是幫你家接上馬路的承包商。
「人在動」跟「裝置藏起來」，是兩件不同的事
裝置越做越小、無線越來越普及，催生出兩個常被搞混、但其實不同的概念：
使用者在移動中、或到了平常不在的地方，仍能透過隨身裝置存取資源。重點是「人會動，服務要跟著走」。挑戰是連線時有時無、甚至斷線——也就是 斷線操作要處理好。
把許多小而便宜的運算裝置藏進日常環境（家裡、辦公室），小到讓人幾乎察覺不到。重點是「裝置藏在環境裡，人不用特別意識到電腦存在」。
書上舉了一個很真實的情境：一位訪客帶著筆電、手機、數位相機去別家公司開會。同一個人身上，同時跑著三種不同距離、不同技術的無線連線——筆電接上主辦方的 WiFi、手機用行動網路連 Internet、相機則用短距離的個人無線網路直接連會議室印表機。
相機把照片送去印表機，只需要相機跟印表機之間的無線連線——完全不必繞經整個網路。但問題是：相機怎麼知道「這間陌生會議室裡有一台印表機」？這就需要 服務發現（service discovery），讓裝置和從沒見過的本地服務快速、方便地搭上線——書上稱這種能力為 自發互通（spontaneous interoperation）。
招牌互動：手機在網路間漫遊，服務怎麼不中斷？
行動運算最有感的體驗，就是「你根本沒發現網路換過」。按「下一步」，看手機怎麼在 WiFi 熱點、行動基地台、雲端服務之間悄悄切換。
這種切換看起來理所當然，其實是系統刻意處理了「連線時有時無、甚至斷線」這個行動運算的老問題。手機、基地台、雲端服務三方要協調好，才能讓你完全感覺不到底層換了一條路。
多媒體要「準時」，雲端要「像水電一樣租」
後兩股趨勢，一個管「時間」，一個管「所有權」。先看多媒體：影片、語音這類 連續媒體 跟圖片、文字這類離散媒體完全不同——它的完整性，取決於「準時送達」。
離散媒體（照片、文字）像一張照片，你慢慢看都行，沒有時間壓力。連續媒體（音訊、視訊）像迴轉壽司的傳送帶——影格要以穩定速度準時送到你面前，忽快忽慢畫面就卡頓。「保證準時送達」這件事，就是 服務品質（QoS）。做不到時，系統就得自動降畫質——這叫 適應（adaptation）。
另一股趨勢，是把整套分散式運算資源當成 雲端運算（cloud computing） ——就像水電一樣，用租的而不是自己買斷。背後撐起雲端規模的，是一群便宜硬體互連合作的叢集電腦（cluster computer）。
網路無所不在、裝置隨身可連，讓「在路上工作」變成常態，但也帶來斷線與漫遊的挑戰。
直播、視訊會議、串流影音要求「準時送達」，逼系統認真規劃服務品質（QoS）與適應策略。
運算資源變成按用量付費的公用事業，靠虛擬化與叢集電腦彈性供應，不必自己養機房。
感應器、家電、穿戴裝置大量連上網，把無所不在運算的願景，變成滿街都是的真實產品。
以前想用運算資源，得自己挖一口井——買伺服器、自己維護、用不用都要養著。雲端運算把運算變成自來水：打開水龍頭（連上服務），用多少算多少錢，不必煩惱水從哪來。虛擬化就像把一條大水管分裝成很多戶人家各自的水表，彈性又好管理。
小試身手
四股趨勢都摸過一輪了。來兩題，檢查你有沒有抓到重點：
這些裝置與服務，到底在共享什麼、又是誰在提供？往下捲，我們把鏡頭轉向「資源共享」這個分散式系統最核心的動機。
資源共享：服務、用戶端與伺服器
你每天都在「共享資源」，卻很少想過——資源明明鎖在別台電腦裡，你是怎麼碰到它的？
你以為的「用印表機」，其實是一次跨電腦的協作
印表機、共用檔案、搜尋引擎——你天天在享受這些好處，習慣到幾乎不會多想。但課本第一句話就把話說白了：建構分散式系統，最主要的動機就是 資源共享 。
但這裡藏著一個很物理的事實：資源不是飄在空中的，它被實體封裝在某一台電腦裡——檔案存在某顆硬碟上，印表機接在某個網路埠上。其他電腦想用它，唯一的辦法就是隔著網路「開口要」。這一模組，就是要把這個「開口要」的過程，拆成精確的詞彙。
印表機、磁碟——共享這些，主要是為了省成本。
共用資料庫、一組網頁——使用者真正在意的是資料本身，不是它躺在哪顆硬碟上。
搜尋引擎、匯率轉換器——使用者只管功能好不好用，不管背後是哪台伺服器在撐。
共享印表機、磁碟確實省成本，但課本說得很清楚：對使用者而言，真正重要的是共享那些「更高層」的資源——像共用資料庫、搜尋引擎——使用者根本不在乎背後是哪顆磁碟、哪台伺服器在跑。
直接讀原文，旁邊就是白話
這一段是本節對「service / server / client」最精確的定義，一字都不能鬆動。左邊原文、右邊白話導讀——不是逐句對應，是幫你抓住這幾句話在講什麼。
這幾句話，是整套 client-server 詞彙的地基：服務（service）是系統裡專門管理一群相關資源、並把功能開放給使用者與應用程式的那個部分——你進不去它的內部，只能透過它公開的那組「操作」跟它互動。
為什麼要這樣限制？書上講得很誠實：資源被實體封裝在某台電腦裡，別的電腦只能靠「通訊」去碰它，這是物理現實逼出來的設計，不是刻意為難你。
於是就有了伺服器（server）——一支在網路電腦上跑、被動等著接請求、做完事再回應的程式；發請求的那一方叫用戶端（client），整套模式就叫 client-server computing。
最容易忽略但最重要的一句：client 是主動的，server 是被動的——server 一直開著待命，client 只在它所屬的應用程式還活著的時候，才存在。
「Resources … are physically encapsulated within computers and can only be accessed from other computers by means of communication.」——資源被鎖在電腦裡，通訊是唯一的鑰匙。後面所有的 client、server、remote invocation，都是圍著這句話長出來的。
把服務想成餐廳的點餐窗口
詞彙有點抽象？課本自己給了一個很生活的畫面——想像一間餐廳。
你不能直接伸手去拿——它們被封裝在廚房裡，就像資源被封裝在某台電腦裡。
你只能用菜單上有的選項互動：點餐、加點、退單，但不能說「讓我進廚房自己翻冰箱」。
你（client）主動走到窗口點餐；服務生／廚房（server）平常待命，收到點單才動作。
這個比喻還藏著一個容易考的細節：client 與 server 是角色，不是身分。一位服務生對顧客來說是 server，但他轉身向廚房點貨時，他自己又變成廚房的 client——角色只看「這一次互動」，不是看這個人「本來是誰」。
你只能點菜單上有的東西，這保證了廚房能可靠、一致地出餐，不會被亂搞。對應到系統裡：操作（operations）就是那張菜單——例如 file service 只開放 read、write、delete，你進不去背後的檔案系統細節。
招牌互動：兩個用戶端，一份資源，一場資源共享
光講定義還是抽象。下面演一次最經典的場景：用戶端 A 先發請求，接著用戶端 B 也想同時用同一份資源——這正是「資源共享」要解決的核心問題。按「下一步」看它怎麼跑。
只有一個用戶端時，client-server 看起來很簡單。真正的挑戰，是像剛剛這樣——多個用戶端同時競用同一份資源，伺服器還要保證每個人拿到的結果都正確、一致。這正是「資源共享」這件事之所以需要被認真設計的原因。
服務怎麼安排？主從式 vs 對等式
Client-server 不是唯一的做法。課本舉了大型多人線上遊戲（MMOG）的真實案例：有些遊戲用主從式，有些完全反過來，走 對等式（peer-to-peer） 。點點看兩種安排的特色與取捨：
多數商業系統還是選主從式或它的變體（例如把世界拆給多台地理分散的伺服器，像 EverQuest 那樣依使用量動態分配用戶端）。對等式更前衛，但代價是協調變複雜——這就是分散式系統設計裡反覆出現的權衡：集中好管理，分散好擴充。
你天天都在用的 client-server：瀏覽器
不必舉多複雜的例子——你現在看這頁教材用的瀏覽器，本身就是一個 用戶端（client） 。它向 web server 請求網頁，這正是最常見的 client-server 案例，也是下一章要細看的 WWW 案例的核心骨架。
把這套詞彙用在分析任何系統上，課本給了一份實務檢核清單，拿到任何系統先問三題：
找出誰是 client（發請求）、誰是 server（收到才醒來回應）。
這個服務對外公開哪些明確操作？哪些細節被刻意封裝、你碰不到？
web server 對瀏覽器是 server，但它去查資料庫時，自己又變成 client。
在物件導向的分散式系統裡，資源常封裝成 物件（object） ，這時我們說 client object 對 server object 呼叫「方法（method）」。分析一條請求鏈時，記得逐次請求判斷角色——同一支程式，可能在鏈的這一端是 server，換到下一端就變成 client。
小試身手
把 service、client、server、remote invocation 這串詞彙串起來，你就掌握了本章最基本也最常用的骨架。來兩題：
資源共享聽起來簡單，但要做對，得同時扛住八個難題。往下捲，我們把它們一個一個攤開來看。
設計上的八大挑戰：讓「看起來簡單」撐住背後的複雜
你點一下滑鼠、寄一封信、看一段視訊——背後其實是八道題目同時被解開
分散式系統的「甜」，藏著八根刺
前面幾個模組都在講分散式系統多好——資源共享、平行運算、隨處連線。但天下沒有白吃的午餐：把一堆各不相同的電腦、網路、程式湊在一起共事，注定會撞上一整組麻煩。書上把這些麻煩歸納成八個挑戰，這個模組先解第一、二個。
第一個挑戰是 異質性 Heterogeneity ——說白了就是「大家都不一樣」。它出現在五個層面：網路（Ethernet、WiFi……）、電腦硬體（例如整數的位元組順序就有兩種寫法）、作業系統（UNIX 與 Windows 收發訊息的 API 不同）、程式語言（字元、陣列、紀錄的表示法各異），還有不同開發者各自的實作——沒有共同標準就無法互通。
例如所有連上 Internet 的電腦都講 Internet 協定，網路的差異就被抹平了。
一層軟體，提供統一的程式設計抽象，同時把底層網路、硬體、OS、語言的差異都遮蔽起來。像 CORBA、Java RMI。
行動程式碼（如 JavaScript）本來綁死特定指令集與 OS；編譯成 bytecode 交給 JVM 解譯，每種電腦只要實作一次 JVM 就通。
聯合國裡各國代表講不同語言，彼此根本聽不懂——但只要戴上同步口譯耳機，講英文的、講法文的都能順暢開會。耳機遮蔽了語言差異，還提供了統一的「開會方式」。這正是中介軟體在分散式系統裡做的事。
直接讀原文，旁邊就是白話
這幾句是本章對「異質性」與「開放性」最直接的定義。左邊原文、右邊白話導讀——不逐句對齊，先抓住意思就好。
Internet 讓使用者能跨越一整堆「彼此不一樣」的電腦與網路，照樣存取服務、跑應用程式——這就是異質性的日常戰場。中介軟體的角色，就是站在應用程式和底層之間，一邊給你一套統一好用的介面，一邊把下面網路、硬體、作業系統、程式語言的差異全部吸收掉，讓寫應用的人不必操心「對方到底是什麼機器」。
另一個挑戰是開放性：一個系統夠不夠開放，看的是它能不能被別人擴充、被重新實作。而開放的先決條件很直白——把關鍵軟體介面的規格和文件公開出來，讓所有開發者都能拿到。書上一句話說得乾脆：簡單講，就是把關鍵介面「公開（published）」。
樂高能無限擴充，是因為它的凸點規格是公開的——任何廠商照規格做積木，都能拼進現有的城堡。你不會被單一廠商綁死。但前提是每塊積木都得真的符合規格，否則拼不起來。開放系統也一樣：介面公開了，元件還是得經過測試，確認真的遵守標準。
第三、四關：東西別被看走、別被擠垮
分散式系統裡流動的資訊往往很值錢，安全性 Security 因此至關重要，通常拆成三要素——機密性 Confidentiality（防洩漏給未授權者）、完整性 Integrity（防竄改）、可用性 Availability（防止存取手段被干擾）。這三者多半能靠加密技術解決，但還有兩個尚未完全解決的難題：
用海量無意義請求灌爆服務，讓正常使用者進不來。目前多半只能靠事後抓人懲處，並非根本解法。
收到的執行檔（像 email 附件）可能表面上是張有趣圖片，實際卻在偷存取本機資源，甚至參與 DoS 攻擊。
第四關是 可擴展性 Scalability ——系統在資源數與使用者暴增時，還能不能維持有效運作。設計時要控制實體資源成本（n 個使用者的資源量最好是 O(n)，跟人數成正比）、控制效能損失（階層式結構比線性結構好，存取時間 O(log n)）、防止軟體資源耗盡（例如 32 位元 IP 位址不夠用只好換成 128 位元的 IPv6），還要避免效能瓶頸——演算法應該去中心化，例如 DNS 把名稱表分割給各地伺服器在地管理，取代了早期單一主檔的瓶頸；熱門資源則可靠快取與複製分流。
一群人故意擠爆銀行大門，讓真正要辦事的客戶進不去——你很難只靠「門口檢查」擋掉，因為他們看起來都像顧客。可擴展性則像連鎖店展店：客人加倍，分店數大致也加倍就好；別讓全國訂位都打到同一支總機，改成各分店自己接訂位；招牌菜先備好放在每家分店，省得每次都跑回中央廚房。
招牌總覽：設計分散式系統的八大挑戰
把前面兩關和接下來要講的四關，一次攤開放在桌上。這八張卡，就是整本書後面所有章節反覆回頭解的題目：
網路、硬體、OS、語言、不同人的實作，通通不一樣——靠共同標準與中介軟體弭平差異。
關鍵介面公開，系統才能被擴充、被不同人重新實作，不被單一廠商綁死。
機密性、完整性、可用性三要素，再加身分辨識；DoS 與行動程式碼仍是未解難題。
使用者與資源暴增時仍要維持效能——靠去中心化、階層化、快取與複製分流。
部分失效難以偵測——用偵測、遮蔽、容忍、復原、冗餘五招撐住可用性。
多個 client 同時碰同一份共享資源，沒同步就會交錯出錯——共享物件必須自己保正確。
把「元件分散」的事實藏起來，讓系統看起來像一個整體，使用者不必知道細節。
有功能還要有品質——尤其是準時性，靠事先保留資源來保證時限。
它們會互相拉扯——為了可擴展性用了複製，就得處理「使用者不該察覺有幾份副本」的透通性；為了容錯用了冗餘，又牽動並行的同步問題。設計分散式系統，就是在這八根柱子之間找平衡。
第五、六關：有些東西壞了，但你分不清楚
分散式系統的失效很特別——是 部分失效 Partial failure ：有些元件壞了，其他還在跑，這讓處理特別困難。書上給了五招對付它：
有些失效能偵測（checksum 抓出損壞資料），有些（像遠端伺服器當機）難以偵測——挑戰是「懷疑卻無法確定」時還能撐住。
把已偵測到的失效藏起來或減輕，例如訊息沒到就重傳、資料同時寫到兩顆硬碟。但不保證最壞情況下有效。
有些失效乾脆讓 client 承受。瀏覽器連不到伺服器不會讓你永遠空等，而是告知問題、讓你稍後再試。
設計軟體讓當機後資料能回復，或「回滾」到一致狀態。
用備援元件容錯——路由間至少兩條路徑、名稱表至少複製兩份、資料庫複製到多台。
第六關是 並行性 Concurrency 。多個 client 可能同時存取共享資源；一次只處理一個請求吞吐量太低，於是通常允許並行處理——但若多個執行緒在同一物件內未受控地交錯操作，就會出錯（書上的拍賣例子：兩筆出價交錯後金額被張冠李戴）。書上講得很直接：任何代表共享資源的物件，都必須負責在並行環境下仍正確運作，做法是把操作「同步」，例如用 semaphore 之類的技術。
單機程式壞了像一個人感冒全身癱瘓；分散式系統像一間公司，會計部請假，業務部照常上班——這是部分失效。麻煩的是，你打電話到會計部沒人接，分不清是請假還是只是去洗手間，這正是難以偵測的失效。並行問題則像大家搶寫同一塊白板：兩人同時改同一行字，沒人協調，最後就是東拼西湊的錯字——解法是裝一支白板筆，誰拿到筆才能寫。
動手配配看：透通性的四個子類型
第七關 透通性 Transparency 就像一位隱形管家：你說「幫我拿那份檔案」，管家自己跑去不知哪個房間拿來，你完全不必知道它放哪、是不是有副本、中途有沒有出小狀況。RM-ODP 定義了八種透通性，這裡挑四種最常被搞混的，把情境描述拖到它對應的透通性上：
存取透通與位置透通，合稱網路透通性——書上點名這兩種對「分散式資源到底有沒有被好好利用」影響最大。寄一封 email，你不必知道對方實體位置在哪（位置透通），也用同一套「寄信」動作完成（存取透通）；就算對方一時收不到，系統也會重試到送達為止（失效透通）。
最後一關，加上小試身手
第八關是 服務品質 QoS 。有了功能還要問品質——主要的非功能性質是可靠性、安全性、效能，再加適應性。QoS 後來特指系統滿足時限保證的能力，例如準時顯示每一幀視訊。要做到這點，關鍵資源必須被「保留」，由資源管理者提供保證；無法滿足的保留請求則會被拒絕。
你要辦一場準時開始的活動，不能「有空位再說」，得事先預訂包廂與人手，餐廳才能保證準時上菜；若資源被訂滿，預約直接被拒絕，而不是讓你到場撲空。這就是 QoS 用「保留資源」換「時限保證」的邏輯。
八個挑戰講完了，來驗收兩題：
下一站：把整章打包，看一個真實系統怎麼同時扛住這八個挑戰——全球資訊網。
案例研究：全球資訊網——活生生的分散式系統
你天天在用的網頁，正是這一章講的所有觀念的縮影——資源共享、client-server、開放系統，全部藏在一個網址裡
整章講的東西，其實你每天都在用
前面幾格談了資源共享、client-server、開放系統這些聽起來有點抽象的概念。現在課本挑了一個你我每天都在碰的東西來當範例—— 全球資訊網（World Wide Web）。
Web 誕生於 1989 年的 CERN（歐洲核子研究中心），一開始只是物理學家之間交換文件的小工具。它的關鍵特色是 超文本（hypertext） 結構：文件裡藏著一個個連結，指向別的文件或資源，於是全世界的文件被織成一張「連結之網」——這就是「World Wide」的來源。
還記得前面提過的開放系統嗎？Web 開放在兩個地方：一是它建立在自由公開、大家都能實作的標準上（任何符合標準的瀏覽器都能跟任何符合標準的伺服器溝通）；二是它對「可發布的資源類型」保持開放——誰發明了新格式，馬上就能發布上網，瀏覽器再靠外掛去支援顯示。這正是它能一路長成今天規模的原因。
直接讀原文，旁邊就是白話
這一段是課本介紹 Web 起源與本質的原話。左邊原文、右邊白話導讀——你看得懂大意，也順手練了原文。
這幾句話講的是 Web 的「出身」跟「本質」：它不是憑空掉下來的完美設計，而是從一群物理學家想互相交換文件的小需求，一路演化長大的系統。課本特別強調它「持續演化（evolving）」——不是一次到位，是邊用邊長。
而它之所以能長這麼大，關鍵就在超文本結構：文件之間彼此連結，剛好貼合人腦組織知識的方式（想到一件事，順手就連到相關的另一件事）。加上它從骨子裡就是開放系統——新東西隨時能加進來，舊功能不會被打壞——這才撐得起後來三十幾年的爆炸性成長。
Web 從 1989 年到今天長這麼大，靠的不是運氣，而是它一開始就選對了架構——開放標準＋簡單協定＋超文本。這正是這一章想告訴你的：好的分散式系統設計，會讓「演化」變得可能。
招牌互動：把一個網址拆開來看
Web 的基本架構從沒大改過，一直立在三根柱子上：HTML、URL、HTTP。其中 URL 最值得拆開來看——每一段都有自己的任務。點點看下面每一段：
scheme 是「用哪種交通方式」（走路／坐船／寄信）；servername 是「哪一棟樓」；path 是「樓裡哪個房間」；如果網址還有 #fragment，那是「房間裡的哪一頁」——由瀏覽器把整份文件下載回來之後，自己在裡面找到那一段。
跑一次完整的網頁請求，看資料怎麼跑
你在網址列打下一個網址、按下 Enter，短短幾百毫秒內，背後其實跑了好幾趟來回。按「下一步」，看三個角色怎麼合作：
靜態網頁像超商貨架上已經做好的便當——你拿了就走，每個人拿到的都一樣（伺服器單純讀檔案）。動態網頁像餐廳現點現做——你填了表單，伺服器上的 CGI 程式 依你的輸入現場做一份給你。妙的是，你（瀏覽器）拿到內容時根本分不出是貨架拿的還是現做的——課本管這個叫「透通（transparent）」：瀏覽器不知道也不在乎內容究竟是讀檔案還是程式現場生出來的。
當瀏覽器不夠用：把程式碼帶回家，讓程式也能當客人
Web 一開始是「人用瀏覽器看文件」，但很快就不夠用了。課本接著談了兩個延伸方向：
JavaScript 能在你打字時就即時檢查輸入格式，還能只更新網頁的一角，不必整頁重抓——這種「資料到達跟你的動作不同步」的更新方式叫 AJAX（非同步）。 早期還有用 Java 寫、由瀏覽器自動下載執行的 applet。
HTML 是設計給人看的，並不適合程式跟程式互通。於是有了 XML ——標準、結構化、自我描述，讓不同機器都能讀懂彼此傳的資料，這正是Web Services的基礎。
那 Web Services 要怎麼設計介面？課本點名了 REST 這個架構風格：每個資源都有自己的 URL，而且都回應同一組標準操作——GET 讀取、POST 新增、PUT 更新、DELETE 刪除。
每個資源都有自己的地址（URL），而且都接受同一組標準操作，誰來都能插，超好擴充——這正是它換來的擴展性。代價是規範相對鬆散，實際運作時較不嚴謹，得靠額外文件把每個操作的細節說清楚。
Web 為什麼能長這麼大？順手驗收一下
課本歸納 Web 成功的三個原因：發布資源很容易、超文本結構適合組織各種資訊、系統架構夠開放——而且背後的標準夠簡單，又早早就公開了。這三點值得你設計任何長久平台時，當作黃金範本。
但成功背後也有代價：資源被搬走或刪除，連到它的連結就變成「斷鏈（dangling link）」；使用者也常在滿地連結裡「迷失在超空間」，得靠搜尋引擎來補救。天下沒有零缺點的設計，只有取捨。
回頭看看：Web 同時體現了本章開頭談的資源共享（全世界的文件、服務彼此開放存取）、client-server（瀏覽器對伺服器一問一答），也一路示範了三大特性——開放性、並行性、容錯性如何在真實系統裡落地；而它從斷鏈、迷失在超空間到擴展性壓力，其實都是那八大挑戰的具體現身。這正是這一章想教你的：學會「辨認」——下次遇到任何一個分散式系統，你都能認出這些同樣的骨架。
第一章到這裡就告一段落了：從「什麼是分散式系統」出發，走過資源共享、三大特性、八大挑戰，最後用你我每天都在用的 Web 收尾——把抽象的原則，釘進一個具體又熟悉的例子裡。準備好，翻到下一章，繼續往下深挖分散式系統的設計細節。