分散式、高吞吐量、高可擴充套件性訊息佇列服務Kafka商業化釋出！

訊息佇列Kafka是一個分散式的、高吞吐量、高可擴充套件性訊息佇列服務，廣泛用於日誌收集、監控資料聚合、流式資料處理、線上和離線分析等，是大資料生態中不可或缺的產品之一，阿里雲提供全託管服務，使用者無需部署運維，更專業、更可靠、更安全。本文就將帶你走進訊息佇列Kafka。

訊息佇列Kafka
訊息佇列Kafka是一個分散式的、高吞吐量、高可擴充套件性訊息佇列服務。相比於Apache Kafka，訊息佇列Kafka所提供的是全託管的服務。這裡也簡單地介紹一下Apache Kafka，Apache Kafka是一個分散式的基於push-subscribe的訊息系統，它具備快速、可擴充套件、可持久化的特點。它現在是Apache旗下的一個開源系統，作為hadoop生態系統的一部分，目前被廣泛使用在大資料場景中。

而訊息佇列 Kafka 針對Apache Kafka提供全託管服務，徹底解決開源產品長期以來的痛點。使用者只需專注於業務開發，無需部署運維，低成本、更彈性、更可靠。訊息佇列產品最大的特點就是全託管服務，這裡主要涉及到兩個特性：相容性和便捷性。首先，對於相容性，訊息佇列Kafka能夠100%相容Apache Kafka，對於使用者而言，可使用各種語言的開源客戶端進行無縫接入，目前使用開源Kafka的使用者，只需要更改一個接入點就可以使用訊息佇列Kafka產品。同時，訊息佇列Kafka相容Apache Kafka的所有生態。其次，對於便捷性而言，訊息佇列Kafka不需要部署，使用者只要在購買訊息佇列Kafka後，填入例項資訊，15分鐘內就能使用訊息佇列Kafka的服務了，因此是非常便捷易用的。

上述是對於訊息佇列Kafka的整體介紹，接下來將分為痛點、優勢以及場景這三個模組與大家進行較為細節的分享。首先將與大家分享目前阿里雲針對於訊息佇列服務所收集到的使用者痛點，以及根據這些痛點來解決問題，訊息佇列Kafka所具備的優勢又是什麼，最後還將與大家介紹一下訊息佇列Kafka所適用的場景。

一、痛點：自建Kafka的煩惱
Apache Kafka運維難度大
對於Kafka而言，從使用者視角來看，是一個非常簡單的產品，其所提供的是釋出與訂閱模型。那麼，在對於Kafka進行運維方面而言，其難度又會非常大，這是因為它不僅僅需要關注整個叢集之內像broker、controller類似的角色，還需要關注其所依賴的一些產品像ZooKeeper等。所以對於以上這些模組的運維不僅僅涉及到引數的調優，同時隨著業務的增長，還會面臨擴縮容等問題。此外，還需要關注磁碟以及網路情況。因此，綜上所述，自建Kafka的運維成本和運維難度都是非常大的。接下來就為大家分享一些具體的例子。

資料混亂
一些使用者反饋在自己使用Kafka叢集的時候出現了資料混亂的問題。大家都知道，在Kafka叢集裡面存在Controller和Broker兩種角色，在Controller出現異常的情況之下，會從Broker裡面自動地選擇一個Broker成為新的Controller。但是由於網路等異常情況，最開始掛掉的Controller可能重新復活了，那麼在復活之後，對於整個叢集而言就會出現“腦裂”的情況。因為Controller的主要職責是管理整個叢集的分割槽和副本的狀態，而當出現“腦裂”就會造成資料混亂的問題，而這對於使用者而言，是不可接受的。

ZooKeeper不可用
整個Kafka叢集對於ZK是強依賴的，而ZooKeeper的運維工作也是龐大而複雜的。比如在運維人員對於ZooKeeper不是非常瞭解的情況之下，可能不知道如何部署ZooKeeper，不知道如何保證ZK在同機房或者多機房的情況下保證其一定可用，而這些往往需要運維人員的思考和權衡。而ZooKeeper上面會儲存Kafka的重要資料，當ZK不可用的情況下，整個叢集的災備選組以及儲存的資料都會受到影響。

頻寬關注
對於使用者而言，自建Kafka時不僅僅需要關注其外圍的依賴產品，其實還需要關注一個在叢集內部經常會遇到的問題——頻寬。站在使用者的使用角度來看，經常需要做出對於副本數的權衡。而為了提升可靠性以及容災能力，叢集往往需要三副本，而當副本數量一多，那麼就會涉及到機器之間的資料複製，這種情況就會增加網路的頻寬。同時，由於Broker之間是對等的，並且需要從Controller裡面同步資料。這樣一來，Controller不僅僅需要承擔自己的本身的任務，還需要對外提供服務，而就其本身的設計而言，這兩部分任務是沒有優先順序先後的，所以在叢集規模大的情況之下，就會引發網路頻寬的擁堵問題。而阿里雲訊息佇列Kafka就已經幫助使用者解決了上述問題了，使用者不需要去做備份之間的權衡，阿里雲會幫助使用者實現資料的三副本儲存，並且使得服務可用效能夠達到99.9%

