一、前言
主要分享經曆的生産環境多版本kafka叢集版本更新統一過程中的經驗教訓和踩過的坑
二、我的kafka叢集是否有必要更新？
做任何一件事之前，首先需要考慮和明确的，不是該怎麼做，而是是否有必要做。版本更新這樣的“大動作”更是如此。社群釋出了新版本，我們是否要跟進，需要根據叢集目前運作狀況、是否需要新特性這兩大方面，結合實際情況來判斷
公司生産環境叢集情況，屬于上圖中第三象限：
觸發低版本bug的頻率較高，嚴重影響了叢集的穩定性；
由于曆史原因，多個叢集的版本不一緻，使用者使用的便捷性受到制約；
由于多版本并存，管理者必須關注各版本的變更項，增加了線上問題排查的耗時和複雜度。
雖然讨論的是叢集版本更新過程，但依舊要鄭重提醒大家：更新有風險，決定需謹慎。版本更新的目的，是為了使叢集運作更穩定功能更強大，如果叢集目前運作良好而且在可預見的短期内不需要新特性，那麼完全不必要更新版本。
三、叢集更新之“道”：方案設計
決定需要進行叢集更新後，接下來就是方案制定環節。本節将依照“對使用者影響盡量小，操作盡量安全高效”的原則，從是否可以停服更新、如何選擇版本、怎樣分階段分批次操作等層面展開，和大家一起讨論更新方案制定過程中的一些關鍵點。
**3.1 停服更新 or 滾動更新
**
首先，如果可以接受停服，優先選擇停服更新。這樣可以規避滾動更新過程中必須經過的高風險階段——新舊版本之間的切換和并存。
停服更新的操作過程簡單明了：
如果不可接受較長時間停服，但有備份叢集或者有足夠的機器資源可以用來搭建備份叢集，可以通過主備切換的方式實作對主叢集的停服更新：
1、用戶端切換broker/zookeeper連接配接到備份叢集；
2、對主叢集進行停服更新；
3、(如果需要) 備份叢集資料同步至新版本的主叢集；
4、用戶端連接配接切回主叢集，主叢集恢複對外服務。
如果既需要保持服務不中斷，又無法提供備份叢集，那麼滾動更新是唯一的選項，将必須面對新舊版本切換和共存的問題以及由此帶來的潛在風險。作者就是從滾動更新這條路走過來的。
官網和Cloudera、Confluent等主流kafka服務提供商都給出了各自版本的滾動更新流程，這是我們制定滾動更新方案的最主要依據。
3.2 社群版本 or 服務商封裝版本
由于曆史原因，運維的諸多叢集中既有社群版本，也存在不少Cloudera版本(即CDK)，這兩種版本在日常工作中的使用體驗對比詳見下表。大家可以結合各自的使用場景進行選擇。
深感CDK版本的問題排查和調優不便，而且已自研可視化管理平台，是以選擇了全部更新為社群版本
3.3 直接更新到目标版本 or 更新到中間版本過渡
除依賴zookeeper的0.9.0.0版本用戶端由于Bug而無法被0.10.0.x版本的叢集相容以外，Apache kafka官方文檔明确給出了其它各低版本向任一高版本直接更新的操作流程。作者操作完成了CDK和社群共計0.8.2.0~2.1.0其間6個不同版本向目标版本2.2.1的直接更新，得益于kafka優秀的版本相容性。
3.4 叢集更新五階段
作為C/S架構，Kafka叢集的完整更新過程，包括叢集(broker)側和用戶端(client)側兩方面共五部分。
在決定上述各部分執行次序前，需要詳細了解kafka的版本相容特性：
0.10.2.0版本之前，broker版本單向向下相容client版本：broker可以相容等于或低于其版本的client，反之不相容；
0.10.2.0版本及後續版本，broker和client版本雙向相容：broker可以相容0.8.x及以上版本的client，client可以相容0.10.0及以上版本的broker。
0.10.2.0及以後broker和client的版本雙向相容，是通過新增的ApiVersions接口進行協調的：client在讀寫資料前，先向broker發送該類型請求，以擷取目前叢集所能支援的所有版本。
為保證用戶端讀寫不受影響，結合上述版本相容特性，可以得出這五部分的執行次序應該如下：
第一階段：[broker側] 代碼更新。該階段隻更新broker代碼，複制協定和消息格式版本配置保持和低版本一緻。
第二階段：[broker側] broker間通信協定/複制協定版本更新。該階段對配置項 inter.broker.protocol.version 進行更新，消息格式版本配置保持和低版本一緻。
(說明：如果此時更新消息格式版本，會導緻目前低版本Consumer無法識别高版本格式的消息！)
第三階段：[client側] Consumer版本更新。更新後的高版本Consumer可以相容叢集目前的低版本格式的消息。
第四階段：[broker側] 消息格式版本更新。Consumer版本更新完成後，才可以更新broker消息格式版本，即配置項 log.message.format.version。
該階段完成後：
至此，broker側的更新過程全部完成；
Consumer和叢集互動的協定将使用新版本。
第五階段：[client側] Producer版本更新。Producer版本在最後進行更新。
更新後的Producer和叢集互動的協定将直接使用新版本；
至此，整個叢集包括broker和client均已更新完畢。
3.5 分批次操作
叢集更新操作是對叢集的重大變更，如果生産環境有不止一個叢集，為保證更新期間的服務穩定性，建議根據叢集承載業務的重要程度和流量，由小到大循序漸進分批次操作。
所操作的叢集批次劃分如下，供參考。
四、叢集更新之“術”：執行流程
綜合考慮上一節提到的各種因素确定更新方案後，即可将方案細化為可執行的操作步驟實施執行。
作者所在團隊制定的執行流程概要如下圖所示。
關鍵環節集中在：
測試：要對更新操作過程中可能遇到的各種場景進行充分測試，以盡力降低出現意外的機率；
更新流程演練：在測試環境對即将進行更新的叢集操作進行全流程演練，主要目的有兩點：
以文檔的形式固化操作步驟 (包括每一步的執行人、執行的具體操作指令、執行耗時、檢查點，和可能的復原方案)，供線上操作使用；
演練執行并确認復原方案的有效性。
線上更新操作：之前各環節都充分執行完成後，按照既定步驟執行即可。
後續文章将依次對各階段的執行流程，以及操作過程中遇到的問題，進行詳細解析。
五、總結
是否有必要更新叢集：取決于叢集目前運作是否穩定和對新特性的需求是否迫切。
更新方案設計關鍵點：
優先選擇停服更新的方式，可以規避新舊版本切換和共存過程中的潛在風險；
社群版本和服務商封裝版本各有千秋，可根據實際情況進行選擇；
kafka支援broker從幾乎所有的低版本向各個高版本的直接更新，無需中間版本過渡；
叢集的完整更新過程包括broker和client兩方面共五部分，需嚴格按照先後次序分五個階段依次進行；
建議根據業務和流量對所有叢集進行循序漸進分批次更新。
執行流程關鍵點：要對更新操作進行全流程演練，以固化操作步驟并驗證復原方案的有效性。