可觀察性是監(jiān)控的超集。除了提供對隱式故障模式的詳細洞察之外，它還提供了系統(tǒng)健康狀況的高級概述。此外，可觀察系統(tǒng)還提供了有關(guān)其內(nèi)部運作的儲備，能夠發(fā)現(xiàn)更深層次的系統(tǒng)性問題。

一旦服務(wù)部署到生產(chǎn)環(huán)境中，我們想知道它每秒請求數(shù)、資源利用率等方面的執(zhí)行情況。此外，如果出現(xiàn)問題，希望能得到即時警報，例如服務(wù)實例失敗或者磁盤空間不足，最好是在影響用戶體驗之前得到警報。如果出現(xiàn)問題，我們需要能夠排除故障并進行 RCA(根本原因分析)。

作為服務(wù)開發(fā)人員，我們應(yīng)該實現(xiàn)幾種模式，讓服務(wù)管理和故障排除更容易。以下五種模式可以幫助我們設(shè)計可觀察的服務(wù)：

• 健康檢查API： 提供一個返回服務(wù)健康狀況的端點。
• 日志聚合：您可以記錄服務(wù)活動并將日志存儲在集中式日志服務(wù)器中，該服務(wù)器提供警報和搜索功能。
• 分布式跟蹤：使用唯一ID 識別每個外部請求，并在請求服務(wù)之間流動時對其進行跟蹤。
• 異常跟蹤：應(yīng)將異常報告給異常跟蹤服務(wù)，該服務(wù)對異常進行重復(fù)數(shù)據(jù)刪除、提醒開發(fā)人員并跟蹤它們是如何解決的。
• 應(yīng)用程序指標：諸如計數(shù)器和儀表之類的指標由服務(wù)維護并暴露給指標服務(wù)器。
• 審計日志：跟蹤用戶操作

一、健康檢查 API 模式

有時，服務(wù)可能正在運行但無法處理請求。新啟動的服務(wù)實例可能仍在初始化并進行一些健全性檢查，然后才能處理請求。部署基礎(chǔ)架構(gòu)在準備好處理 HTTP 請求之前，將其路由到服務(wù)實例是沒有意義的。

也可能出現(xiàn)服務(wù)實例沒有終止就失敗的情況，例如所有的DB連接都用完了，無法訪問數(shù)據(jù)庫。部署基礎(chǔ)設(shè)施不應(yīng)將請求路由到失敗但仍在運行的服務(wù)實例；如果服務(wù)實例無法恢復(fù)，則必須終止它，并創(chuàng)建一個新實例。服務(wù)實例必須能夠告訴部署基礎(chǔ)設(shè)施它是否能夠處理請求。您可以使用實現(xiàn)健康端點的Spring Boot Actuator來為您的服務(wù)實現(xiàn)健康檢查端點。

二、日志聚合模式

日志聚合模式可以進行故障排除。如果您想確定應(yīng)用程序出了什么問題，日志文件是一個很好的起點。登錄微服務(wù)架構(gòu)可能具有挑戰(zhàn)性，因為日志內(nèi)容分散在不同服務(wù)的日志文件中。

日志聚合是解決方案。日志聚合服務(wù)將所有服務(wù)實例的日志發(fā)送到集中式日志服務(wù)器。當(dāng)日志被日志服務(wù)器存儲時，它們可以被查看、搜索和分析。還可以設(shè)置在日志中出現(xiàn)某些消息時觸發(fā)警報。

日志基礎(chǔ)設(shè)施負責(zé)聚合日志、存儲日志，并使用它進行搜索。許多流行的工具都提供了日志聚合，例如Splunk、Fluentd、ELK stack、Graylog等。

三、分布式跟蹤模式