磁碟運維
使用者自建Kafka還會遇到其他的一些問題，比如磁碟的運維問題。從0.110版本之後，Consumer offsets不僅僅儲存在ZK端，其可以作為一個普通的Topic儲存在Kafka叢集裡面。而整個Consumer offsets的留存策略決定了磁碟的佔用情況，因此有可能因為設定了錯誤的引數導致磁碟的佔用過高。同時，使用者經常看到的情況是：自己的叢集有100T的磁碟，僅僅使用了幾十T就已經出現了不可寫的情況。大家都知道，在Producer裡面可以通過兩種方式對於資料進行分割槽，通過Hash可能會造成Hash的傾斜，而使用RoundBobin的方式也可能導致磁碟佔用不均。對於使用者而言，其可能看到的情況是使用者明明購買了很多的磁碟，磁碟也沒有被佔滿，但是Producer卻已經不可寫了。而關於磁碟運維的細節問題，訊息佇列Kafka就已經幫助使用者解決掉了。

資料丟失
其實，對於使用者而言，最苦惱的就是資料丟失問題。Kafka為使用者提供了三種資料儲存策略，第一種可以認為是OneWay方式，第二種相當於將一個備份的資料落盤，最後一種相當於將所有備份資料落盤才能成功。對於這三種方式的選擇過程，其實就是可用性與效能之間的博弈。在網路負載很高或者磁碟很難寫入的情況下，就可能造成磁碟寫入失敗。同時，Kafka的資料最開始是儲存在PageCache上面的，並且會定時地刷到磁碟上，但是並不是每條訊息傳送成功都會儲存在磁碟上的。如果出現斷電或者機器故障的情況，儲存在記憶體中的資料就會丟失。此外，還有一種情況就是當單批資料量超過限制也會丟失資料。而使用訊息佇列Kafka，使用者就不需要去做這些資料上面的選型的博弈和考慮，因為只要訊息佇列Kafka傳送資料成功，那麼這些資料就會被持久化，保證了資料不會丟失。因為訊息佇列Kafka做了這些優化，資料的可靠性就能夠達到8個9(即99.999999%)

二、優勢
在前面與大家分享了自建Kafka所遇到的痛點，接下來將會結合上述的痛點與大家分享阿里雲訊息佇列Kafka的優勢所在以及其是如何解決上述痛點的。

開箱即用
阿里雲的訊息佇列Kafka是開箱即用的，是100%相容Apache Kafka的，原來正在使用Apache Kafka的使用者只需要更改接入點就可以無縫地接入，並且訊息佇列Kafka也能夠支援開源版本所支援的各種客戶端，與此同時也能夠相容Apache Kafka的全部生態。並且訊息佇列Kafka不需要使用者進行部署，只需要在購買之後填入使用者的例項資訊，在15分鐘之內就能使用訊息佇列Kafka的服務，非常便捷。

全託管
當使用者購買了訊息佇列Kafka之後，阿里雲會對於整個叢集進行維護並提供託管服務，這對於使用者而言，是完全的0維護成本。這樣的0維護成本又是怎樣做到的呢？阿里雲訊息佇列Kafka提供了秒級的健康巡檢以及自恢復體系，阿里雲有專業的研發和運維團隊來保障整個健康巡檢的正常執行以及自動化維護體系的可實施性。對於使用者而言，健康巡檢是整個託管的基石。那麼阿里雲又是如何為使用者提供健康巡檢的呢？為使用者所提供的健康巡檢又是哪些內容呢？其實可以分為三個層次，即機器維度、業務維度以及業務效能上面的運維。比如阿里雲會關注網路是否異常，磁碟是否故障這樣系統級別的運維和巡檢。此外，阿里雲訊息佇列Kafka還會提供業務級別的巡檢，將會關注生產和消費是否正常執行，也會關注Kafka對外提供的整體服務是否正常執行，這些都屬於業務層面上的巡檢。從效能上面，也會關注像磁碟IO請求的速度這樣指標，通過磁碟IO請求速度的變化推測出負載的情況，並進行一些告警以及自動化的處理。通過上述這樣的健康巡檢方式來檢測叢集的健康狀況。

