白瑜慶：知乎基於Kubernetes的kafka平臺的設計和實現

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~

  本文首發在雲+社區，未經許可，不得轉載。

自我介紹

我是知乎的技術中臺工程師，如今是負責知乎的存儲相關組件。個人分享主要基於三個，一個是簡單介紹一下Kafka在知乎是的應用，另一個是爲何作基於Kubernetes的Kafka平臺，還有咱們如何去實現了基於Kubernetes平臺

Kafka在知乎的應用

Kafka一個是很是優秀的，消息或者是數據流的組件，在知乎承載了日誌，數據收集，消息隊列的服務日誌，顯而易見就包括業務，包括運行的DEBUG日誌關鍵性日誌。

數據傳輸，好比咱們在瀏覽知乎的時候，有些用戶行爲或者內容特徵，經過咱們這個平臺作數據的流失處理。

另一個是Kafka實現對消息服務。簡單地，就是我關注的A用戶，我是否是應該基於關注用戶行爲上作不少事情，這是一個消息隊列的服務。咱們那個平臺如今是部署超過有40個Kafka集羣，這些集羣都是獨立的。另外上面有超過一千個topic，咱們的Broker數有超過有兩千個Kafka。平臺從上線到如今已經運行有兩年了，承載的數據量都是百TB級的，咱們如今這個設計是Kafka集羣，咱們要實現多集羣。由於是對於公司內部的平臺，咱們要保證高可用，平臺架構底層實際上是廣大Broker管理員，上層是抽象出來的。Kafka的集羣對業務其實也無感，。另外就是一個管理平臺管理，我建立topic，去建立分區，或者作故障處理。第一，上層只可能有管理平臺和客戶端是對R業務有感，客戶端咱們要對客戶端進行收斂，有一個客戶端是原生支持的——Java。不一樣客端會有不一樣的表現，如今咱們須要去收斂這個詞，

爲何採用Kubernetes？

由於咱們遇到的問題在早期的時候，知乎的Kafka是一個單集羣，在你們使用率不高，或者在數據量增加不爆炸的時候，單集羣你們用得還OK時有天發現有一個Broker掛了，等到你們都掛了，這時候才發現實際上是一條路是不能夠常走的。所以咱們以爲咱們認爲集羣和大型社科系統單點，你們會依賴集權，無論任何的業務，我寫日誌也好，發消息也好，或者我去作數據傳輸也好，這是不能夠的。對於Kafka來，咱們有一個開發，有各國的Top的概念，其實發生到業務來，每一個topic都表明了不一樣的一個業務的場景，咱們以爲對業務場景在內部要作分級，好比我重要的數據，我要作分析，咱們的業務與Kafka的深耦合。當我先作了規劃，去梳理一下發現爲何我會這麼多，它topic爲何集中掛掉以後有人還沒事，還很是的憤怒，以爲簡單就是天災。

那時候咱們發現，其實咱們的日誌裏面topic有不少類型，抽樣出來，一種是日誌，一種是數據和消息。數據，好比在作一個離線計算的時候，收集了用戶數據或者我在APP裏有埋點，這些數據能夠經過開發管道或者spa或者咱們的計算任務。另一個是消息剛纔也提到，好比我用戶去作了一次關注或者點贊，觸發後面一系列處理流程，很顯然看出他們實際上是有分級的。咱們要把Kafka集羣在內部要作成多集羣的方式，然而根據咱們套配合作出劃分。

同類型的topic作不一樣集羣的管理和配置。其實最簡單的法是Kafka有分片，咱們是作高可用，日誌的分片能夠少。消息容量是小的，對於數據你們都作，好比用Kafka作數據分析，確定知道在離線技術，在數據分析時候看一下數據量是跟在線的時候應該是千倍萬倍的這種關係，那就會出現一個問題——咱們去規劃一個設計就去實施的，最後結果咱們的需求會變的很是多，好比一個A業務，我認爲很是的重要，去作一個可是承載了一個，我天天有幾百幾十T的數據，那我是否是能夠申請一個新的Broker。新的集羣，別人不要跟我摻到一塊兒，我提供的是基礎數據，這樣的話咱們遇到問題是集羣會愈來愈多，事實上如今不少已是超過四十億四十個了。服務器資源怎麼去使用？由於早期部署的時候確定單機部署，但又不是，好比我有一個普通的，好比我作了一個G，承載的數量有四個T，這樣的話我部署一個消息任務是否是有點浪費？那不數數任務它是有點就太過小，其實咱們提供一個提升資源利用率，但願從單機上部署更多的Broker，而且可以作到它們之間的相互的影響降到最低。實際上在咱們實驗實踐中，磁盤實際上是Kafka一個繞不開的問題。

