背景及系統簡介：

Kafka是一種高吞吐量的分布式架構的發布訂閱消息系統，它可以處理消費者在網站中的所有動作流數據。通常由于高吞吐量的要求而選擇通過處理日志數據和日志聚合來解決。

[[348168]]

本文涉及的分布式系統(簡稱C系統)已初具規模，而隨著系統建設的建設推進和功能的逐步完善，外圍系統對C系統的日志消費需求逐步增加。為了滿足日志消費需求，決定在C系統的網關系統中增加日志發送功能實現對外消息的發送。

C系統的網關系統主要負責分布式系統的接入驗證，對接受請求進行必要的合法性、安全性等內容的校驗。將消息發送功能放到網關系統中主要有2方面考慮：

• 網關系統日志記錄了上送請求的原始信息，能夠完整描述交易請求發生的場景及請求內容;
• 便于制定統一的消息報文格式和規范，避免多系統發送消息時標準不一致，給后續的消息消費帶來困難。

聯機消息發送測試

網關系統設置了消息控制表，控制是否發送消息。同時可以根據需要從不同維度控制哪些消息需要發送,而不是所有日志數據全部發送，避免系統資源的浪費，提高消息的使用效率。

1. 正常交易消息發送

即發送服務的基本功能測試。當上送交易請求在后臺執行成功后，觸發網關系統消息發送功能，將該上送請求相關的日志信息封裝消息發送出去。消息控制數據緩存在應用服務器，以提高讀取速度，通過POSTMAN工具查詢、驗證。

消息發送無顯性展示，因此測試對消息是否正常、發送規則是否符合消息控制表配置規則、發送內容的正確性和完整性、topic使用是否正確、總線系統是否正常、正確接收到消息等內容的驗證，通過查詢log的方式完成。

2. 查證交易消息發送

查證功能是網關系統提供的查證上送交易執行結果(成功/失敗)的功能。由于網絡等原因未收到被查交易返回結果時，如果該交易配置了消息發送功能，則在查證交易成功后將被查交易的原始交易信息封裝消息并發送，保證該交易所有使用場景都能正確發送消息。

3. 異常消息處理

異常場景主要驗證Kafka不能正常發送消息的情況，我們通過修改Kafka服務器IP地址方式和配置錯誤的topic等方式模擬Kafka消息發送失敗的場景，進而驗證網關系統是否能將消息正確、完整的記錄到異常消息表中。

4. 熔斷場景測試

熔斷是指Kafka異常或消息服務壓力過大，進而影響網關系統其他正常功能，需要臨時關閉消息服務已保證網關系統本身對外服務正常。關閉消息服務是通過將要發送的消息記錄到異常消息表中，后續通過批量補發方式補發消息。

批量消息處理測試

通過定時輪詢的方式，對記錄到異常消息表里的消息進行補發。同時設置消息熔斷機制，當Kafka異常時，將消息發送完全切換到記錄消息表，避免造成Kafka完全失效的同時也保證了本系統對外服務正常。

消息補發功能

當日消息補發定時輪詢，每5分鐘掃描一次異常消息表，對于未發送成功的消息重新補發，在發送三次失敗后更新消息狀態為“異常”。測試主要驗證內容：

• 補發消息的篩選;
• 錯誤的消息(如空消息)等處理;
• 補發線程沖突處理機制，等

上日消息補發對上一日未發送的異常消息進行補發，與當日補發功能類似，但不是定時輪詢。

異常消息導出

對于各種補發后仍失敗的消息，為保證數據的完整性，提供導出功能做后續處理。

性能測試

由于投產后預期消息發送量很大，預估約1億筆以上，所以對性能要求較高。

參考預估交易量，根據二八原則(80%的交易量發生在20%的時間內)，估算投產后系統的TPS約7000左右。參考該系統前次性能測試指標，我們將通過標準定位2000，測試、生產TPS比例1：3.5。而測試環境資源與生產資源比例約為1：16，遠大于TPS的測試生產比例，因此我們認為達到該標準即可滿足生產系統性能要求。

在進行了基準測試、負載測試及混合場景測試后，消息服務在測試環境TPS達到了2000以上，并且系統資源都在合理范圍內。

總結

Kafka是比較成熟的消息系統，為網關系統的消息服務提供了基礎，但Kafka偶爾會出現假死現象，導致消息阻塞。本次原本計劃嘗試模擬假死現象，但與項目開發人員以及Kafka支持人員討論了解到，暫時無法模擬該場景，這也是本次留下的遺憾。