滴滴內(nèi)部統(tǒng)一使用 kafka 作為大數(shù)據(jù)的數(shù)據(jù)通道，當(dāng)前滴滴共有幾十個(gè) kafka 集群，450+ 的節(jié)點(diǎn)，20k+ 的 kafka topic，每天2w億+的消息量；每周500+UV用戶，需要完成 topic 創(chuàng)建、申請(qǐng)、指標(biāo)查看等操作；每天運(yùn)維人員還有大量集群、topic運(yùn)維操作。因此我們需要構(gòu)建一個(gè)Kafka的管控平臺(tái)來承載這些需求。

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

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

免費(fèi)體驗(yàn)地址：http://117.51.150.133:8080/kafka ，賬戶admin/admin。

***1. ***

需求分析

圖片

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

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

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

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

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

• 用戶使用友好性

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

• 問題定位高效性

在日常使用 kafka topic 的過程中，會(huì)有大量的問題需要查看和定位，如：消息生產(chǎn)和消費(fèi)的速度、消息堆積的程度、partition的均勻度、topic的分布信息、broker的負(fù)載信息、副本的同步信息等，如何使用戶和運(yùn)維人員快速高效的定位問題、處理問題，是重點(diǎn)需要解決的問題。

• 運(yùn)維管控便利性

在日常的運(yùn)維中，會(huì)存在著大量的集群、topic的運(yùn)維操作，如：集群的部署、升級(jí)、擴(kuò)縮容、topic的遷移、leader rebalance等高頻高危的操作，怎么樣在提升運(yùn)維操作效率的同時(shí)，還要保證高危操作不會(huì)影響集群穩(wěn)定性，這個(gè)也是需要去重點(diǎn)考慮。

***2. ***

整體設(shè)計(jì)

圖片

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

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

在平臺(tái)的整體設(shè)計(jì)上，我們制定了“一點(diǎn)三化”的設(shè)計(jì)原則：

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

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

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

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

圖片

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

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

• 資源層：滴滴 kafka 引擎和 kafka manager 除了 zookpeer 之外只依賴 msyql，依賴精簡(jiǎn)，部署方便；

• 引擎層：當(dāng)前滴滴 kafka 引擎版本是2.5，我們?cè)诖嘶A(chǔ)上開發(fā)了一些自己的特性，如磁盤過載保護(hù)，并且完全兼容開源社區(qū)的 kafka；

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

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

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

圖片

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

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

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

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

圖片

***3. ***

安全性

image.gif

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

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

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

• 提供 kafka 集群的服務(wù)發(fā)現(xiàn)服務(wù)節(jié)點(diǎn)，這樣用戶在使用 kafka 集群服務(wù)時(shí)，當(dāng) kafka cluster boostrap 地址變更時(shí)，則不需要用戶改動(dòng) kafka 的連接地址，不用重啟 kafka client，保障集群的變更對(duì)用戶透明；

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

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

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

• 在 kafka manager 上申請(qǐng)租戶(appid)，獲取到對(duì)應(yīng)的租戶密碼(app-password)；

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

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

圖片

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

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

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

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

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

圖片

***4. ***

平臺(tái)化

image.gif

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

• 方便的日常用戶使用

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

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

• 高效的運(yùn)維操作

1. 提煉用戶、運(yùn)維人員創(chuàng)建Topic、調(diào)整配額、擴(kuò)展分區(qū)、集群遷移、集群重啟等高頻運(yùn)維操作，將高頻操作平臺(tái)化，簡(jiǎn)化用戶操作，大大降低運(yùn)維成本。

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

• 友好的生態(tài)

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

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

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

• 出眾的顏值

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

***5. ***

可視化

image.gif

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

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

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

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

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

• 服務(wù)端強(qiáng)管控

服務(wù)端記錄客戶端連接版本和類型，連接強(qiáng)感知，集群強(qiáng)管控，元信息的基石；controller 強(qiáng)管控，指定的主機(jī)列表，記錄 controller 歷史運(yùn)行節(jié)點(diǎn)；記錄 topic 的壓縮格式，應(yīng)用與業(yè)務(wù)元信息，業(yè)務(wù)強(qiáng)感知。

***6. ***

專家化

圖片

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

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

• 分區(qū)熱點(diǎn)遷移

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

2. 解決方案：

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

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

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

• 分區(qū)不足擴(kuò)容

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

2. 解決方案：

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

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

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

• topic資源治理

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

2. 解決方案:

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

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

***7. ***

同類對(duì)比

image.gif

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

圖片

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

***8. ***

展望

圖片

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

• 平滑的跨集群遷移

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

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

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

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

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