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

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

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

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

一、健康檢查 API 模式

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

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

二、日志聚合模式

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

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

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

三、分布式跟蹤模式

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

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

四、異常跟蹤模式

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

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

異常跟蹤服務(wù)是一種非常好的異常跟蹤方法。服務(wù)向集中式服務(wù)報(bào)告異常，該服務(wù)對(duì)異常進(jìn)行重復(fù)數(shù)據(jù)刪除、生成警報(bào)和異常管理。可以使用Honeybadger和Sentry等實(shí)現(xiàn)異常跟蹤服務(wù)。

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

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

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

六、審計(jì)日志模式

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

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

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

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