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