滴滴內(nèi)部統(tǒng)一使用 kafka 作為大數(shù)據(jù)的數(shù)據(jù)通道瓦糟，當(dāng)前滴滴共有幾十個 kafka 集群菩浙，450+ 的節(jié)點劲蜻，20k+ 的 kafka topic，每天2w億+的消息量疫蔓；每周500+UV用戶衅胀，需要完成 topic 創(chuàng)建滚躯、申請掸掏、指標(biāo)查看等操作阅束；每天運維人員還有大量集群息裸、topic運維操作年扩。因此我們需要構(gòu)建一個Kafka的管控平臺來承載這些需求厨幻。

在平臺建設(shè)的初期况脆，我們調(diào)研了社區(qū)同類產(chǎn)品的使用情況格了，在調(diào)研中發(fā)現(xiàn)盛末，外部同類產(chǎn)品無論在監(jiān)控指標(biāo)的完善程度悄但、運維管控的能力亦或是使用的體驗、還是整體的安全管控上都無法很好的滿足我們的需求净嘀，因此自建滴滴 kafka 云管控平臺勢在必行。

經(jīng)過前期產(chǎn)品同學(xué)的反復(fù)調(diào)研和設(shè)計挖藏、中期研發(fā)同學(xué)高質(zhì)量的實現(xiàn)暑刃、后期針對用戶體驗反饋的持續(xù)迭代，kafka 云平臺上線后廣受內(nèi)部用戶和運維人員的好評膜眠，使用滿意度達(dá)到90分岩臣。與此同時，還進(jìn)行了開源(https://github.com/didi/Logi-KafkaManager)和商業(yè)化輸出宵膨，并被多家企業(yè)用戶成功采購。

免費體驗地址：http://117.51.150.133:8080/kafka 辟躏，賬戶admin/admin谷扣。

***1. ***

需求分析

圖片

在 Kafka 云平臺建設(shè)的初期，我們對之前所面臨的問題和需求進(jìn)行了歸納分析捎琐，主要有以下幾點：

• 數(shù)據(jù)安全性

由于絕大多數(shù)用戶使用的kafka topic 都會由公共集群來承載數(shù)據(jù)的生產(chǎn)和消費会涎，而當(dāng)前 kafka 引擎在 topic 級別的安全管控手段較為薄弱，任何人只要知道kafka集群地址和相應(yīng)的topic便可進(jìn)行消費瑞凑。這無疑會造成數(shù)據(jù)泄漏的安全風(fēng)險末秃，因此數(shù)據(jù)的安全性成首要被解決的問題。

• 服務(wù)的穩(wěn)定性

滴滴內(nèi)部絕大部分的 topic 是在共享集群上籽御，共享集群下多 topic 之間存在著相互影響的問題练慕。如某個 topic 的流量突增可能會大面積地影響其他 topic ，從而導(dǎo)致業(yè)務(wù)的抖動和集群的不穩(wěn)定技掏。因此在共享集群下铃将，kafka 服務(wù)的穩(wěn)定性也成為了一個必須被解決的問題。

• 用戶使用友好性

滴滴內(nèi)部每周有大量的用戶需要進(jìn)行 topic 的創(chuàng)建零截、消費麸塞、擴partiton、指標(biāo)查看等操作涧衙，用戶高頻使用的功能需要做的足夠的友好和容易上手，這樣才能最大的簡化用戶的操作和減低日常開發(fā)和運維人員的答疑成本奥此。因此用戶高頻操作的平臺化支撐弧哎，則成為接下來需要解決的問題。

• 問題定位高效性

在日常使用 kafka topic 的過程中稚虎，會有大量的問題需要查看和定位撤嫩，如：消息生產(chǎn)和消費的速度、消息堆積的程度蠢终、partition的均勻度序攘、topic的分布信息茴她、broker的負(fù)載信息、副本的同步信息等程奠，如何使用戶和運維人員快速高效的定位問題丈牢、處理問題，是重點需要解決的問題瞄沙。

• 運維管控便利性

在日常的運維中己沛，會存在著大量的集群、topic的運維操作距境，如：集群的部署申尼、升級、擴縮容垫桂、topic的遷移师幕、leader rebalance等高頻高危的操作，怎么樣在提升運維操作效率的同時诬滩，還要保證高危操作不會影響集群穩(wěn)定性霹粥，這個也是需要去重點考慮。

***2. ***

整體設(shè)計

圖片

從以上的需求分析可以看出碱呼，滴滴 kafka 云平臺建設(shè)需要解決的問題比較多元蒙挑，因此在設(shè)計之初就需要對整體有一個清晰的思路和規(guī)劃，為此我們定義了一個核心設(shè)計原則愚臀，并對業(yè)務(wù)進(jìn)行了合理的分層用以指導(dǎo)我們后續(xù)的產(chǎn)品設(shè)計和代碼開發(fā)忆蚀。

**********▍********1. 核心設(shè)計原則******

在平臺的整體設(shè)計上，我們制定了“一點三化”的設(shè)計原則：

• 一點：以安全和穩(wěn)定為核心點姑裂，建設(shè) kafka 的網(wǎng)關(guān)系統(tǒng)馋袜，針對 topic 的生產(chǎn)/消費提供安全校驗，同時提供多租戶的隔離方案解決共享集群下多 topic 相互影響的問題舶斧；

• 平臺化：著重建設(shè) kafka 云平臺欣鳖，反復(fù)進(jìn)行需求調(diào)研和產(chǎn)品設(shè)計，提煉用戶和運維的高頻操作茴厉，將這些操作都通過平臺實現(xiàn)泽台，降低用戶的使用成本；

• 可視化：提升topic/集群監(jiān)控矾缓、運維過程中指標(biāo)的可觀察性怀酷，所有指標(biāo)盡量能在平臺上可以直觀體現(xiàn)，方便使用者及時感知集群運行狀態(tài)嗜闻，快速定位問題蜕依；

• 專家化：將日常集群運維的經(jīng)驗沉淀在平臺上，形成專家服務(wù)能力和智能化能力，進(jìn)一步降低 kafka 集群的維護(hù)成本样眠，提升整體穩(wěn)定性友瘤。

圖片

**********▍********2. 業(yè)務(wù)分層架構(gòu)******

在滴滴 kafka manager 具體的業(yè)務(wù)設(shè)計上，我們采取分層設(shè)計檐束，從下至上分為以下幾層：

• 資源層：滴滴 kafka 引擎和 kafka manager 除了 zookpeer 之外只依賴 msyql辫秧，依賴精簡，部署方便厢塘；

• 引擎層：當(dāng)前滴滴 kafka 引擎版本是2.5茶没，我們在此基礎(chǔ)上開發(fā)了一些自己的特性，如磁盤過載保護(hù)晚碾，并且完全兼容開源社區(qū)的 kafka抓半；

• 網(wǎng)關(guān)層：引擎層之上我們設(shè)計了網(wǎng)關(guān)層，網(wǎng)關(guān)層的設(shè)計非常巧妙格嘁，主要提供：安全管控笛求、topic 限流、服務(wù)發(fā)現(xiàn)糕簿、降級能力探入，具體詳見后文“安全性”的內(nèi)容；

• 服務(wù)層：基于kafka gateway 我們在 kafka manager 上提供了豐富的功能懂诗，主要有：topic 管理蜂嗽、監(jiān)控管理、集群管理等殃恒；

• 平臺層：對外提供了一套 web 平臺植旧，分別針對普通用戶和運維用戶，提供不同的功能頁面离唐，盡可能的將一些日常使用中的高頻操作在平臺上進(jìn)行承接病附，降低用戶的使用成本。

圖片

**********▍********3. 應(yīng)用邏輯架構(gòu)******

在實際的應(yīng)用部署和關(guān)聯(lián)上亥鬓，整體的 kafka manager 和 kafka 引擎完沪、kafka gateway 之間的邏輯關(guān)系比較簡單，具體如下圖所示：

• kafka gateway 包括兩大塊功能：服務(wù)發(fā)現(xiàn)嵌戈、元數(shù)據(jù)網(wǎng)關(guān)覆积，詳細(xì)介紹見后面的元數(shù)據(jù)網(wǎng)關(guān)設(shè)計一節(jié)。

• kafka manager 提供我們開發(fā)的特色功能熟呛，如：topic管理技健、監(jiān)控管理、集群管理惰拱，以及相應(yīng)的 web 平臺，普通用戶和研發(fā)運維人員日常操作接觸最多，最高頻的操作都將這上面完成偿短。

圖片

***3. ***

安全性

image.gif

以kafka 數(shù)據(jù)的安全性和集群使用過程中的穩(wěn)定性保障是我們在構(gòu)思和設(shè)計整個 kafka 云平臺時首要考慮的問題欣孤，為此我們設(shè)計了一套 kafka 元數(shù)據(jù)網(wǎng)關(guān)和多租戶的隔離模型來解決這些問題。******▍********1. 元數(shù)據(jù)網(wǎng)關(guān)設(shè)計**

用戶在接入原始的 kafka 集群時沒有安全管控昔逗，無法有效的管理用戶的使用行為降传，對數(shù)據(jù)安全和集群穩(wěn)定性造成嚴(yán)重的風(fēng)險，因此我們設(shè)計了一套 kafka 集群元數(shù)據(jù)網(wǎng)關(guān)系統(tǒng)來解決安全問題勾怒。

kafka gateway 系統(tǒng)除了解決數(shù)據(jù)的安全風(fēng)險還附帶了以下作用：

• 提供 kafka 集群的服務(wù)發(fā)現(xiàn)服務(wù)節(jié)點婆排，這樣用戶在使用 kafka 集群服務(wù)時，當(dāng) kafka cluster boostrap 地址變更時笔链，則不需要用戶改動 kafka 的連接地址段只，不用重啟 kafka client，保障集群的變更對用戶透明鉴扫；

• 提供 kafka topic 生產(chǎn)和消費的限流能力赞枕，避免用戶無限制的使用集群的流量，流量大的用戶會耗盡系統(tǒng)資源從而影響其他用戶的使用坪创，造成集群的節(jié)點故障炕婶；

需要注明說明一點，kafka gateway 的設(shè)計很巧妙的將這些功能實現(xiàn)在 kafka 引擎內(nèi)部莱预。因為 kafka 作為一個消息系統(tǒng)柠掂，其本身流量是非常的巨大，如果 kafka gateway 作為一個單獨應(yīng)用存在依沮，所有流量都先通過 gateway 再進(jìn)入 kafka 引擎涯贞，則對 kafka gateway 機器資源的消耗是非常巨大的，基本等同于需要增加一倍的機器資源悉抵，并且整個流程的耗時也會增加肩狂。所以在設(shè)計之初，就把 kafka gateway 和 kafka 引擎合在一起姥饰，這便是滴滴 kafka 引擎的特色能力所在傻谁。

搭建好 kafka gateway 系統(tǒng)之后，用戶使用 kafka topic 的流程變?yōu)槿缦拢?/p>

