一、背景
1.開發背景
PaaS三節點環境下，需要針對具體服務進行橫向彈縮，以提高服務的處理能力。針對彈出新服務的pm-adaptor和pm-pool容器，開發人員進行了程式碼對應修改，以應對同一服務的多個容器對Kafka訊息的處理。
2.測試背景
利用Jenkins流水線部署了Daily-smoke-CI，通過--開發分支版本編譯->環境安裝部署->呼叫雲測試任務，執行自動化用例。一天執行三次，使得程式碼提交到開發分支後，針對系統的基本功能進行檢測，及時發現引入的故障。
二、故障發現及定位
- POOL任務相關自動化用例未通過
- 進入測試環境進行排查分析
- 發現建立POOL任務時 ，POOL中的網元上的任務未能成功建立，導致用例中到下級OAM去校驗網元任務時，校驗失敗。初步原因：POOL中網元的網元任務未正常建立。
- 在環境中手工建立POOL，並針對POOL建立測量任務，觀察pm-pool的日誌。針對POOL建立任務的Kafka訊息正常傳送，但沒有收到向POOL中網元建立測量任務的Kafka訊息。
- 通過讀取Kafka容器的日誌，發現針對網元建立任務的Kafka訊息被正常消費。
- 嘗試直接針對網元建立任務，任務正常下發至下級。
- 由於pm-adaptor中建立任務和pm-pool中建立任務消費的Kafka主題相同，懷疑存在相互影響，於是針對POOL建立任務同時也觀察pm-adaptor的日誌，最終發現，訊息被pm-adaptor所消費，故障定位。
三、故障原因分析
通過分析程式碼，發現最近一次提交，初始化pm-adaptor和pm-pool的消費者時，將兩者放入了同一消費者群組。 原始的情況，如下圖
修改後將pm-adaptor和pm-pool放入了同一個消費者群組，同一個主題下的一個分割槽只能被一個消費者所消費，且只有被選舉為Leader的分割槽才會被消費，其他分割槽作為容災備份用。本來的訊息pm-pool也可以消費到，現在訊息都被pm-adaptor所消費，從而引入了故障，如下圖所示：
針對故障進行再次修改，將pm-adaptor和pm-adaptor放入不同的消費者群組，二者均能消費到分割槽中的訊息，然後再在容器內部進行自行判斷是否需要自己處理，如下圖所示：