分散式系統（尤其是其中介軟體）一方面要提供通用方案來遮蔽網路固有的不良特性，以支援越多應用越好；另一方面，完全的分散透明性又不是多數應用真正想要的，應用專屬的方案也必須被支援。前一節的結論是：分散式系統應該是可調適的，但調適的重點在執行行為，而不是抽換組成系統的軟體元件。

當調適需要自動進行時，系統架構與軟體架構產生了強烈的交互作用：一方面要把元件組織成可監控、可調整的形式；另一方面要決定處理調適的行程放在哪裡執行。

本節專注於把分散式系統組織成高階的回饋控制系統，讓系統能對變化自動調適。這個領域也稱為自主運算（autonomic computing）或 self-star（self-*）系統——後者的命名反映了自動調適的多種面向：自我管理（self-managing）、自我修復（self-healing）、自我配置（self-configuring）、自我最佳化（self-optimizing）等等。以下統一以自我管理系統涵蓋這些變體。

回饋控制模型#

對自我管理系統的各種觀點，多數（明示或暗示地）共享一個假設：調適透過一或多個回饋控制迴圈（feedback control loops）進行。以這種迴圈組織的系統稱為回饋控制系統。回饋控制在工程領域行之有年，其數學基礎也逐漸進入運算系統；對自我管理系統而言，一開始最有趣的是架構面的議題。

迴圈的核心是需要被管理的元件群：它們由可控制的輸入參數驅動，但行為也受各種不可控輸入影響——即干擾（disturbance）或雜訊。干擾常來自系統執行的環境，但也可能是未預期的元件互動造成的意外行為。

回饋控制迴圈由三類元素構成：

1. 監控與度量估計：系統本身必須被監控，也就是量測系統的各個面向。量測常常說易行難——例如 Internet 的往返延遲變化劇烈，還取決於量的到底是什麼；若節點 A 要在不打擾 B、C 的前提下估計 B 與 C 之間的延遲，就更困難了。因此迴圈中通常有一個邏輯上的**度量估計（metric estimation）**元件。
2. 回饋分析（feedback analysis）：分析量測值並與參考值比對，是迴圈的心臟——決定是否調適、如何調適的演算法都在這裡。
3. 影響行為的機制：直接改變系統行為的各種手段——放置複本、改變排程優先權、切換服務、為可用性搬移資料、把請求轉向其他伺服器等。分析元件必須知道有哪些機制、以及各機制對系統行為的（預期）效果，才能觸發其中一或多個，之後再觀察成效。

有趣的是，這個迴圈同樣適用於人工管理系統——差別只在分析元件換成了人類管理者。但管理者一樣需要像樣的監控設備與控制機制。「正確分析量測資料、觸發正確行動」正是自我管理系統之所以難做的原因。

回饋控制迴圈描述的是自我管理系統的邏輯組織，實體組織可以非常不同：分析元件可能完全分散在系統各處，效能量測通常也是在每台機器各自進行。以下三個實例會同時展示「如何自動監控、分析、修正」以及邏輯與實體組織的差異。

實例一：用 Astrolabe 監控系統#

Astrolabe 是支援超大型分散式系統一般性監控的系統。在自我管理的脈絡裡，它的定位是觀察系統行為的通用工具，輸出可以餵給分析元件來決定修正行動。

• 階層式區域（zones）：Astrolabe 把大量主機組織成區域階層——最低層的區域只含單一主機，逐層聚合成越來越大的區域，最頂層區域涵蓋所有主機。
• 代理程式（agent）：每台主機跑一個 Astrolabe 行程，收集該主機所屬各區域的資訊，並與其他代理程式通訊，把區域資訊散布到整個系統。
• 屬性（attributes）：每台主機維護一組屬性收集本地資訊（如它存放的特定檔案、資源使用量）。只有最低層（主機自身）的屬性可寫；區域層級的屬性值一律由下層的值計算而來。

例如三台主機 A、B、C 組成一個區域，各自記錄 IP 位址、CPU 負載、可用記憶體與活躍行程數；區域層級只能收集聚合資訊，如平均 CPU 負載、平均活躍行程數。

• 關聯式視角：每台機器收集的資訊視為資料庫中的一筆記錄，這些記錄合起來構成一個關聯（表格）——這是刻意的設計，Astrolabe 就是這樣看待所有收集到的資料。
• 可程式化的聚合函數：聚合資訊由類似 SQL 的函數計算。假設主機資訊放在本地表 hostinfo，要算該區域的平均行程數：

SELECT AVG(procs) AS avg_procs FROM hostinfo

搭配少量 SQL 擴充，不難寫出更有訊息量的查詢。

• 傳播機制：這類查詢由每台主機上的代理程式持續評估，前提是區域資訊要傳遍所有節點。每個代理程式負責計算其所屬區域表格的一部分；不歸它算的記錄，會透過簡單而有效的流言（gossiping）交換程序不時送達，計算結果同樣會傳給其他代理程式。最終效果：所有參與取得某聚合資訊的代理程式，都會看到相同的結果（前提是期間沒有變動）。