• 在 kafka manager 上申請租戶(appid)列粪，獲取到對應(yīng)的租戶密碼(app-password)审磁；

• 利用 appid 申請創(chuàng)建新的 topic，或者申請已存在的 topic 的生產(chǎn)和消費權(quán)限岂座；

• 使用 kafka client 時設(shè)置好對應(yīng)的 appid 和 app-password态蒂，相應(yīng)的 topic 鑒權(quán)，限流都在 kafka broker 端完成费什。

圖片

******▍********2. 多租戶隔離模型**

在滴滴內(nèi)部钾恢，絕大部分的 topic 是在共享集群上的，在沒有管控的情況下，topic 的各個分區(qū)是隨機的分布在不同的 broker 上瘩蚪，隨著集群中 topic 數(shù)量的增加泉懦，topic 流量的變大，某個具體 topic 的抖動有可能會影響到其他的 topic疹瘦，因此共享集群下的 topic 隔離就是非常必要的崩哩，為此我們結(jié)合 kafka gateway 在 kafka manager 上設(shè)計了一套多租戶隔離模型來解決這個問題，具體操作如下：

• 對將kafka 集群中的各個 broker 進(jìn)行劃分言沐，一組 broker 被分成一個 region邓嘹，這個 region 在業(yè)務(wù)上被抽象為一個邏輯集群；

