概述#
Energy Efficiency（能源效率）是一個相對新興但日益重要的品質屬性。本章將能源效率提升為架構層級的一級關注事項，提供系統化的情境、策略與模式來指導設計。
書中指出，當前能源效率面臨三大挑戰：
- 架構概念不足：缺乏架構層面用於推理與管理能源的概念，開發者只能各自發明方法，最好的情況是產出難以維護與演進的臨時方案，最壞的情況是根本無法達成能源效率目標。
- 認知不足：多數架構師與開發者不知道 energy efficiency 是一項品質屬性，也不知如何收集與分析相關需求。當前教育課程中幾乎未提及這是程式設計師的關注事項。
- 設計概念匱乏：缺乏適合的模型、模式、策略等設計概念來設計及在 runtime 管理與監控能源效率。這些設計概念仍處於萌芽階段，尚無完整的目錄。
雲端平台通常不擔心能源耗盡（災難情境除外），但行動裝置與物聯網裝置每天都面臨這項挑戰。雲端環境中的擴展（scaling up/down）是核心能力，需定期決定最佳資源配置；物聯網裝置受尺寸、外形與散熱限制，無法使用大型電池，且預計未來十年部署的龐大數量使其能源使用成為重要議題。
在所有情境中，energy efficiency 必須與 performance 及 availability 取得平衡：
- 雲端：更多資源帶來更好的效能與容錯能力，但增加能源與資本支出。
- 行動/物聯網：通常無法增加資源（但可將計算負擔轉移至雲端後端），取捨集中在能源效率 vs. 效能與可用性。
- 所有情境：能源效率與 buildability、modifiability 之間存在取捨。
Energy Efficiency General Scenario#
Table 6.1 列出了 energy efficiency 一般情境的各個要素：
| 情境要素 | 說明 | 可能的值 |
|---|---|---|
| Source | 誰發起節能請求 | 終端使用者、管理者、系統管理員、自動化代理 |
| Stimulus | 節能請求的內容 | 總使用量、最大瞬時使用量、平均使用量等 |
| Artifacts | 被管理的對象 | 特定裝置、伺服器、VM、叢集等 |
| Environment | 管理能源的環境 | Runtime、已連線、電池供電、低電量模式、省電模式 |
| Response | 系統採取的節能行動 | 停用服務、釋放 runtime 服務、變更服務至伺服器的配置、以較低消耗模式運行、配置/釋放伺服器、變更服務層級、變更排程 |
| Response measure | 節能的衡量指標 | 最大/平均千瓦負載、平均/總節省能源量、總千瓦時使用量、系統必須維持供電的時間，同時維持所需的功能水準與其他品質屬性的可接受水準 |
Figure 6.1: Sample energy efficiency scenario
上圖展示一個具體情境：管理者希望在非尖峰時段透過釋放未使用的資源來節省能源。系統在釋放資源的同時，維持資料庫查詢最壞情況延遲 2 秒，平均節省 50% 的總能源需求。
Tactics for Energy Efficiency#
Energy efficiency 情境由節能或管理能源的需求所觸發，同時仍需提供所需的功能（但不一定是完整功能）。若能源回應在可接受的時間、成本與品質限制內達成，則該情境算成功。
Figure 6.2: Goal of energy efficiency tactics
能源效率的核心是有效利用資源。策略分為三大類：Resource Monitoring（資源監控）、Allocate Resources（資源配置）、Reduce Resource Demand（降低資源需求）。此處的「resource」指消耗能源並提供功能的計算裝置，包含 CPU、資料儲存、網路通訊與記憶體。
Figure 6.3: Energy efficiency tactics
Monitor Resources（資源監控）#
「你無法管理你無法衡量的事物」，因此從資源監控開始：
- Metering（計量）：透過感測器基礎設施，近乎即時地收集計算資源的能源消耗數據。最粗略的層級可從資料中心的電錶測量；個別伺服器或硬碟可使用外部工具（如安培表、瓦時表）或內建工具（如有計量功能的 rack PDU、ASIC）測量。電池供電系統則透過 battery management system 判斷電池剩餘電量。
- Static classification（靜態分類）：當即時資料收集不可行時（例如使用外部雲端而無法直接存取即時能源數據），透過編目所使用的計算資源及其已知能源特性來估算能源消耗，例如記憶體裝置每次 fetch 的能耗。這些特性可從基準測試或製造商規格取得。
- Dynamic classification（動態分類）：當靜態模型不足以反映實際情況時，使用動態模型根據暫態條件（如工作負載）估算能源消耗。模型可以是簡單的查表、基於先前執行數據的回歸模型，或模擬。
Allocate Resources（資源配置）#
資源配置意指在考量能源消耗的前提下，將資源分配給工作：
- Reduce usage（降低使用量）：在裝置層級透過降低顯示器刷新率、暗化背景等裝置特定活動來減少使用。當需求不再需要時移除或停用資源——如旋停硬碟、關閉 CPU 或伺服器、降低 CPU 時脈、關閉未使用的處理器區塊電流。也可透過將 VM 整併（consolidation）至最少數量的實體伺服器，並關閉閒置的計算資源。在行動應用中，可將部分計算送往雲端以節省能源（假設通訊的能耗低於計算）。
- Discovery（發現服務）：發現服務將服務請求（來自客戶端）與服務提供者配對。在能源效率的情境中，請求可附加能源資訊，讓請求者基於服務提供者的（可能是動態的）能源特性來選擇。雲端環境可使用 green service directory（綠色服務目錄）儲存從計量、靜態分類或動態分類取得的資訊；智慧型手機則可從 app store 取得。
- Schedule resources（排程資源）：將任務分配至計算資源。在能源情境中，排程可基於資源監控策略收集的數據，在滿足任務限制與優先順序的前提下有效管理能源使用。計算任務可動態切換至提供更佳能源效率或更低能源成本的計算資源。
Reduce Resource Demand（降低資源需求）#
此類策略在 Chapter 9（Performance）中有詳細說明，包括：
- Manage event arrival（管理事件到達）
- Limit event response（限制事件回應）
- Prioritize events（排定事件優先順序，可能讓低優先事件不被處理）
- Reduce computational overhead（減少計算開銷）
- Bound execution times（限制執行時間）
- Increase resource usage efficiency（提高資源使用效率）
這些策略透過「做更少的工作」來直接提升能源效率，與 reduce usage 策略互補。Reduce usage 假設需求不變，而 reduce resource demand 策略則是顯式管理（並降低）需求的手段。
Tactics-Based Questionnaire#
以下是基於策略的問卷，用於快速了解架構在多大程度上運用了特定策略來管理 energy efficiency：
| 策略群組 | 策略問題 |
|---|---|
| Resource Monitoring | 系統是否計量（meter）能源使用？是否透過感測器基礎設施近乎即時地收集計算裝置的實際能源消耗數據？ |
| 系統是否對裝置與計算資源進行靜態分類（static classification）？在即時計量不可行或計算成本太高時，是否有參考值來估算能耗？ | |
| 系統是否對裝置與計算資源進行動態分類（dynamic classification）？在靜態分類因負載或環境條件變化而不準確時，是否使用基於先前收集數據的動態模型？ | |
| Resource Allocation | 系統是否透過降低使用量（reduce usage）來縮減資源使用？是否能在需求不再需要時停用資源以節能？ |
| 系統是否排程資源（schedule resources），以在任務限制與優先順序下更有效地利用能源，透過切換至更節能的計算資源？ | |
| 系統是否使用發現服務（discovery service），讓服務請求可附加能源需求資訊以選擇具有更佳能源特性的提供者？ | |
| Reduce Resource Demand | 是否持續嘗試降低資源需求？（可參考 Chapter 9 Performance 的策略問卷） |
Patterns#
以下是用於 energy efficiency 的幾個常見模式：
Sensor Fusion（感測器融合）#
行動應用與物聯網系統經常使用多個感測器收集環境數據。此模式的核心思想是：使用低功耗感測器的數據來推斷是否需要從高功耗感測器收集數據。
一個常見的範例是在手機中使用加速度計（accelerometer）數據來判斷使用者是否移動，若確實有移動，才啟動 GPS 定位更新。此模式的前提假設是——存取低功耗感測器的能耗遠低於高功耗感測器。
優點：
- 以智慧方式最小化高耗能裝置的使用，而非僅僅降低查詢頻率（例如單純減少 GPS 更新間隔）。
取捨：
- 查詢與比較多個感測器會增加前期設計複雜度。
- 高耗能感測器能提供更高品質的數據且速度更快（因為無需先查詢次要感測器再做判斷）。
- 若推斷結果經常導致仍需存取高功耗感測器，則整體能耗反而可能高於直接使用高功耗感測器。
Kill Abnormal Tasks（終止異常任務）#
行動系統因為經常執行來源不明的應用程式，可能在不知情的情況下運行異常耗電的 app。此模式提供一種機制來監控應用程式的能源使用，並在必要時中斷或終止耗能過高的操作。
具體範例：若一個 app 持續發出聲音警報並震動手機，而使用者未回應這些警報，系統會在預設的超時期限（timeout period）後自動終止該任務。
優點：
- 為具有未知能源特性的應用提供 fail-safe（失效安全）選項，防止單一 app 耗盡裝置電力。
取捨：
- 任何監控流程都會為系統運作增加少量 overhead，可能影響效能與能源使用。
- 從 usability 角度，終止耗能任務可能與使用者的意圖相違背——使用者可能正需要該功能。
Power Monitor（電源監控器）#
Power monitor 模式的職責是監控與管理系統裝置，最小化裝置處於活動狀態的時間。此模式嘗試自動停用應用程式目前未正在使用的裝置與介面。
這個模式在積體電路（IC）設計中已有長期歷史——當晶片中的電路區塊未被使用時，即關閉其電流以節能。如今這個概念被提升至系統軟體架構層級。
優點：
- 在對終端使用者幾乎無影響的情況下實現智慧節能，前提是被關閉的裝置確實不需要。
取捨：
- 裝置被關閉後，重新啟動會產生額外延遲（相較於持續運行的情況）。
- 在某些情況下，啟動的能耗可能高於一段時間的穩態運行能耗（啟動代價高於維持代價）。
- 電源監控器需要了解每個裝置及其能源消耗特性，這增加了系統設計的前期複雜度。
Energy efficiency 是一個跨領域的品質屬性，與 performance（效能）、availability（可用性）、modifiability（可修改性）等存在密切的取捨關係。在架構設計時，必須有意識地推理這些取捨，而非將能源效率視為事後考量。
小結#
Energy efficiency 作為品質屬性雖然相對年輕，但隨著雲端運算的規模化、行動裝置的普及與物聯網的爆發性成長，其重要性日益提升。架構師可透過三類策略——資源監控（metering、靜態/動態分類）、資源配置（降低使用量、發現服務、排程）、降低資源需求——以及 sensor fusion、kill abnormal tasks、power monitor 等模式，系統性地在架構中納入能源效率考量。