首先磁盤不能夠作數據持久化，可是咱們遇到了不少的問題，有量突增的或者流量大的時候，磁盤首先容量會有問題，好比我有申請了1T的磁盤，那可能我如今寫一天給我寫兩天就已經寫到了3T。

另一個問題就是磁盤的LUTOC其實IOPS太高這種問題出現的話，開發的性能是有很大的降低的。既然Broker能夠作到多部署，那咱們就在磁盤層面上作隔離，先在保證這種不要互相影響，就是好比數據和消息，Broker在磁盤這個層面要作好，作到互相不影響，所以咱們想到的方法就是磁盤是否是能夠分開，在物理層面就分開，而且開它自己又有副本。

這種物理存在分開是能夠接受的，並且若是出現故障，徹底是在可控範圍以內的，而是可期的。所以我以爲把分開，咱們當時選服務器，正好黑石這邊也提供了一種叫高性能的服務器，其實很是知足咱們需求，它有12個高性能的磁盤，是單盤的，他不作瑞的，每一個盤就是容量還不小。它的CPU和內存上面其實有優點的，由於Kafka是對內存是有要求的，好比走的文件緩存，內存是知足我需求的CPU，如今英特爾的CPU性能還蠻。咱們就採用了黑色這款高性能服務器，如今咱們的平臺都主要部署在這種服務器。底層的服務器想好了，資源劃分想好了，就是怎麼去管理它？

咱們先講一個有意思的，咱們平臺以前有一個開發的管理平臺是自寫自演的，實現了部署Broker，包括渲染配置，去作遷移的，這個平臺比較私有，並且在運維上面或者管理上面不是很方便，並且觀衆很高興來同事都要從代碼層面學習，從那一套咱們的平臺學習影響，或者是有一個更好的方案來去解決。若是激情數增長到了保證的不可數增長，而且是服務器若是壞掉了，你看咱們如何感染管理他，調度的時候咱們如何去考慮到按照磁盤這個維度作調度。所以咱們想到QQ那鐵絲，由於以前咱們有不少的一個在容器化方面的實踐，早期在開發上QQ來此以前其實知乎在ks上部署了不少計算任務，在這上面有不少積累，因此咱們想利用它的管理功能和容器的技術進行資源管理。另一個是應用程序管理。

Kafka on Kubernetes

首先解決問題設計Kafka容器，無非就是四個問題——內存，CPU，網絡和存儲。另一個問題是咱們怎麼實現具體調度Kafka容器。

首先是內存和CPU。其實CPU是比較難以預估的，由於根據諮詢類型不一樣，對於內存和CPU消耗是不一樣的，Kafka自己是不強，依賴於CPU。可是在實際使用中仍是有些問題的，好比我們Kafka不是作批量，但不少時候有時候你們對它比較理解得透的時候，會把批量會得很小，好比我下降延遲，要保證每一條消息都確切的投放過去，把Brokers收得很小，這時候會形成一個什麼問題？CPU會高，可是很這種問題咱們能夠經過調高CPU來解決。若是不出現這種大流量的話，通常內存是不會超過八個G的，並且通常使用會更低，因此咱們的基準的容器會設置成8G根據實際使用時間長，常常會作調整，這個調整能夠在IT市場很容易改。

另外網絡方面就是咱們對外服務，採用的是一種獨立的內網ip方式，好比我每個Broker都有一個獨立的ip，實際上由於咱們的單機上會部署不少容器，因此每一個都有IP，而且將這個ip註冊在內網DNS上面，這樣照好處是對於使用者來講，不須要知道具體容器的ip。這個是網絡又有一個很好的方式——能夠作單機的多ip網絡設計，至少能夠知足咱們的需求，這是容器方面的設計。默認支持的磁盤的掛載方式是HostParh Volume，這種方式是最優的，由於Kafka在本地磁盤性能最好的，並且可以充分利用到本地的這種高效的文件緩存，咱們自己的磁盤性能也是很是棒的，至少我能夠知足個人需求。

所以咱們就應該是本地的目錄一個cosplay，也就到K2起來以後是給他的，請求的配置掛載到服務器的磁盤，黑色框是咱們的一個容器，開發目錄指向的藍色框是服務器上的一個磁盤或者服務器上的目錄。雖然咱們的集羣看來就是這個樣子的，每個方塊表明網上有不少的部署的Broker。業務上面能夠反過來看，每一個藍色的地方表明Broker。