• 用戶在申請創(chuàng)建新的 topic 時需要選擇一個邏輯集群险胰，這樣 topic 的分區(qū)只能創(chuàng)建在一個邏輯集群上汹押，也就是一組 broker 上；

• 具體 topic 消息的生產(chǎn)和消費就只會和一組 broker 發(fā)生關(guān)系鸯乃，如果某個 topic 的抖動也只會影響特定 broker 上的其他 topic鲸阻，從而將影響限定在一定的范圍內(nèi)。

圖片

***4. ***

平臺化

image.gif

滴滴 kafka manager 平臺建設(shè)之初就把易用性作為主要目標(biāo)缨睡，因此在產(chǎn)品設(shè)計上非常注重用戶的使用體驗鸟悴，前期通過反復(fù)的用戶調(diào)研和內(nèi)部討論，最終提煉出普通用戶和運維用戶的高頻操作奖年，將這些操作都通過平臺實現(xiàn)细诸，降低用戶的使用成本。

• 方便的日常用戶使用

1. 用戶只關(guān)注自己的Topic的信息(默認(rèn))陋守，以減少不必要信息的干擾震贵；

2. 足夠的指標(biāo)信息，以保證用戶能自助解決問題的同時減少不必要信息的干擾水评；

• 高效的運維操作