高可靠、高可用
對於訊息佇列Kafka而言，它不僅僅對外承諾服務的資料可靠性達到了99.999999%以及服務的可用性達到了99.9%。訊息佇列Kafka對外承諾的資料可靠性和服務可用性不僅僅是通過健康巡檢來保證的，同時還做了非常多的優化。這裡簡單介紹阿里雲對於訊息佇列Kafka所做的兩個優化。在儲存層，通過儲存與計算的分離來實現優化。其次，阿里雲訊息服務Kafka還提供了自動災備，而自動災備的範圍很大，這裡可以簡單列出幾點：第一點就是當一個Broker掛掉的時候，備用的Broker將會直接啟動起來，同時當機的Broker的流量將會自動分配到存活的Broker上面，從而實現了業務完全無感知的效果。正是通過以上的方式，阿里雲訊息佇列Kafka實現了極高的資料可靠性以及服務的可用性，因此使用者根本無需擔心資料的可靠性以及服務可用性。

業務監控&報表
在系統層面，阿里雲幫助使用者運維了整個叢集，保證了可用性和可靠性。在此基礎之上，阿里雲還為業務方提供了一整套的業務監控與報表體系。在這套業務監控體系裡面，主要還是通過三個維度進行，第一個維度就是例項，所謂例項就是使用者可以理解為自建的叢集的一個概念，而實際上也就是一個叢集，每個使用者購買一個例項的時候也就能得到一個真實的小的叢集。對於例項而言，使用者所需關注的是其磁碟水位、生產者以及消費者的TPS會不會超過閾值這些異常情況。第二個維度是Topic，阿里雲也提供了一些訊息堆積的查詢情況，通過直觀的方式，使用者將能夠看到生產者是否在正常地生產著訊息，而這在開源的Kafka實現裡面也是使用者的一個痛點。在開源方案中，沒有這種相應的運維工具，使用者很難直接去對生產者進行監控。最後一個維度，也是使用者使用非常多的就是Consumer Group與Topic對應的堆積情況，目前的堆積在後續也會提供延遲的各種訊息。以上這三個是目前阿里雲訊息佇列Kafka所能夠提供的監控維度，未來也會根據使用者的反饋不斷增加相應的監控維度。

資料安全
訊息佇列Kafka提供了一系列資料安全的保障體系來保證資料的安全。首先所提供就是專有網路VPC，VPC網路是基於阿里雲構建的一個隔離的網路環境，在專有網路之間邏輯上徹底隔離。VPC網路是屬於使用者自己獨有的雲上私有網路，也就是提供給使用者的完全由自己掌控的專有網路。理論上，部署在VPC私有網路裡面就是安全的，不同使用者的雲伺服器部署在不同的專有網路，不同專有網路之間通過隧道ID進行隔離。除此之外，有一些使用者還可能有更多的需求，比如政務雲使用者除了VPC的需求之外，還需要元件與元件之間的加密，這樣的場景阿里雲也是支援的。此外，阿里雲訊息佇列Kafka還支黑白名單以及鑑權等功能，能夠通過多種的機制來保證資料的安全。

訊息佇列Kafka的優勢
上述與大家分享的就是訊息佇列Kafka的優勢，再來總結一下。訊息佇列Kafka是完全相容Apache Kafka的，Apache Kafka所能夠用到的整個生態的產品，比如上端的Flume等產品和下端的Spark、Storm、Flink以及ES等，對於訊息佇列Kafka而言也是完全相容的。其次，訊息佇列Kafka所提供的是全託管的服務，也就是說無論叢集中出現的是磁碟問題、網路問題也好，無論是Kafka本身的還是其所依賴的產品所出現的任何問題，都是有專業團隊來解決的。對於使用者而言，所能夠看到的是產品99.9%的可用性，並且能夠為使用者帶來非常穩定的狀態，而底層的技術細節則是由阿里雲專業的團隊來處理的。對於高可用以及高可靠這部分而言，其與全託管是存在強關聯的。對於資料的可靠性而言，都是每一個產品所最為重視的，因為當發生了資料的丟失，就可能使得整個的業務邏輯出現錯誤，進而引發一些重大的故障。而阿里雲所承諾的是當使用者使用訊息佇列Kafka傳送訊息，只要返回所傳送的訊息是成功的，那麼這個資料的可靠性就能夠達到8個9，這一點也是使用者所無需擔心的。同時，阿里雲訊息佇列為使用者提供了非常實用的業務報表以及靈活全面的業務監控體系，並且業務的監控和報表是基於使用者業務維度的，包括整個叢集的磁碟水位、Topic以及Consumer Group在內的所有的使用者所關心的業務相關指標，這些內容都會沉澱在訊息佇列Kafka的控制檯裡面，使用者直接登入控制檯就能夠看到整體業務的執行情況。最後一點，執行在訊息佇列Kafka上的資料是非常安全的，通過VPC網路的隔離、鑑權、加密以及黑白名單這一系列的保障能夠保證使用者的資料是非常安全的，同時訊息佇列Kafka所具有的一個巨大優勢就是其購買的每一個例項都是使用者購買所獨享的，使用者之間不會因為相互影響導致整個系統出現不穩定的情況。

