第五個、也是最後一個對流暢交付至關重要的品質屬性是可觀測性(Observability)——它反映「理解應用與其使用者行為的容易程度」。它的重要性體現在三件事:

• 來自生產環境與使用者的回饋是流暢交付不可或缺的一環。
• 部署失敗必須被快速偵測並回滾。
• 生產問題必須被快速診斷與修復。

可觀測性的場景#

兩個典型場景:

• 支援部署機制判斷成敗:部署期間,元件發出指標(error rate、latency 等),由可觀測性基礎設施收集後提供給部署機制,作為「成功 / 應該回滾」的判斷依據。
• 支援團隊理解應用與使用者行為:應用元件發出 telemetry,由可觀測性基礎設施收集,提供給開發者觀察自家元件與使用者的行為。

設計高可觀測性的架構#

兩條主要策略:

• 實作可觀測性模式(observability patterns)
• 使用多元件架構

實作可觀測性模式#

技術可觀測性的好定義(來源:Honeycomb 的《What Is Observability?》):

「Observability(亦稱 o11y)是理解應用與系統行為與效能的概念。它從收集系統 telemetry 開始——例如 logs、metrics、traces;更關鍵的是如何分析這些 telemetry,以診斷問題、理解依賴互聯,並確保可靠性。」

注意:這個定義側重「應用可靠性」,但 telemetry 同時也呈現使用者行為——例如某個你以為很有價值的功能,實際上根本沒人用。

第 17 章詳述以下可觀測性模式:

• Log aggregation(日誌聚合)
• Distributed tracing(分散式追蹤)
• Application metrics(應用指標)

每種模式都由兩部分組成:

• 元件中的 instrumentation 程式碼:收集並發出 telemetry。
• 基礎設施服務:收集、儲存、分析 telemetry。

可觀測性是開發與營運共同協作的成果。

• 營運:提供 log aggregation、monitoring 等基礎設施服務。
• 開發:撰寫 instrumentation 程式碼。對某些 telemetry,只需引入適當的函式庫;對另一些(domain-specific metrics、application-level logs),需要寫自己的程式碼。

多元件架構提升可觀測性#

Telemetry 是按「元件實例」收集的,某些指標(尤其是資源使用率)反映的是整個元件的合計行為。

當單一元件包含多個子領域時,合計指標會遮蔽各子領域的個別行為。多元件架構讓你能取得更細緻的 telemetry(例如以子領域為單位),更容易定位問題與理解使用者行為。

章節重點摘要#

• 流暢交付需要架構滿足五個品質屬性:可修改性、可演化性、可測試性、可部署性、可觀測性。
• 前四項讓開發者快速地把變更交給客戶;第五項則確保部署的安全並提供來自生產與使用者的回饋。
• 可修改性:來自鬆設計期耦合與高內聚的架構。
• 可演化性:對大型應用而言,需要多元件架構,讓多數架構決策可獨立做,升級可漸進進行。
• 可測試性:來自模組化、鬆設計期耦合、確定性的架構。
• 可部署性:來自支援自動化、快速、可靠、不影響 SLA、可自動回滾的部署設計。
• 可觀測性:主要透過落實可觀測性模式達成;多元件架構讓大型複雜應用的可觀測性更佳。
• 元件架構的選擇(單一元件 vs 多元件)直接影響大型應用能否滿足可演化性、可測試性、可部署性、可觀測性,這也是微服務與巨石之間的關鍵差異。