1. 提煉用戶猩系、運維人員創(chuàng)建Topic、調(diào)整配額中燥、擴展分區(qū)寇甸、集群遷移、集群重啟等高頻運維操作疗涉，將高頻操作平臺化拿霉，簡化用戶操作，大大降低運維成本咱扣。

2. 提供整體集群直觀的全局視角绽淘，以提高排查問題的效率以及對集群規(guī)模的直觀感知，并提供詳盡的局部視角闹伪，以提高排查問題的效率沪铭；

• 友好的生態(tài)

  內(nèi)部版本與滴滴監(jiān)控系統(tǒng)打通壮池，開源版本與滴滴開源的夜鶯監(jiān)控告警系統(tǒng)打通，集成監(jiān)控告警伦意、集群部署火窒、集群升級等能力，形成運維生態(tài)驮肉，凝練專家服務(wù)，使運維更高效已骇。

• **體貼的細(xì)節(jié) **

  kafka 云平臺的建設(shè)离钝，它有著自己的設(shè)計理念，如：應(yīng)用褪储、權(quán)限卵渴、限流等；kafka 集群的 broker 和 topic 的上也存在著各種指標(biāo)鲤竹，操作任務(wù)浪读，審批流程等，這些都會對用戶的使用造成困惑辛藻。雖然產(chǎn)品同學(xué)在反復(fù)的體驗和持續(xù)的優(yōu)化迭代碘橘，但是為了進(jìn)一步的方便用戶使用，我們在各種用戶可能感覺到困惑指標(biāo)含義的地方吱肌，設(shè)置了大量的提示說明痘拆，讓用戶不用出頁面就可以基本解決問題，整個使用過程力爭如絲般順滑氮墨。

• 出眾的顏值

  常見的內(nèi)部工具型產(chǎn)品往往都是以滿足功能和需求為主纺蛆，很多都是功能在頁面上的堆砌，kafka 云平臺在建設(shè)之初规揪，在產(chǎn)品設(shè)計和前端開發(fā)上也力求更高的標(biāo)準(zhǔn)桥氏，最終整體的風(fēng)格相比以往提升巨大，一上線就被用戶稱贊為 “大廠出品” 猛铅，相比目前幾款主流開源的 kafka 管理平臺字支，在頁面美觀程度上大大超出其他同類產(chǎn)品，可以說是“我花開后百花殺”奕坟。

***5. ***

可視化

image.gif

運維人員在日常進(jìn)行kafka 集群維護(hù)和穩(wěn)定性保障過程中祥款，對集群和 topic 的各項指標(biāo)都非常關(guān)注，因此指標(biāo)采集展示的準(zhǔn)確性和及時性變得非常重要月杉。為此我們將指標(biāo)的可視化也作為 kafka manager 建設(shè)的核心目標(biāo)刃跛。

