滴滴內部統一使用 kafka 作爲大數據的數據通道，當前滴滴共有幾十個 kafka 集羣，450+ 的節點，20k+ 的 kafka topic，每天2w億+的消息量；每週500+UV用戶，需要完成 topic 創建、申請、指標查看等操作；每天運維人員還有大量集羣、topic運維操作。因此我們需要構建一個Kafka的管控平臺來承載這些需求。
在平臺建設的初期，我們調研了社區同類產品的使用情況，在調研中發現，外部同類產品無論在監控指標的完善程度、運維管控的能力亦或是使用的體驗、還是整體的安全管控上都無法很好的滿足我們的需求，因此自建滴滴 kafka 雲管控平臺勢在必行。
經過前期產品同學的反覆調研和設計、中期研發同學高質量的實現、後期針對用戶體驗反饋的持續迭代，kafka 雲平臺上線後廣受內部用戶和運維人員的好評，使用滿意度達到90分。與此同時，還進行了開源(https://github.com/didi/Logi-KafkaManager)和商業化輸出，並被多家企業用戶成功採購。
免費體驗地址：http://117.51.150.133:8080/kafka ，賬戶admin/admin。
***1. ***
需求分析
在 Kafka 雲平臺建設的初期，我們對之前所面臨的問題和需求進行了歸納分析，主要有以下幾點：
- 數據安全性
由於絕大多數用戶使用的kafka topic 都會由公共集羣來承載數據的生產和消費，而當前 kafka 引擎在 topic 級別的安全管控手段較爲薄弱，任何人只要知道kafka集羣地址和相應的topic便可進行消費。這無疑會造成數據泄漏的安全風險，因此數據的安全性成首要被解決的問題。
- 服務的穩定性
滴滴內部絕大部分的 topic 是在共享集羣上，共享集羣下多 topic 之間存在着相互影響的問題。如某個 topic 的流量突增可能會大面積地影響其他 topic ，從而導致業務的抖動和集羣的不穩定。因此在共享集羣下，kafka 服務的穩定性也成爲了一個必須被解決的問題。
- 用戶使用友好性
滴滴內部每週有大量的用戶需要進行 topic 的創建、消費、擴partiton、指標查看等操作，用戶高頻使用的功能需要做的足夠的友好和容易上手，這樣才能最大的簡化用戶的操作和減低日常開發和運維人員的答疑成本。因此用戶高頻操作的平臺化支撐，則成爲接下來需要解決的問題。
- 問題定位高效性
在日常使用 kafka topic 的過程中，會有大量的問題需要查看和定位，如：消息生產和消費的速度、消息堆積的程度、partition的均勻度、topic的分佈信息、broker的負載信息、副本的同步信息等，如何使用戶和運維人員快速高效的定位問題、處理問題，是重點需要解決的問題。
- 運維管控便利性
在日常的運維中，會存在着大量的集羣、topic的運維操作，如：集羣的部署、升級、擴縮容、topic的遷移、leader rebalance等高頻高危的操作，怎麼樣在提升運維操作效率的同時，還要保證高危操作不會影響集羣穩定性，這個也是需要去重點考慮。
***2. ***
整體設計
從以上的需求分析可以看出，滴滴 kafka 雲平臺建設需要解決的問題比較多元，因此在設計之初就需要對整體有一個清晰的思路和規劃，爲此我們定義了一個核心設計原則，並對業務進行了合理的分層用以指導我們後續的產品設計和代碼開發。
**********▍********1. 核心設計原則******
在平臺的整體設計上，我們制定了“一點三化”的設計原則：
一點：以安全和穩定爲核心點，建設 kafka 的網關係統，針對 topic 的生產/消費提供安全校驗，同時提供多租戶的隔離方案解決共享集羣下多 topic 相互影響的問題；
平臺化：着重建設 kafka 雲平臺，反覆進行需求調研和產品設計，提煉用戶和運維的高頻操作，將這些操作都通過平臺實現，降低用戶的使用成本；
可視化：提升topic/集羣監控、運維過程中指標的可觀察性，所有指標儘量能在平臺上可以直觀體現，方便使用者及時感知集羣運行狀態，快速定位問題；
專家化：將日常集羣運維的經驗沉澱在平臺上，形成專家服務能力和智能化能力，進一步降低 kafka 集羣的維護成本，提升整體穩定性。
**********▍********2. 業務分層架構******
在滴滴 kafka manager 具體的業務設計上，我們採取分層設計，從下至上分爲以下幾層：
資源層：滴滴 kafka 引擎和 kafka manager 除了 zookpeer 之外只依賴 msyql，依賴精簡，部署方便；
引擎層：當前滴滴 kafka 引擎版本是2.5，我們在此基礎上開發了一些自己的特性，如磁盤過載保護，並且完全兼容開源社區的 kafka；
網關層：引擎層之上我們設計了網關層，網關層的設計非常巧妙，主要提供：安全管控、topic 限流、服務發現、降級能力，具體詳見後文“安全性”的內容；
服務層：基於kafka gateway 我們在 kafka manager 上提供了豐富的功能，主要有：topic 管理、監控管理、集羣管理等；
平臺層：對外提供了一套 web 平臺，分別針對普通用戶和運維用戶，提供不同的功能頁面，儘可能的將一些日常使用中的高頻操作在平臺上進行承接，降低用戶的使用成本。
**********▍********3. 應用邏輯架構******
在實際的應用部署和關聯上，整體的 kafka manager 和 kafka 引擎、kafka gateway 之間的邏輯關係比較簡單，具體如下圖所示：
kafka gateway 包括兩大塊功能：服務發現、元數據網關，詳細介紹見後面的元數據網關設計一節。
kafka manager 提供我們開發的特色功能，如：topic管理、監控管理、集羣管理，以及相應的 web 平臺，普通用戶和研發運維人員日常操作接觸最多，最高頻的操作都將這上面完成。
***3. ***
安全性
以kafka 數據的安全性和集羣使用過程中的穩定性保障是我們在構思和設計整個 kafka 雲平臺時首要考慮的問題，爲此我們設計了一套 kafka 元數據網關和多租戶的隔離模型來解決這些問題。******▍********1. 元數據網關設計**
用戶在接入原始的 kafka 集羣時沒有安全管控，無法有效的管理用戶的使用行爲，對數據安全和集羣穩定性造成嚴重的風險，因此我們設計了一套 kafka 集羣元數據網關係統來解決安全問題。
kafka gateway 系統除了解決數據的安全風險還附帶了以下作用：
提供 kafka 集羣的服務發現服務節點，這樣用戶在使用 kafka 集羣服務時，當 kafka cluster boostrap 地址變更時，則不需要用戶改動 kafka 的連接地址，不用重啓 kafka client，保障集羣的變更對用戶透明；
提供 kafka topic 生產和消費的限流能力，避免用戶無限制的使用集羣的流量，流量大的用戶會耗盡系統資源從而影響其他用戶的使用，造成集羣的節點故障；
需要註明說明一點，kafka gateway 的設計很巧妙的將這些功能實現在 kafka 引擎內部。因爲 kafka 作爲一個消息系統，其本身流量是非常的巨大，如果 kafka gateway 作爲一個單獨應用存在，所有流量都先通過 gateway 再進入 kafka 引擎，則對 kafka gateway 機器資源的消耗是非常巨大的，基本等同於需要增加一倍的機器資源，並且整個流程的耗時也會增加。所以在設計之初，就把 kafka gateway 和 kafka 引擎合在一起，這便是滴滴 kafka 引擎的特色能力所在。
搭建好 kafka gateway 系統之後，用戶使用 kafka topic 的流程變爲如下：
在 kafka manager 上申請租戶(appid)，獲取到對應的租戶密碼(app-password)；
利用 appid 申請創建新的 topic，或者申請已存在的 topic 的生產和消費權限；
使用 kafka client 時設置好對應的 appid 和 app-password，相應的 topic 鑑權，限流都在 kafka broker 端完成。
******▍********2. 多租戶隔離模型**
在滴滴內部，絕大部分的 topic 是在共享集羣上的，在沒有管控的情況下，topic 的各個分區是隨機的分佈在不同的 broker 上，隨着集羣中 topic 數量的增加，topic 流量的變大，某個具體 topic 的抖動有可能會影響到其他的 topic，因此共享集羣下的 topic 隔離就是非常必要的，爲此我們結合 kafka gateway 在 kafka manager 上設計了一套多租戶隔離模型來解決這個問題，具體操作如下：
對將kafka 集羣中的各個 broker 進行劃分，一組 broker 被分成一個 region，這個 region 在業務上被抽象爲一個邏輯集羣；
用戶在申請創建新的 topic 時需要選擇一個邏輯集羣，這樣 topic 的分區只能創建在一個邏輯集羣上，也就是一組 broker 上；
具體 topic 消息的生產和消費就只會和一組 broker 發生關係，如果某個 topic 的抖動也只會影響特定 broker 上的其他 topic，從而將影響限定在一定的範圍內。
***4. ***
平臺化
滴滴 kafka manager 平臺建設之初就把易用性作爲主要目標，因此在產品設計上非常注重用戶的使用體驗，前期通過反覆的用戶調研和內部討論，最終提煉出普通用戶和運維用戶的高頻操作，將這些操作都通過平臺實現，降低用戶的使用成本。
- 方便的日常用戶使用
用戶只關注自己的Topic的信息(默認)，以減少不必要信息的干擾；
足夠的指標信息，以保證用戶能自助解決問題的同時減少不必要信息的干擾；
- 高效的運維操作
提煉用戶、運維人員創建Topic、調整配額、擴展分區、集羣遷移、集羣重啓等高頻運維操作，將高頻操作平臺化，簡化用戶操作，大大降低運維成本。
提供整體集羣直觀的全局視角，以提高排查問題的效率以及對集羣規模的直觀感知，並提供詳盡的局部視角，以提高排查問題的效率；
-
友好的生態
內部版本與滴滴監控系統打通，開源版本與滴滴開源的夜鶯監控告警系統打通，集成監控告警、集羣部署、集羣升級等能力，形成運維生態，凝練專家服務，使運維更高效。
-
**體貼的細節 **
kafka 雲平臺的建設，它有着自己的設計理念，如：應用、權限、限流等；kafka 集羣的 broker 和 topic 的上也存在着各種指標，操作任務，審批流程等，這些都會對用戶的使用造成困惑。雖然產品同學在反覆的體驗和持續的優化迭代，但是爲了進一步的方便用戶使用，我們在各種用戶可能感覺到困惑指標含義的地方，設置了大量的提示說明，讓用戶不用出頁面就可以基本解決問題，整個使用過程力爭如絲般順滑。
-
出衆的顏值
常見的內部工具型產品往往都是以滿足功能和需求爲主，很多都是功能在頁面上的堆砌，kafka 雲平臺在建設之初，在產品設計和前端開發上也力求更高的標準，最終整體的風格相比以往提升巨大，一上線就被用戶稱讚爲 “大廠出品” ，相比目前幾款主流開源的 kafka 管理平臺，在頁面美觀程度上大大超出其他同類產品，可以說是“我花開後百花殺”。
***5. ***
可視化
運維人員在日常進行kafka 集羣維護和穩定性保障過程中，對集羣和 topic 的各項指標都非常關注，因此指標採集展示的準確性和及時性變得非常重要。爲此我們將指標的可視化也作爲 kafka manager 建設的核心目標。
- 黃金指標定義
針對 broker 和 topic 日常監控和診斷問題過程中最主要的指標進行篩選，這些指標被定義爲黃金指標，如：topic 的 messageIn、byteIn等，並在平臺的相關頁面上進行高優高亮展示，便於用戶在日常使用過程中，快速診斷和定位集羣可能存在的問題。同時我們還根據 broker 和 topic 的指標監控，制定了一套用於快速識別其運行狀態的健康分算法，將多個指標進行加權計算，最終得到一個健康分數值，健康分的高低則直觀的展示了 broker 和 topic 實際運行過程中的狀態，便於用戶和運維快速從多個 broker 和 topic 中識別。
- 業務過程數據化
增加基於 topic 生產消費各環節的耗時統計，支持動態開啓與關閉，幫助用戶自助排查問題；關鍵指標業務運行過程化，不同分位數性能指標的監控，方便歷史問題回溯診斷。
- 服務端強管控
服務端記錄客戶端連接版本和類型，連接強感知，集羣強管控，元信息的基石；controller 強管控，指定的主機列表，記錄 controller 歷史運行節點；記錄 topic 的壓縮格式，應用與業務元信息，業務強感知。
***6. ***
專家化
基於之前全面的kafka數據採集，和運維同學在日常操作過程中的一些經驗總結，我們將高頻的問題和操作沉澱形成特有的專家服務，來智能診斷 kafka 集羣和 topic 的健康狀態，並提供對應的處理方案。
kafka manager 的專家服務能提供了以下功能：
- 分區熱點遷移
背景：Kafka只具備Topic遷移的能力，但是不具備自動均衡的能力，Region內部分Broker壓力非常大，但是部分Broker壓力又很低，高低不均。如果不立即處理，輕則無法繼續承接用戶的需求，重則由於部分Broker壓力過大導致集羣出現穩定性問題。
解決方案：
在滴滴 kafka 引擎上增加 topic 在不同磁盤上分佈的指標；
kafka manager 通過定時採集的 topic 指標來分析 topic在不同磁盤上的分佈均勻度；
針對不均勻的 topic 發起遷移操作，並在遷移時進行流量控制，保證遷移不會影響集羣的穩定性。
- 分區不足擴容
背景：kafka 集羣的 topic 相關的元信息存儲在 zookpeer 上，最終由 controller 將其同步到各個broker。如果元信息過大，controller 同步的壓力就會隨之上升成爲整個集羣的瓶頸點，如果遇到某臺 broker 出現問題，整個集羣的數據同步就非常慢，從而影響穩定性。
解決方案：
在用戶申請創建 topic 的時候，平臺進行分區數的管控，分區數不能設置的特別大，然而隨着 topic 流量的上升，topic 分區可能不足。如果遇到 topic 流量突增，超過了單分區能承載的能力，會導致分區所在的Broker出現壓力，如cpu和load升高等問題，客戶端也會出現發送堆積的情況。
基於現有的機型以及客戶端的消費發送能力的壓測，我們定義了單分區的承載流量，同時我們實時對每個 topic 的流量進行監控，當某個 topic 的峯值流量持續的達到和超過閾值之後，會對該 topic 進行標記或者告警，定義爲分區不足的 topic。
針對監控發現出來的分區不足的 topic，由運維人員手動進行擴分區，或者 kafka manager 根據當前集羣整個容量情況自動進行擴分區。
- topic資源治理
背景：公共集羣中用戶申請創建的 topic，它們的使用情況是各不相同的，還存在着部分 topic 根本不使用還佔據集羣元數據的情況，這對本來就十分擁擠的公共集羣造成很大的資源浪費和穩定性風險，因此針對集羣中的不使用的 topic進行治理就非常必要。
解決方案:
實時對集羣中所有 topic 的流量進行採集監控，智能的分析 topic 的流量趨勢，如果發現 topic 的流量持續在一段時間內爲0，則進行標記或者告警。
針對監控發現的一定週期無流量、無生產消費鏈接的topic，進行通知和下線清理操作。
***7. ***
同類對比
我們來和外部類似的產品進行一個簡要的功能對比如下：
經過簡單的對比，我們可以看到，經過平臺化、可視化、智能化、安全建設之後，滴滴kafka manager在安全性、用戶體驗、監控、運維管控上都有着顯著的優勢，也提供了很多特色的功能，極大的方便了用戶和運維人員的日常使用，歡迎大家Star和體驗https://www.didiyun.com/production/logi-KafkaManager.html
***8. ***
展望
Logi-Kafka-Manager 已在滴滴內部上線使用，未來我們除了在平臺化、可視化、智能化基礎上持續改進，還會在以下幾個方面持續努力：
- 平滑的跨集羣遷移
我們將基於 MirrorMaker + KafkaGateWay 打造一套 kafka Topic 跨集羣平滑遷移能力，在 kafka manager 平臺上爲 kafka topic 運維管控提供更爲高效的遷移能力，進一步提升運維效率。
- 更多的指標監控
進一步的支持 kafka 2.5+ 最新版本的管控，並且新增更多的關鍵指標的監控，從而讓 kafka manager 指標展示和問題定位的能力更強大。
- 持續回饋開源社區
作爲在滴滴內部經過大量複雜場景驗證過的 kafka 管控平臺，我們會持續對其進行核心業務抽象，剝離滴滴內部依賴，回饋社區，我們也希望熱心的社區同學和我們交流想法，共同提升滴滴 Logi-KafkaManager 的功能和體驗