第一，CPU和內存並非問題，網絡其實已過測試過的，服務器網絡是二世紀的20G帶寬，每一個盤咱們通過測試，是有一點幾個G性能，即使把每一個盤全部人都跑滿，其實這是災難狀況，他只有不會超過20個G，所以咱們不在考慮範圍以內，咱們考慮的是磁盤的高可用目標，讓單個集羣的Broker在節點要儘可能作到分散。

第二是節點上的存儲使用盡可能均勻。

算法是根據服務器磁盤狀態計算分數，分數高者被調度。另外就是磁盤的使用狀況，若是有更多的可用盤，咱們傾向於把Broker掛在了上面。其實它用了一個簡單的方式，假設建立一個紅色集羣，實際上A和C均可以，但C是最優的，由於C上面的Broker數比較少。若是要建立一個藍色集羣，那顯然是A是最優的。另外，在實際使用狀況下要更復雜，由於得考慮到分片的高可用。按照算法去實現會遇到了一個實際性的問題——用HostPat是有很大侷限性，一致性很差，好比須要去管理要調度的節點，由於若是用class的話須要去註冊一個自己選擇的word，或者其實我是不知道被調到哪一個節點上。另外主機上要去掛載的目錄實際上是沒有人管理的。這是咱們遇到的問題，當時咱們但願是既要利用到HostPath，只有掛在本地的磁盤這種特性來提升咱們的性能管理。

並且我要可以選出合理節點，而且可以管理到這個存儲。所以咱們在當時對Kubernetes作改造，實現磁盤和調度器的算法，能夠實現實時更新磁盤信息。可是實現方式是經過假設建立實例.

本地磁盤管理

若是Broker已經在設備上創建起來，磁盤也被用了，那如何去管理它？事實上磁盤管理只能進入第三方的Agent。

故障處理和提高資源利用時會預留空間，好比爲了快速處理故障不作簽署，首先就是成本過高，如今作的是快速恢復，所以咱們會預留1到2個盤，即快速處理盤，所以只要把軟件指向這個容器，就能夠立刻啓用，而且不會有太大的網絡開銷。另外就是在主機層面，即把分片在主機層面是作分開，作到高可用。

但咱們遇到一個問題——須要把客戶端統一，由於技術平臺化。那如何把客戶端作到統一？咱們的看這裏，客戶端能夠去讀Consul信息，檢查topic是否是有用。還有個好處是，若是作遷移的時候，由於事情使了不少方，生產和消費方式是不少的，並且通常流程是先於生產方，消費方就過來，你們可能有業務，可能你們若是按照這種註冊方式的話，其實遷移過程是能夠同步的。在這個地方更改信息，整個這個生產所生產的消費，均可以感覺到，就是另外就是易用性會提升。且用這種方式有好處是有一個集羣好比我整個集羣所有斷掉了，雖然事沒發生過，可是做爲一個備用的方式的話，咱們會有一個災備集羣把全部的客戶端均可以直接遷移過去。

Q/A

Q: 你好，麻煩問一下,一個集羣裏面可能有不少topic，不一樣的用戶消費topic的時候，用戶之間是怎麼隔離的？會不會消費到其餘的topic數據？想問一下有沒有什麼隔離的好的辦法？你一個集羣裏有多少套？集羣裏有多個topic，數據我就不想讓別人看到嗎？固然我若是提供一個客戶端給他，他就能把全部的數據看獲得，有沒有什麼好的辦法？

A：實際上是這樣的，就是在咱們的一個狀況稱，若是這個進羣它有多少Broker，假如在這個會相互影響，咱們仍是建議把它不是相互影響，由於集羣面不可能只給一個用戶只提供一個集羣，就是咱們一個大的集羣，會有不少用戶在使用他的數據，都是不一樣的topic進來的嗎？他消費的時候若是我沒有隔離的話，我只要給他客戶端，它全部的數據都看獲得嗎？只能經過我在前面去作提供什麼API服務來這種方式，有沒有？Kafka自己有沒有什麼好的辦法去自己應該是有認證。 

瞭解更多詳情，請戳下面的連接：

知乎基於Kubernetes的Kafka平臺的設計和實現.pdf

問答
apache kafka vs apache storm如何使用？
相關閱讀
陳新宇：CKafka在人臉識別PASS中的應用
楊原：騰訊雲Kafka自動化運營實踐
饒軍：Apache Kafka的過去，如今，和將來

此文已由做者受權騰訊雲+社區發佈，原文連接：https://cloud.tencent.com/developer/article/1114620?fromSource=waitui