• 黃金指標(biāo)定義

針對 broker 和 topic 日常監(jiān)控和診斷問題過程中最主要的指標(biāo)進(jìn)行篩選，這些指標(biāo)被定義為黃金指標(biāo)苛萎，如：topic 的 messageIn桨昙、byteIn等检号，并在平臺的相關(guān)頁面上進(jìn)行高優(yōu)高亮展示，便于用戶在日常使用過程中蛙酪，快速診斷和定位集群可能存在的問題齐苛。同時我們還根據(jù) broker 和 topic 的指標(biāo)監(jiān)控，制定了一套用于快速識別其運行狀態(tài)的健康分算法桂塞，將多個指標(biāo)進(jìn)行加權(quán)計算凹蜂，最終得到一個健康分?jǐn)?shù)值，健康分的高低則直觀的展示了 broker 和 topic 實際運行過程中的狀態(tài)阁危，便于用戶和運維快速從多個 broker 和 topic 中識別玛痊。

• 業(yè)務(wù)過程數(shù)據(jù)化

增加基于 topic 生產(chǎn)消費各環(huán)節(jié)的耗時統(tǒng)計，支持動態(tài)開啟與關(guān)閉狂打，幫助用戶自助排查問題擂煞；關(guān)鍵指標(biāo)業(yè)務(wù)運行過程化，不同分位數(shù)性能指標(biāo)的監(jiān)控趴乡，方便歷史問題回溯診斷对省。

• 服務(wù)端強管控

服務(wù)端記錄客戶端連接版本和類型，連接強感知晾捏，集群強管控蒿涎，元信息的基石；controller 強管控粟瞬，指定的主機列表同仆，記錄 controller 歷史運行節(jié)點；記錄 topic 的壓縮格式裙品，應(yīng)用與業(yè)務(wù)元信息俗批，業(yè)務(wù)強感知。

***6. ***

專家化

圖片

基于之前全面的kafka數(shù)據(jù)采集市怎，和運維同學(xué)在日常操作過程中的一些經(jīng)驗總結(jié)岁忘，我們將高頻的問題和操作沉淀形成特有的專家服務(wù)，來智能診斷 kafka 集群和 topic 的健康狀態(tài)区匠，并提供對應(yīng)的處理方案干像。

kafka manager 的專家服務(wù)能提供了以下功能：

• 分區(qū)熱點遷移

1. 背景：Kafka只具備Topic遷移的能力，但是不具備自動均衡的能力驰弄，Region內(nèi)部分Broker壓力非常大麻汰，但是部分Broker壓力又很低，高低不均戚篙。如果不立即處理五鲫，輕則無法繼續(xù)承接用戶的需求，重則由于部分Broker壓力過大導(dǎo)致集群出現(xiàn)穩(wěn)定性問題岔擂。

2. 解決方案：

3. 在滴滴 kafka 引擎上增加 topic 在不同磁盤上分布的指標(biāo)位喂；

4. kafka manager 通過定時采集的 topic 指標(biāo)來分析 topic在不同磁盤上的分布均勻度浪耘；

5. 針對不均勻的 topic 發(fā)起遷移操作，并在遷移時進(jìn)行流量控制塑崖，保證遷移不會影響集群的穩(wěn)定性七冲。

• 分區(qū)不足擴容

1. 背景：kafka 集群的 topic 相關(guān)的元信息存儲在 zookpeer 上，最終由 controller 將其同步到各個broker规婆。如果元信息過大澜躺，controller 同步的壓力就會隨之上升成為整個集群的瓶頸點，如果遇到某臺 broker 出現(xiàn)問題聋呢，整個集群的數(shù)據(jù)同步就非常慢苗踪，從而影響穩(wěn)定性。

2. 解決方案：

