建站
咨詢
售后
建站咨詢
新聞中心
Kafka是如何處理Netflix每天2萬億條消息的，相信很多沒有經(jīng)驗(yàn)的人對(duì)此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個(gè)問題。
從產(chǎn)生伊始，各類微服務(wù)就需要以不同的方式進(jìn)行彼此通信。
有些人喜歡使用 HTTP REST APIs，但是他們可能會(huì)碰到自身的隊(duì)列問題；有些人則傾向使用諸如 RabbitMQ 之類舊的消息隊(duì)列，然而他們不得不考慮擴(kuò)容和運(yùn)營等相關(guān)問題。
因此以 Kafka 為核心的架構(gòu)應(yīng)運(yùn)而生，它旨在解決上述兩方面的問題。
我們將和您討論 Apache Kafka 是如何改進(jìn)過去在微服務(wù)中，所用到的 HTTP REST API 和消息隊(duì)列架構(gòu)，以及它是如何進(jìn)一步擴(kuò)展自己的服務(wù)能力。
兩大陣營的故事
第一大陣營是指：通信被通過調(diào)用諸如 HTTP REST API、或遠(yuǎn)程過程調(diào)用（Remote Procedure Calls，RPC）等其他服務(wù)的形式來直接處理。
第二大陣營則借用了面向服務(wù)的架構(gòu)（Service-Oriented Architecture，SOA）的企業(yè)服務(wù)總線（Enterprise Service Bus）的概念，使用某個(gè)負(fù)責(zé)與其他服務(wù)進(jìn)行通信的消息隊(duì)列（如 RabbitMQ），作為消息代理來實(shí)現(xiàn)各種操作。
此法雖然能夠給通信免去逐個(gè)服務(wù)直接進(jìn)行“交流”的負(fù)載，但是在網(wǎng)絡(luò)中增加了額外“一跳（hop）”的成本。
使用 HTTP REST APIs 的微服務(wù)
HTTP REST APIs 是一種在服務(wù)之間進(jìn)行 RPC 的流行方式。它的主要好處在于簡化了初始化設(shè)置，并提升發(fā)送消息的相對(duì)效率。
然而，這種模式需要其實(shí)現(xiàn)者考慮隊(duì)列之類的問題，以及如何應(yīng)對(duì)傳入請(qǐng)求的數(shù)量超過該節(jié)點(diǎn)容量的問題。
例如：假設(shè)您有一個(gè)服務(wù)長鏈，其中的一個(gè) preceding（先導(dǎo)）超過了節(jié)點(diǎn)的處理容量。
那么我們就需要對(duì)該服務(wù)鏈中的所有 preceding 服務(wù)進(jìn)行相同類型的背壓處理（back pressure handling，譯者注：系統(tǒng)自適應(yīng)地降低源頭或者上游的發(fā)送速率），以應(yīng)對(duì)該問題。
此外，這種模式要求所有的單個(gè) HTTP REST API 服務(wù)都具備高可用性。而在那些由各種微服務(wù)所組成的長管道（pipeline）中，沒有一個(gè)微服務(wù)可以承受失去其所有組件的“損失”。
因此，只要在給定組中至少一個(gè)進(jìn)程仍在正常運(yùn)行，那么這種通信就仍然可以運(yùn)作。
當(dāng)然，我們通常需要在這些微服務(wù)的前端配置負(fù)載均衡模塊。同時(shí)，由于不同的微服務(wù)需要知道哪里能夠通過調(diào)用來實(shí)現(xiàn)通信，因此服務(wù)發(fā)現(xiàn)（service discovery）模塊也往往是必須的。
這種模式的優(yōu)點(diǎn)之一在于：延時(shí)非常低。由于在給定的請(qǐng)求路徑上，幾乎省去了中間人的角色，因此，諸如 Web 服務(wù)器和負(fù)載平衡之類的組件，都經(jīng)得起實(shí)戰(zhàn)的“檢驗(yàn)”，并具有高性能。
可見，對(duì)于不同 RPC 類型的微服務(wù)而言，我們需要處理它們之間的普通依賴性，因此它們往往會(huì)很快變得相當(dāng)復(fù)雜，并最終影響、甚至拖慢開發(fā)的進(jìn)程。
如今，業(yè)界也推出了一些新的解決方案。例如 Envoy 代理，它使用的是服務(wù)網(wǎng)格（service mesh）來解決此類問題。
雖然該模式解決了諸如負(fù)載均衡和服務(wù)發(fā)現(xiàn)等問題，但是相對(duì)于簡單且直接的 RPC 調(diào)用而言，我們系統(tǒng)的整體復(fù)雜程度還是增加了不少。
如下圖所示，許多公司起初可能只有幾個(gè)微服務(wù)需要相互通信，而隨著其系統(tǒng)的逐漸“成長”，相互之間的調(diào)用關(guān)系和通信渠道會(huì)最終變得像一碗意大利面那些錯(cuò)綜復(fù)雜。
消息隊(duì)列
構(gòu)建微服務(wù)之間通信的另一種方式是：基于消息總線或消息隊(duì)列系統(tǒng)的使用。
以前那些舊的面向服務(wù)架構(gòu)將這種方式稱為企業(yè)服務(wù)總線（ESB）。通常情況下，它們需要用 RabbitMQ 或 ActiveMQ 作為消息代理（message brokers）。
消息代理作為集中式的消息服務(wù)，能夠方便所有與之相連的微服務(wù)進(jìn)行彼此通信。
同時(shí)，借助消息服務(wù)的排隊(duì)處理機(jī)制和高可用性，各個(gè)服務(wù)之間的通信也能夠得以保障。
例如：有了消息隊(duì)列的支持，各種消息能夠被有序地接收到，以便系統(tǒng)進(jìn)行后期處理。
而不會(huì)在出現(xiàn)請(qǐng)求峰值，且超過了處理容量的極限時(shí)，系統(tǒng)直接丟棄后續(xù)的隊(duì)列。
然而，許多消息代理都已經(jīng)明確地告知用戶：它們?cè)诩涵h(huán)境中，對(duì)于消息的傳遞和持久性的處理能力缺少可擴(kuò)展性，甚至有所限制。
對(duì)于消息隊(duì)列而言，另一個(gè)值得專注的地方是：它們?cè)阱e(cuò)誤發(fā)生時(shí)的處理方式。
例如：系統(tǒng)在消息傳遞過程的可靠機(jī)制，是能夠至少保證一次呢？還是最多也只能保證有一次？
當(dāng)然，其語義的選擇，則完全依賴于消息隊(duì)列的實(shí)現(xiàn)。也就是說，您必須熟悉自己所選用的消息傳遞、及其相配的語義規(guī)則。
此外，將消息隊(duì)列添加到現(xiàn)有系統(tǒng)的架構(gòu)中，勢必會(huì)增加有待操作和維護(hù)的新組件。
同時(shí)為了發(fā)送各類消息，而在網(wǎng)絡(luò)中新增“一跳”，也將會(huì)給網(wǎng)站產(chǎn)生一些額外的延時(shí)與等待。
客觀地說，該模式通過對(duì)各種消息隊(duì)列系統(tǒng)，采用集中式的訪問控制列表（Access Control Lists，ACL），從而簡化了各類安全事項(xiàng)。
即：這種集中式管控方式統(tǒng)一地運(yùn)用各種規(guī)則，限定了誰可以讀取和寫入什么樣的消息。
集中式通信的另一個(gè)好處是：網(wǎng)絡(luò)安全。例如：過去所有的微服務(wù)都采用的是彼此自行通信的方式。
而采用消息代理之后，您可以將所有的連接都經(jīng)由消息隊(duì)列服務(wù)來進(jìn)行中轉(zhuǎn)，通過類似防火墻的規(guī)則設(shè)定，來濾除掉其他微服務(wù)之間的直接聯(lián)絡(luò)，進(jìn)而減少了被攻擊面。
以 Kafka 為中心的優(yōu)勢
由 LinkedIn 創(chuàng)建的 Apache Kafka 是一個(gè)開源的事件流平臺(tái)。與過去舊的消息隊(duì)列系統(tǒng)截然不同的是：它具有將發(fā)送者與接收者完全分離的能力。也就是說，發(fā)送者并不需要知道誰將會(huì)去接收其發(fā)送的消息。
在其他許多消息代理系統(tǒng)中，它們必須事先知道誰會(huì)去讀取所發(fā)的消息。這多少阻礙了我們將一些新的未知用例添加到傳統(tǒng)的排隊(duì)系統(tǒng)之中。
而在使用 Apache Kafka 時(shí)，各種消息被發(fā)送者寫入一個(gè)被稱為 topic（主題）的日志式數(shù)據(jù)流里，他們完全沒有必要去關(guān)心誰、或那些應(yīng)用將會(huì)真正地去讀取該消息。
因此，這留給了新的用例去根據(jù)自己的新用途，考慮如何處置 Kafka 的相關(guān) topic 內(nèi)容的發(fā)揮空間。
對(duì)于 Kafka 而言，它不但不會(huì)去理會(huì)各種發(fā)送消息的具體載荷，還會(huì)讓消息以任意方式進(jìn)行序列化。
因此，大多數(shù)用戶還是會(huì)使用 JSON、AVRO、或 Protobufs 來實(shí)現(xiàn)其數(shù)據(jù)格式上的序列化。
另外，您也可以輕松地通過設(shè)置 ACL，來限制各種 producers（生產(chǎn)者）和 consumers（消費(fèi)者）能夠?qū)ο到y(tǒng)中的哪些 topic 進(jìn)行讀取或?qū)懭?，以便您?shí)現(xiàn)對(duì)所有消息的集中式安全控制。
因此，您會(huì)經(jīng)?？吹?Kafka 被作為一種 firehose 式數(shù)據(jù)管道，用來接收潛在的超大量數(shù)據(jù)。
例如：Netflix 公司就聲稱，他們正在使用 Kafka 來處理每天二萬億條消息的體量。
值得注意的是，Kafka 的 consumers 具有一個(gè)重要的特性：隨著消息負(fù)載的增加，Kafka 的 consumers 會(huì)根據(jù)故障和容量需求的增多而發(fā)生變化，此時(shí) Kafka 會(huì)自動(dòng)地重新平衡各個(gè) consumers 之間的處理負(fù)荷。
可見，開發(fā)者從需要保證微服務(wù)內(nèi)部的高可用性，轉(zhuǎn)移到了 Apache Kafka 服務(wù)本身。
相應(yīng)地，Kafka 這種能夠處理流數(shù)據(jù)（streaming data）的運(yùn)營能力，也將其從一個(gè)消息系統(tǒng)發(fā)展成為了一個(gè)流數(shù)據(jù)平臺(tái)。
而且可喜的是，Apache Kafka 的使用雖然給網(wǎng)絡(luò)新增了額外的“一跳”，但是它作為各種請(qǐng)求的微服務(wù)通信總線，卻沒有增加（或者說降低了）任何延時(shí)。
看完上述內(nèi)容，你們掌握Kafka是如何處理Netflix每天2萬億條消息的的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道，感謝各位的閱讀！
分享標(biāo)題：Kafka是如何處理Netflix每天2萬億條消息的-創(chuàng)新互聯(lián)
轉(zhuǎn)載源于：http://fisionsoft.com.cn/article/djdedc.html