實例二：Globule 的差異化複寫策略#

Globule 是協作式內容傳遞網路：終端使用者在 Internet 上提供伺服器，協作以網頁複寫最佳化效能。每個源頭伺服器（負責特定網站更新的伺服器）以逐頁為單位記錄存取模式：每次讀寫操作都被加上時間戳記錄下來。

• Globule 最簡形式假設 Internet 可視為前述的邊緣伺服器系統：請求總是能經過適當的邊緣伺服器。這個簡單模型讓源頭伺服器得以推演「如果當初把複本放在某台邊緣伺服器，會發生什麼事」——複本離用戶端越近，用戶端感受的延遲越低，但為了維持複本與原始頁面一致，源頭伺服器與邊緣伺服器之間的流量也會增加。

• 源頭伺服器收到頁面請求時，記錄來源 IP，用 WHOIS 服務查出對應的 ISP 或企業網路，找出可作為該用戶端邊緣伺服器的最近複本伺服器，並計算到該伺服器的延遲與最大頻寬。最簡配置下，Globule 假設複本伺服器與使用者機器之間延遲可忽略、頻寬充足。
• What-if 分析：收集到足夠請求後，源頭伺服器評估多種複寫政策——政策描述頁面複寫到哪裡、如何保持一致。每個政策的成本以簡單線性函數表達：

cost = (w1 × m1) + (w2 × m2) + ... + (wn × mn)

其中 m_k 是效能度量、w_k 是其重要性權重。典型度量包括：回傳網頁副本時用戶端與複本伺服器間的聚合延遲、源頭與複本伺服器間維持一致所耗的總頻寬、（允許）回傳給用戶端的過期副本數。例如想最佳化用戶端感受延遲，就把聚合延遲的權重調高，於是只有真正把該度量壓低的政策才會呈現低成本。

• 源頭伺服器對每個網頁分別、定期以軌跡驅動模擬（trace-driven simulation）評估數十種複寫政策，選出最佳者並執行——可能因此在不同邊緣伺服器安裝新複本，或改用不同的一致性維持方式。軌跡收集、政策評估、政策執行全部自動完成。

延伸：軌跡長度與預測準確度的微妙關係

一個微妙的問題是：要收集多少請求才能評估政策？假設源頭伺服器在時刻 T_i 根據 T_i-1 到 T_i 之間的請求選了政策 p，用到 T_i+1；事後回顧，若根據 T_i 到 T_i+1 實際發生的請求應該選 p*，且 p* ≠ p，那當初就是選錯了。

預測錯誤率取決於用來預測的請求序列長度（軌跡長度，trace length），而且兩頭都會變差：

• 軌跡太短：請求不夠，無法做像樣的評估，錯誤率上升。
• 軌跡太長：涵蓋了太多存取模式的變化，預測最佳政策變得困難甚至不可能。這就像想預測明天的天氣，卻去看過去一百年的紀錄——只看近期反而準得多。

最佳軌跡長度同樣可以自動求得（原書留作習題）。

實例三：Jade 的自動元件修復管理#

維護一叢集電腦、每台跑著複雜的伺服器時，減輕管理負擔非常重要。對以元件式方法建構的伺服器，一種做法是偵測元件故障並自動替換——Jade 系統走的就是這條路。

• Fractal 元件模型：Jade 建立在 Fractal 之上——一個允許執行期增刪元件的框架的 Java 實作。Fractal 元件有兩種介面：伺服器介面（供他人呼叫該元件實作的方法）與用戶端介面（該元件用來呼叫其他元件）。元件之間靠**繫結（binding）**介面相連：原始繫結表示呼叫用戶端介面就直接呼叫被繫結的伺服器介面；複合繫結則可能經過一或多個其他元件——例如介面不匹配需要轉換，或元件位於不同機器。

• 修復管理域（repair management domain）：由若干節點組成，每個節點代表一台伺服器與其上執行的元件；另有獨立的**節點管理者（node manager）**負責在域中增刪節點，為了高可用可以複寫。

• 故障偵測器：每個節點配備偵測器，監控節點或元件的健康狀態並向節點管理者回報。偵測對象通常包括元件狀態的異常變化、資源使用量，以及元件真正的故障——後者可能意味整台機器當機。

• 修復程序：偵測到故障即啟動，由明確陳述的**修復政策（repair policy）**驅動（部分由節點管理者執行），依偵測到的故障類型執行。例如偵測到節點故障時，政策可能規定：

  1. 終止「非故障節點上的元件」與「故障節點上的元件」之間的所有繫結。
  2. 請求節點管理者啟動並加入一個新節點。
  3. 把新節點配置成與當機節點完全相同的元件組合。
  4. 重新建立先前終止的所有繫結。

這個修復政策很簡單，只在沒有關鍵資料遺失時有效——也就是當機的元件必須是無狀態的（stateless）。

Jade 是自我管理的典型示範：偵測到故障後自動執行修復政策，把系統整體帶回當機前的狀態。但這種自動修復需要「執行期增刪元件」的特定支援——一般而言，把遺留（legacy）應用改造成自我管理系統是不可能的。