從設計到分散式系統，Apache Kafka是這樣測試的！

Apache Kafka被用於很多的公司，包括全球最苛刻的，大規模的和關鍵的系統。其最大的用戶在數千台機器上運行Kafka，每天處理數萬億條消息。它是銀行和金融交易等關鍵市場數據系統的骨幹。它是許多科技公司的計費管道的一部分。它還被用作幾個分散式資料庫（包括運行Linkedin的主資料庫）的提交日誌。在所有這些環境中，最根本的問題是保持正確性和性能：我們如何確保系統保持不變，不會丟失數據。你如何為這種類型的嚴苛需求用途的系統編寫軟體？

當然，現實是非常困難的，沒有「銀彈」。分散式系統因其精細的環境而令人頭疼，也是追蹤和復驗問題的難點。試圖消除它們需要在整個軟體開發生命周期中的一套實踐，從設計到生產。大多數項目都很好地記錄了他們的API和功能集，但很少記錄他們採取的做法和策略，以確保這些功能的正確性。本文目的是讓人們深入了解Confluent和更大的Apache Kafka社區如何處理以確保質量的測試和其他做法。

從設計開始：Kafka改進提案

軟體的趨勢遠離了前期的設計流程和更靈活的方法，這對於應用程序開發來說可能是一件好事，但是對於分散式系統，我們認為製作好的軟體必須以良好的設計開始。什麼是核心要素，確保和API？新功能或模塊如何與其他子系統進行交互？如果你不能用少量的編碼來清楚地解釋這些東西，那麼很難測試你是否在一個大的代碼庫中正確地實現了這些。更重要的是，設計討論的目的是確保全面開發團隊對特徵的意圖有所了解，以便代碼審查和未來開發在代碼基礎發展的過程中保持正確性。

為了確保我們已經考慮過這些問題，Kafka要求任何主要的新功能或子系統都附帶一個名為Kafka Improvement Proposal（KIP）的設計文檔。這允許改變進行廣泛而公開的討論。例如，關於KIP-98提出的一次性交付語義的討論，一個非常大的功能，花費了幾個月，但最終大大改善了原始設計。設計討論經常緩慢，但實際情況是，設計可以比實現功能所需的時間快得多，因為認識到方法的局限性，然後重新設計和重新實現。

KIP文檔：https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals

KIP98：

https://cwiki.apache.org/confluence/display/KAFKA/KIP-98+-+Exactly+Once+Delivery+and+Transactional+Messaging

代碼審查

Kafka團隊具有深入和廣泛的代碼審查的分為，試圖主動發現正確性和性能問題。代碼審查當然是軟體工程中相當普遍的做法，但它通常是對風格和高級設計的粗略檢查。我們發現在代碼審查中更深入的時間投入真的是值得的。

分散式系統中的故障通常與錯誤條件有關，通常是在有針對性的測試中難以觸發的組合和狀態。這可不是一個偏執的個人通過逐行檢查新的代碼，花費大量的時間嘗試思考可能出錯的一切所能替代的。代碼審查通常有助於找到難以在測試中觸發的罕見問題。

測試與平衡

軟體工程師通常主張單元測試優於集成測試。我們發現，需要的是測試方法的層次結構。單元測試運行速度快，易於調試，但你需要將其與更為完整的測試相結合，在更現實的環境中運行更完整集成的軟體版本。

單元測試

Kafka擁有超過6800個單元測試，用於隔離單獨組件或小套組件。這些測試運行速度快，容易調試，因為它們的範圍很小。但是由於它們不測試模塊之間的相互作用，而且只能在人為環境中運行，因此它們對整個系統的正確性沒有提供太多保證。

除了單元測試，我們還使用其他預提交檢查，例如findbugs（靜態分析工具）和checkstyle（樣式檢查來保持代碼美觀）。

集成測試

Kafka擁有超過600個集成測試，可以驗證在單個進程中運行的多個組件的交互。典型的集成測試可能會設置Kafka代理和客戶端，並驗證客戶端是否可以向代理髮送消息。

這些測試比單元測試慢，因為它們涉及更多的設置工作，但是在沒有負載或環境故障（如硬碰撞或網路問題）的情況下，可以很好地檢查正確性。

分散式系統測試

許多軟體項目僅限於單一和單一過程集成測試；然而，我們發現這不足夠，因為它們不涵蓋分散式數據系統困擾的全部問題：並發問題只發生在負載，機器故障，網路故障，緩慢的進程，版本之間的兼容性，微妙的性能回歸等等。要檢測這些問題，必須在現實環境中測試分散式系統的實際部署。我們將這些多機測試系統測試稱為單進程/機器集成測試。

構建分散式測試對於像Kafka這樣的系統來說並不困難：它具有明確的正規保證和性能特徵，可以被驗證，並不難寫出測試來檢查它們。困難的是使這種測試自動化，可維護和可復驗。這需要Kafka管理員，輕鬆部署流處理器和其他組件的不同分散式拓撲，然後協調安裝程序的測試和故障。更難的是使這種類型的測試可調試：如果你在引入故障的同時通過負載分散式環境運行一千萬條消息，並且你檢測到一條消息丟失，知道從哪開始尋找問題？

為了幫助我們這樣做，我們創建了一個名為ducktape的框架。Ducktape在創建分散式環境，勝任設置集群和索引故障方面的工作。它有助於腳本化測試場景，並收集測試結果。也許最重要的是它也有助於聚合所有運行的測試的日誌和指標，以便可以調試失敗任務。

Ducktape框架庫：https://github.com/confluentinc/ducktape

系統測試框架允許我們構建不可能的測試類型：

• 應力測試：這些測試在重載下運行，並檢查負載下的正確性。

• 性能測試：一次性基準測試非常好，但需要檢查性能回歸。

• 故障注入測試：這些測試會導致故障，如磁碟錯誤，網路故障，進程暫停（模擬GC或I/O）

• 兼容性測試：這些測試檢查舊版本的Kafka與新版本的兼容性，或對外部系統（如Kafka Connect連接器）進行測試。

我們每天運行超過310個系統測試場景，每天超過350個機器小時。可以在這裡看到的結果和測試場景。

結果和測試場景：http://testing.confluent.io/

Ducktape是開源的，所以如果你面臨類似的問題，可能值得一試。

社區測試

沒有什麼比生產環境找到問題重要了。幸運的是，Kafka擁有一大群資深用戶，可以在發布之前在類似生產環境中幫助測試Kafka，通常是通過鏡像生產負載並對新版本的軟體進行運行，以確保其在使用模式下在其環境中工作。

由於我們所有的測試都是自動化的，因此代碼庫儘可能地接近可持續釋放的狀態。這允許Linkedin和其他幾個企業在官方發布之前運行中繼版本。這些企業的理念是，更頻繁的升級意味著更低的風險和更小的變化來尋找任何問題。

來自運行Kafka規模的人們以及撰寫代碼的工程師的緊密反饋循環，一直是開發的重要組成部分。在Confluent和Confluent雲中，我們託管Kafka產品使我們能夠在非常重的環境中觀察各種生產工作負載。這個反饋循環是確保大規模操作的工具，配置，指標和實踐真正有效的。畢竟，在生產中運行軟體是最終的考驗。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！