Kafka是如何解決常見的微服務通訊問題的
微服務自成立以來就以不同的方式相互溝通。有些人更喜歡使用HTTP REST API，但這些API有自己的排隊問題，而有些則更喜歡較舊的訊息佇列，比如RabbitMQ，它們帶有擴充套件和操作方面的問題。
以Kafka為中心的架構旨在解決這兩個問題。
在本文中，我將解釋Apache Kafka如何改進微服務中使用的歷史HTTP REST API /訊息佇列體系結構以及它如何進一步擴充套件其功能。
兩個陣營的故事
我們故事中的第一個陣營是通過直接呼叫其他服務來處理通訊，通常通過HTTP REST API或其他形式的遠端過程呼叫（RPC）。
第二個陣營在借用面向服務的體系結構（SOA）的企業服務匯流排概念時，使用負責與其他服務進行通訊並作為訊息佇列執行的中介。
這個角色通常是通過使用像RabbitMQ這樣的訊息代理來完成的。這種通訊方式以額外的網路跳躍為代價消除了來自各個服務的大部分通訊負擔。
微服務使用HTTP REST API
HTTP REST API是在服務之間執行RPC的常用方法。它的主要好處是在開始時簡化設定和傳送訊息的相對效率。
但是，此模型要求其實現者考慮排隊以及如果傳入請求的數量超過節點容量時該怎麼做。例如，如果您假設在超出其容量的服務之前有一長串服務，那麼鏈中的所有前述服務都需要具有相同型別的背壓處理來應對該問題。
此外，此模型要求所有單獨的HTTP REST API服務都需要高度可用。在由微服務構成的長處理管道中，沒有一個微服務能夠丟失所有元件部分，只有當來自任何給定組的至少一個程序仍然正常執行時，這才起作用。
這通常需要將負載平衡器放在這些微服務的前面。此外，服務發現通常是必須的，因為不同的微服務需要找出呼叫的位置以便彼此通訊。
這種模式的一個優點是它提供了潛在的優秀延遲，因為在給定的請求路徑中很少有中間人，並且這些元件（如Web伺服器和負載平衡器）具有高效能且經過徹底的戰鬥測試。
不同RPC微服務之間的一般依賴性處理通常很快變得更加複雜，並最終開始減緩開發工作。為了解決這些問題，還引入了提供服務網格的Envoy代理等新方法。
雖然這些解決了模型的許多負載平衡和服務發現問題，但它們需要通過簡單，直接的RPC呼叫來提高系統的整體複雜性。
許多公司開始時只有少數微服務相互交談，但最終他們的系統變得越來越複雜，在彼此之間產生了意義上的聯絡。
訊息佇列
構建微服務通訊的另一種方式是圍繞訊息匯流排或訊息排隊系統的使用。老式的面向服務的體系結構稱為這些企業服務匯流排（ESB）。通常，他們一直是像RabbitMQ或ActiveMQ這樣的訊息代理。
訊息代理充當集中式訊息服務，通過該服務，所有有問題的微服務相互通訊，訊息服務處理諸如排隊和高可用性之類的事情，以確保服務之間的可靠通訊。
通過支援訊息佇列，可以將訊息接收到佇列中以供稍後處理，而不是在峰值需求期間處理容量最大化時丟棄它們。
但是，許多訊息代理已經證明了可擴充套件性的限制以及它們如何在叢集環境中處理訊息永續性和交付的警告。
圍繞訊息佇列的另一個大型對話主題是它們在錯誤情況下的行為，例如，訊息傳遞是否保證至少發生一次，最多一次，等等。
選擇的語義取決於訊息佇列實現，這意味著您必須熟悉其訊息傳遞語義。
此外，向體系結構新增訊息佇列會新增要操作和維護的新元件，並且通過為傳送的訊息新增一個額外的網路躍點也會增加網路延遲，這會產生額外的延遲。
通過可以與訊息排隊系統一起使用的訪問控制列表（ACL）的集中性，可以在此模型中略微簡化安全問題，從而可以集中控制誰可以讀取和寫入哪些訊息。
集中化還帶來了一些安全方面的好處。例如，您不必允許所有服務相互連線，而是隻允許連線到訊息佇列服務，並防止其他服務相互遠離，從而減少攻擊面。
以Kafka為中心的新時代的優勢
Apache Kafka是一個由LinkedIn建立和開源的事件流媒體平臺。使它與舊的訊息排隊系統完全不同的是它能夠在傳送者不知道誰將接收訊息的意義上將傳送者與接收者完全分離。
在許多其他訊息代理系統中，需要預知誰將閱讀訊息; 這阻礙了傳統排隊系統中新用例的採用。
使用Apache Kafka時，訊息被寫入稱為主題的日誌樣式流，並且寫入主題的發件人完全忘記了從那裡實際讀取訊息的人或者什麼。因此，為了一個新的目的，提出一個新的用例來處理Kafka主題內容是一切照舊的。
Kafka完全不知道已傳送訊息的有效負載，允許以任意方式序列化訊息，儘管大多數人仍然使用JSON，AVRO或Protobufs作為其序列化格式。
您還可以輕鬆設定ACL，以限制哪些生產者和消費者可以寫入和讀取系統中的哪些主題，從而為您提供對所有訊息傳遞的集中安全控制。
通常看到Kafka被用作消防風格資料管道的接收器，其資料量可能很大。例如，Netflix報告說他們每天使用Kafka處理超過兩萬億條訊息。
消費者擁有的一個重要特性是，當訊息負載增加且Kafka消費者的數量因故障或容量增加而發生變化時，Kafka將自動重新平衡消費者之間的處理負載。這使得需要從微服務中明確地處理高可用性到Apache Kafka服務本身。
處理流資料的能力將Kafka的功能擴充套件到作為訊息傳遞系統執行到流資料平臺之外。
最重要的是，Apache Kafka在將其用作微服務通訊匯流排時提供相當低的延遲，即使它為所有請求引入了額外的網路躍點。
這種低延遲，自動擴充套件，集中管理和經過驗證的高可用性的強大組合使Apache Kafka能夠將其範圍從微服務通訊擴充套件到您尚未想象的許多流實時分析用例。
原文連結：http://mushiming.top/mushblog/archives/888 ，作者：穆世明