假設(shè)您正在對 API 響應(yīng)緩慢進行故障排除，這個 API 可能涉及多個服務(wù)。使用分布式跟蹤可以深入了解應(yīng)用程序正在做什么。分布式跟蹤器類似于單體應(yīng)用程序中的性能分析器。記錄有關(guān)處理請求時進行的服務(wù)調(diào)用的信息。然后，您可以看到服務(wù)在處理外部請求期間如何交互，以及在每個服務(wù)上花費了多少時間。

每個外部請求都被分配一個唯一的 ID，并在它從一個服務(wù)流向另一個提供可視化和分析的集中式服務(wù)器上進行跟蹤。分布式追蹤服務(wù)器包括Zipkin、Jaeger、OpenTracing、OpenCensus、New Relic等。

四、異常跟蹤模式

服務(wù)記錄異常，幫忙確定原因很重要。異常表示存在問題或程序錯誤。日志用于查看異常，甚至可以配置日志服務(wù)器，方便在異常時提醒運維人員。然而有幾個缺點需要注意：

• 日志文件由單行日志條目組成，而異常有多行。
• 在日志文件中，沒有跟蹤異常解決的機制。需要手動將異常復(fù)制/粘貼到問題跟蹤器中。
• 目前沒有辦法自動將重復(fù)的異常視為一個異常。

異常跟蹤服務(wù)是一種非常好的異常跟蹤方法。服務(wù)向集中式服務(wù)報告異常，該服務(wù)對異常進行重復(fù)數(shù)據(jù)刪除、生成警報和異常管理?？梢允褂肏oneybadger和Sentry等實現(xiàn)異常跟蹤服務(wù)。

五、應(yīng)用度量模式

監(jiān)控和警報是生產(chǎn)環(huán)境的關(guān)鍵組件。監(jiān)控系統(tǒng)從其技術(shù)堆棧的所有部分收集提供有關(guān)應(yīng)用程序運行狀況的關(guān)鍵信息的指標。這些指標的范圍從基礎(chǔ)架構(gòu)級別的指標（例如 CPU、內(nèi)存和磁盤利用率）到應(yīng)用程序級別的指標（例如服務(wù)請求延遲和處理的請求數(shù)量）。

度量標準是服務(wù)開發(fā)人員的責(zé)任，有兩種方式。首先必須檢測服務(wù)，收集有關(guān)行為指標。其次，必須將這些服務(wù)指標以及來自 JVM 和應(yīng)用程序框架的指標公開給指標服務(wù)器。應(yīng)用程序指標服務(wù)可以像 AWS CloudWatch 服務(wù)或Prometheus服務(wù)器一樣輪詢端點以檢索指標。Grafana是一種數(shù)據(jù)可視化工具，可用于在 Prometheus 中查看指標。

六、審計日志模式

每個用戶的操作都被審計日志記錄下來。通常，審核日志用于提供客戶支持、確保合規(guī)性和檢測可疑活動。審計日志條目記錄用戶的身份、他們執(zhí)行的操作以及涉及的業(yè)務(wù)對象。審計日志通常存儲在數(shù)據(jù)庫表中。

審計日志可以通過幾種不同的方式實現(xiàn)：

1. 將審計日志代碼添加到業(yè)務(wù)邏輯：每個服務(wù)方法都可以創(chuàng)建一個審計日志條目并將其保存到數(shù)據(jù)庫中。
2. 面向切面的編程 (AOP)：可以使用 AOP 框架（如 Spring AOP）定義攔截每個服務(wù)方法調(diào)用并保留審計日志條目的建議。
3. 利用事件溯源：默認情況下，事件溯源提供了用于創(chuàng)建和更新操作的審計日志。

根據(jù)定義，可觀察性模式不是關(guān)于日志、指標或跟蹤，而是關(guān)于在調(diào)試期間由數(shù)據(jù)驅(qū)動并使用反饋來迭代和改進產(chǎn)品。

標題名稱：微服務(wù)架構(gòu)的可觀察性設(shè)計模式
轉(zhuǎn)載來于：http://uogjgqi.cn/article/cdegiec.html