3. 在用戶申請創(chuàng)建 topic 的時候削锰，平臺進(jìn)行分區(qū)數(shù)的管控，分區(qū)數(shù)不能設(shè)置的特別大毕莱，然而隨著 topic 流量的上升器贩，topic 分區(qū)可能不足。如果遇到 topic 流量突增朋截，超過了單分區(qū)能承載的能力蛹稍，會導(dǎo)致分區(qū)所在的Broker出現(xiàn)壓力绣版，如cpu和load升高等問題园蝠，客戶端也會出現(xiàn)發(fā)送堆積的情況。

4. 基于現(xiàn)有的機型以及客戶端的消費發(fā)送能力的壓測舞竿，我們定義了單分區(qū)的承載流量廓八，同時我們實時對每個 topic 的流量進(jìn)行監(jiān)控奉芦，當(dāng)某個 topic 的峰值流量持續(xù)的達(dá)到和超過閾值之后，會對該 topic 進(jìn)行標(biāo)記或者告警剧蹂，定義為分區(qū)不足的 topic声功。

5. 針對監(jiān)控發(fā)現(xiàn)出來的分區(qū)不足的 topic，由運維人員手動進(jìn)行擴分區(qū)宠叼，或者 kafka manager 根據(jù)當(dāng)前集群整個容量情況自動進(jìn)行擴分區(qū)先巴。

• topic資源治理

1. 背景：公共集群中用戶申請創(chuàng)建的 topic，它們的使用情況是各不相同的冒冬，還存在著部分 topic 根本不使用還占據(jù)集群元數(shù)據(jù)的情況伸蚯，這對本來就十分擁擠的公共集群造成很大的資源浪費和穩(wěn)定性風(fēng)險，因此針對集群中的不使用的 topic進(jìn)行治理就非常必要简烤。

2. 解決方案:

3. 實時對集群中所有 topic 的流量進(jìn)行采集監(jiān)控剂邮，智能的分析 topic 的流量趨勢，如果發(fā)現(xiàn) topic 的流量持續(xù)在一段時間內(nèi)為0乐埠，則進(jìn)行標(biāo)記或者告警抗斤。

4. 針對監(jiān)控發(fā)現(xiàn)的一定周期無流量囚企、無生產(chǎn)消費鏈接的topic，進(jìn)行通知和下線清理操作瑞眼。

***7. ***

同類對比

image.gif

我們來和外部類似的產(chǎn)品進(jìn)行一個簡要的功能對比如下：

圖片

經(jīng)過簡單的對比龙宏，我們可以看到，經(jīng)過平臺化伤疙、可視化银酗、智能化、安全建設(shè)之后徒像，滴滴kafka manager在安全性黍特、用戶體驗、監(jiān)控锯蛀、運維管控上都有著顯著的優(yōu)勢灭衷，也提供了很多特色的功能，極大的方便了用戶和運維人員的日常使用旁涤，歡迎大家Star和體驗https://www.didiyun.com/production/logi-KafkaManager.html

***8. ***

展望

圖片

Logi-Kafka-Manager 已在滴滴內(nèi)部上線使用翔曲，未來我們除了在平臺化、可視化劈愚、智能化基礎(chǔ)上持續(xù)改進(jìn)瞳遍，還會在以下幾個方面持續(xù)努力：

• 平滑的跨集群遷移

我們將基于 MirrorMaker + KafkaGateWay 打造一套 kafka Topic 跨集群平滑遷移能力，在 kafka manager 平臺上為 kafka topic 運維管控提供更為高效的遷移能力菌羽，進(jìn)一步提升運維效率掠械。

• 更多的指標(biāo)監(jiān)控

進(jìn)一步的支持 kafka 2.5+ 最新版本的管控，并且新增更多的關(guān)鍵指標(biāo)的監(jiān)控注祖，從而讓 kafka manager 指標(biāo)展示和問題定位的能力更強大猾蒂。

• 持續(xù)回饋開源社區(qū)

作為在滴滴內(nèi)部經(jīng)過大量復(fù)雜場景驗證過的 kafka 管控平臺，我們會持續(xù)對其進(jìn)行核心業(yè)務(wù)抽象氓轰，剝離滴滴內(nèi)部依賴婚夫，回饋社區(qū)，我們也希望熱心的社區(qū)同學(xué)和我們交流想法署鸡，共同提升滴滴 Logi-KafkaManager 的功能和體驗