微服務日誌一直是架構師需要關註的問題。這是因為每個請求跨不同服務器上的多個服務運行。每個服務都在自己的運行服務器上寫入日誌。它最終導致日誌分散在多個存儲庫中，並且跟蹤事件序列變得困難。
解決方案之一是使用日誌整合工具，例如 Splunk 或 Loggly，定期從不同服務器復製日誌並構建事件序列。
這種方式的問題在於它不是實時解決方案，一些日誌信息直到復製完成才可用。
此外，該解決方案在基於負載動態創建服務和服務器的雲環境中不可行。
基於 Kafka 的微服務日誌解決方案 更可行的解決方案是使用 Kafka 作為日誌的消息代理。這種日誌架構是數據流的一種實現，其中數據就是日誌。所以這種方式也叫做Log Streaming。
在 Log Streaming 中，每個服務都將日誌發送到 Kafka，而不是將日誌寫入本地存儲庫。多個訂閱者被寫入以出於各種目的訂閱日誌。
與通過復製進行日誌整合不同，Log Streaming 是一種實時解決方案，更適合當今的數字平臺。 日誌訂閱者 一個典型的訂閱者是日誌整合工具，然後提供系統事件的整體和實時分析。
除此之外，我們還可以開發訂閱者進行動態分析。這對於臨時事件尤其有用。例如，我們可以開發一個訂閱者來訂閱與安全或性能相關的事件。
我們也可以編寫一個訂閱者來監控和處理一些特定的事件，比如超過 3 次登錄失敗。這是一種將附加功能聚合到系統的整合方法。 網絡阻塞 日誌流模型的問題之一是網絡阻塞。當服務越來越多時，大量的日誌會被註入網絡，造成網絡阻塞。這可能會對其他正常的 Kafka 服務造成影響，例如延遲下單。
解決辦法是:
1. 對網絡進行分區，這樣日誌就不會泛濫整個網絡
2. 精心製作幾臺 Kafka 服務器，僅用於日誌目的，以及
3. 搭建Kafka farm進行日誌操作
感謝您閱讀這篇文章，以下是金融科技透視的其它文章：
緯泓是香港、新加坡和中国的頂級金融科技企業。自1998年以來，我們一直在幫助金融機構實施全球銀行解決方案
Copyright © 2022 緯泓 版權所有，不得轉載
Comments