三、場景
以上為大家介紹了訊息佇列Kafka的優勢，接下來為大家分享其所適用的場景。其實，可以認為訊息佇列Kafka與開源的Apache Kafka所適用的場景是一樣的，不同之處在於訊息佇列Kafka具有更高的可靠性以及可用性，同時不需要使用者自己進行運維。

構建日誌分析平臺
淘寶、天貓平臺等公司每天都會產生大量的日誌。運營、運維團隊以及一些決策人員需要對於整個的日誌資料進行分析與統計。而Kafka本身的效能是非常高效的，同時Kafka的特性決定它非常適合作為"日誌收集中心"，這是因為Kafka在採集日誌的時候業務是無感知的，其能夠相容自己的上游，能夠直接地通過配置加密訊息。當日志資料傳送到Kafka叢集裡面，其實對於業務而言是完全無侵入的。同時其在下游又能夠直接地對接Hadoop/ODPS等離線倉庫儲存和Strom/Spark等實現實時線上分析。在這樣的情況之下，使用Kafka，只需要使用者去關注整個流程裡面的業務邏輯，而無需做更多的開發就能夠實現統計、分析以及報表。

網站活動跟蹤場景
除了實現資料分析形成報表之外，Kafka還可以實現網站活動跟蹤場景。通過Kafka可以實時地收集到網站的活動資料，比如使用者對於頁面的瀏覽、搜尋以及行為等。訊息佇列Kafka可以通過Topic來對於業務上面不同的資料模型進行切分的。那麼，使用者可以按照註冊或者登入以及購買等進行切分，對於下游所需要跟蹤的場景的不同，可以對接不同的處理系統，比如實時處理、實時監控以及離線處理，Kafka在這個場景裡面是非常便捷易用的。

資料在流動中產生價值
前面兩個例子是將訊息佇列Kafka在整個解決方案裡面承擔的是資料輸入流的角色，而Kafka卻不僅僅可以充當資料的輸入流，還可以做流計算處理，比如股市走向分析、氣象資料測控、網站使用者行為分析等領域，由於在這些領域中資料產生快、實時性強、資料量大，所以很難統一採集併入庫儲存後再做處理，這便導致傳統的資料處理架構不能滿足需求。而Kafka Stream以及Storm/Samza/Spark等流計算引擎的出現，可以根據業務需求對資料進行計算分析，最終把結果儲存或者分發給需要的元件。

多路轉發
大家經常會遇到的場景就是對於不同的業務維度而言，需要不同的計算方式，比如對於對賬系統而言，可能需要實時的流處理方式；對於統計分析而言，可以使用批計算方式。而使用Kafka能夠實現多路轉發，上游生產一份資料，多個下游節點都能夠獲取這份資料並做出相應的處理，因此Kafka可以完成資料多路轉發的功能。

訊息佇列Kafka商業化釋出
訊息佇列Kafka已經在2018年7月1日正式地進行了商業化釋出。目前在華北1、華北2、華東1、華東2、華南1這5個region可商業化使用了。目前VPC內部署已支援，預計在9月會推出非VPC版本，非VPC版本主要解決的是目前公網使用者的一些接入問題以及使用經典網路的遺留存量使用者問題。在前期，訊息佇列Kafka的主要精力投入在了穩定性相關以及成本優化問題方面，而在資源報警這部分功能排期在8月份上線。

而對於使用者而言，穩定性永遠處於第一位，最後通過本次分享希望使用者能夠記住：阿里雲訊息佇列Kafka是非常易用的，和開源版本的Kafka可以實現0成本切換，同時資料可靠性和服務可用性都是非常高的，使用者再也不用擔心由於Kafka的問題導致整個業務的癱瘓。相比於阿里雲的另一款產品MQ而言，Kafka也有自己的清晰定位，就是在大資料的場景下使用Kafka，而在業務之間使用MQ。並且Kafka對於生態的對接能力是非常強大的，而MQ提供了一些增強的功能，比如事務、定時訊息以及順序訊息等。在本月是阿里雲訊息佇列Kafka的首月活動，包月將會給予8.5折優惠，則包年直接給到8折優惠。

【本文轉載自雲棲社群，原文連結：https://yq.aliyun.com/articles/620506?spm=a2c4e.11157919.spm-cont-list.5.146c27aetOkTUi，作者： 萌萌怪獸 】

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31077337/viewspace-2168772/，如需轉載，請註明出處，否則將追究法律責任。