Salesforce構建可觀察微服務的五種設計模式

banq發表於2022-02-05
Salesforce微服務設計模式

軟體開發中的設計模式是解決常見問題的可重複解決方案和最佳實踐。即使在服務監控的情況下，如果使用得當，設計模式也可以幫助團隊接受服務所有權並解決生產中的服務故障。您可以將服務監控設計模式分為三類：
  1. 健康檢查你怎麼知道你的服務正在執行——如果是的話——也在做它應該做的事情？是否及時響應？您是否可以在影響客戶之前解決潛在的服務問題？
  2. 實時警報當出現問題時（例如您的服務變得無響應、爬行速度變慢或使用了太多資源），您是否配置了警報以通知您該問題？
  3. 故障排除您的服務出現問題了嗎？如果有，您可能需要知道三件事：何時發生、發生在何處以及導致它發生的原因。在問題發生後使用日誌和跟蹤來診斷問題，並更新您的服務，使這些問題不會對客戶產生持久的影響。


 

健康檢查
健康檢查的兩種模式是由外而內的健康檢查，它驗證您的服務是否正在執行並確定您的服務的響應時間/延遲，以及由內而外的健康檢查，它密切關注應用程式和系統指標，以便您可以在潛在問題（包括效能問題）引起事件之前檢測到它們。

  • 1.由外而內的健康檢查

在此模式中，您使用健康檢查服務或綜合測試工具 ping 您的服務端點。我們使用我們內部構建的工具，但其他選項包括 NewRelic、Gomez 和 DataDog。您的服務響應 ping，它將檢查的輸出記錄為時間序列度量系統中的度量，例如Argus或您用於此類服務的任何系統。資料可用後，您可以在一段時間內視覺化服務的執行狀況和其他關鍵指標，和/或選擇在滿足特定條件時向您傳送警報。

此模式可用於檢查兩組主要指標：
  • 正常執行時間——這個指標回答了一個由來已久的問題，“我的服務是否正在執行，它是否在做它應該做的事情？” 健康檢查呼叫程式 ping 您的服務後，如果您的服務響應，則它已啟動；如果它沒有響應，則它已關閉，您需要開始修復工作
  • 使用者感知延遲— 您必須從全球多個位置檢查服務延遲。例如，對於從日本訪問您的服務的客戶而言，使用者感知的延遲可能與從西班牙和美國訪問服務的客戶不同。您可以將執行狀況檢查 API 呼叫的延遲用作使用者感知延遲的代理。

上述兩組的組合也可用於確定您的服務的基於合成的可用性訊號。
 
  • 2.由內而外的健康檢查

在此模式中，您可以使用系統和應用程式指標在潛在問題導致服務中斷之前檢測到它們——為您的服務和您的客戶！
要確定是否存在可能影響服務效能或可用性的潛在問題，請收集有關應用程式及其執行的底層基礎架構的指標。
那麼您應該關注哪些應用程式指標？至少，收集這四個訊號。
  • 請求率——你的服務有多忙？
  • 錯誤率——您的服務中是否有任何錯誤？如果有，有多少，它們發生的頻率是多少？
  • Duration (of requests) ——你的服務響應請求需要多長時間？
  • 飽和度——你的服務有多過載？它有多大的成長空間？

此外，為您的服務使用的每種資源型別（例如 CPU、記憶體、磁碟空間、IOPS）收集這些系統指標。
  • 利用率——這個資源有多忙？
  • 飽和度——影響應用程式效能/正常執行能力的應用程式中最受限制的資源的利用率如何？
  • 錯誤— 資源的錯誤計數是多少？

收集這些指標還允許您計算服務的可用性指標，這回答了關鍵問題 — 我的服務或功能是否被認為對我的客戶可用？在大多數情況下，正常執行時間、持續時間（延遲）和錯誤率指標的組合可用於以代表客戶服務體驗的方式計算服務的可用性。例如，如果您僅根據正常執行時間計算服務的可用性，那麼即使查詢需要很長時間才能響應/網頁需要很長時間才能載入，您仍然會認為自己可用。因此，採用其他指標（例如錯誤率和持續時間）對於適當定義可用性至關重要。
 

反模式：使用日誌建模指標
使用日誌資料建模指標的計算成本很高（這意味著在貨幣方面很昂貴），並且增加了攝取、處理和反應的時間，從而增加了 MTTD（平均檢測時間）。這些結果都不是可取的。在 Salesforce，我們的團隊構建了高效的指標收集工具供我們的開發人員使用。
 

  • 3. 修復問題

警報的一般模式涉及確定問題是否可以自動修復，或者是否需要人工採取某些措施以避免違反公司與客戶的服務水平協議 (SLA)。
警示反模式
  • 不要做玻璃觀察。隨著系統規模的擴大和複雜性的增加，我們不能依靠人類24小時盯著顯示器來尋找服務的健康趨勢，並在違反閾值的情況下打電話給某人來修復問題。我們需要依靠機器和演算法在出錯時通知我們。這也把人為錯誤排除在外。儘可能多地實現流程的自動化。
  • 所有的警報都是不一樣的。因此，不要以同樣的方式對待所有警報。把服務的每一個小問題都作為警報傳送到電子郵件/Slack頻道，結果不過是垃圾郵件，並大大降低了訊雜比。對於每一個服務問題，如果有可能導致客戶問題/SLA違反（關鍵問題），請呼叫值班工程師（使用類似PagerDuty的東西）。其他所有的事情都應該被記錄為票據（如果需要採取行動），或者應該被記錄為日誌條目。

故障排除
當您的服務確實出現問題時，您需要有關出現問題、出現​​問題的時間以及出現問題的位置的資訊。對您的服務進行編碼，以便此類資訊可用於解決問題。有兩種關鍵方法可以使這些資訊可用。
  • 記錄錯誤情況和相關資訊
  • 在您的服務中啟用分散式跟蹤（尤其是在微服務環境中）

  
  • 4. 記錄錯誤情況

日誌是您找出服務出現問題以及何時出現問題的最佳朋友，因此請務必記錄服務的錯誤情況。在您的服務中包含一個日誌庫以捕獲應用程式日誌並將這些日誌傳送到日誌服務。在 Salesforce，我們使用Splunk，但其他一些選項可能是 DataDog、NewRelic 等。
進行故障排除時，您可以使用應用程式日誌和基礎架構日誌來幫助您確定導致事件的原因以及如何減少事件再次發生的機會。
 
  • 5. 微服務的分散式跟蹤

在微服務架構中，當發生事件或效能下降時，您需要了解的不僅僅是問題所在。您還需要知道您的哪些微服務導致或促成了該問題。
分散式跟蹤允許您透過使用 requestID 標識每個請求來獲取該資訊。當問題發生時，您可以查明它在請求流中發生的位置以及問題是與您的服務相關聯還是與相關服務相關聯。在 Salesforce，我們已經將我們所有的各種應用程式與自主開發的分散式跟蹤服務（構建在 Zipkin 之上）Tracer 整合在一起。生成的 span 被髮送到 Tracer，並使用B3 headers將上下文傳播到下游應用程式。對於檢測，我們使用Zipkin或OpenTelemetry庫。

相關文章