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