【51CTO.com原創(chuàng)稿件】從產(chǎn)生伊始，各類微服務就需要以不同的方式進行彼此通信。

[[253396]]

 

有些人喜歡使用 HTTP REST APIs，但是他們可能會碰到自身的隊列問題;有些人則傾向使用諸如 RabbitMQ 之類舊的消息隊列，然而他們不得不考慮擴容和運營等相關(guān)問題。

[[253397]]

 

因此以 Kafka 為核心的架構(gòu)應運而生，它旨在解決上述兩方面的問題。

在本文中，我們將和您討論 Apache Kafka 是如何改進過去在微服務中，所用到的 HTTP REST API 和消息隊列架構(gòu)，以及它是如何進一步擴展自己的服務能力。

兩大陣營的故事

第一大陣營是指：通信被通過調(diào)用諸如 HTTP REST API、或遠程過程調(diào)用(Remote Procedure Calls，RPC)等其他服務的形式來直接處理。

第二大陣營則借用了面向服務的架構(gòu)(Service-Oriented Architecture，SOA)的企業(yè)服務總線(Enterprise Service Bus)的概念，使用某個負責與其他服務進行通信的消息隊列(如 RabbitMQ)，作為消息代理來實現(xiàn)各種操作。

此法雖然能夠給通信免去逐個服務直接進行“交流”的負載，但是在網(wǎng)絡(luò)中增加了額外“一跳(hop)”的成本。

使用 HTTP REST APIs 的微服務

HTTP REST APIs 是一種在服務之間進行 RPC 的流行方式。它的主要好處在于簡化了初始化設(shè)置，并提升發(fā)送消息的相對效率。

然而，這種模式需要其實現(xiàn)者考慮隊列之類的問題，以及如何應對傳入請求的數(shù)量超過該節(jié)點容量的問題。

例如：假設(shè)您有一個服務長鏈，其中的一個 preceding(先導)超過了節(jié)點的處理容量。

那么我們就需要對該服務鏈中的所有 preceding 服務進行相同類型的背壓處理(back pressure handling，譯者注：系統(tǒng)自適應地降低源頭或者上游的發(fā)送速率)，以應對該問題。

此外，這種模式要求所有的單個 HTTP REST API 服務都具備高可用性。而在那些由各種微服務所組成的長管道(pipeline)中，沒有一個微服務可以承受失去其所有組件的“損失”。

因此，只要在給定組中至少一個進程仍在正常運行，那么這種通信就仍然可以運作。

當然，我們通常需要在這些微服務的前端配置負載均衡模塊。同時，由于不同的微服務需要知道哪里能夠通過調(diào)用來實現(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 調(diào)用而言，我們系統(tǒng)的整體復雜程度還是增加了不少。

如下圖所示，許多公司起初可能只有幾個微服務需要相互通信，而隨著其系統(tǒng)的逐漸“成長”，相互之間的調(diào)用關(guān)系和通信渠道會最終變得像一碗意大利面那些錯綜復雜。

[[253398]]

 

消息隊列

構(gòu)建微服務之間通信的另一種方式是：基于消息總線或消息隊列系統(tǒng)的使用。

以前那些舊的面向服務架構(gòu)將這種方式稱為企業(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)的架構(gòu)中，勢必會增加有待操作和維護的新組件。

同時為了發(fā)送各類消息，而在網(wǎng)絡(luò)中新增“一跳”，也將會給網(wǎng)站產(chǎn)生一些額外的延時與等待。

客觀地說，該模式通過對各種消息隊列系統(tǒng)，采用集中式的訪問控制列表(Access Control Lists，ACL)，從而簡化了各類安全事項。

即：這種集中式管控方式統(tǒng)一地運用各種規(guī)則，限定了誰可以讀取和寫入什么樣的消息。

集中式通信的另一個好處是：網(wǎng)絡(luò)安全。例如：過去所有的微服務都采用的是彼此自行通信的方式。

而采用消息代理之后，您可以將所有的連接都經(jīng)由消息隊列服務來進行中轉(zhuǎn)，通過類似防火墻的規(guī)則設(shè)定，來濾除掉其他微服務之間的直接聯(lián)絡(luò)，進而減少了被攻擊面。

以 Kafka 為中心的優(yōu)勢

由 LinkedIn 創(chuàng)建的 Apache Kafka 是一個開源的事件流平臺。與過去舊的消息隊列系統(tǒng)截然不同的是：它具有將發(fā)送者與接收者完全分離的能力。也就是說，發(fā)送者并不需要知道誰將會去接收其發(fā)送的消息。

[[253399]]

 

在其他許多消息代理系統(tǒng)中，它們必須事先知道誰會去讀取所發(fā)的消息。這多少阻礙了我們將一些新的未知用例添加到傳統(tǒng)的排隊系統(tǒng)之中。

而在使用 Apache Kafka 時，各種消息被發(fā)送者寫入一個被稱為 topic(主題)的日志式數(shù)據(jù)流里，他們完全沒有必要去關(guān)心誰、或那些應用將會真正地去讀取該消息。

因此，這留給了新的用例去根據(jù)自己的新用途，考慮如何處置 Kafka 的相關(guān) topic 內(nèi)容的發(fā)揮空間。

對于 Kafka 而言，它不但不會去理會各種發(fā)送消息的具體載荷，還會讓消息以任意方式進行序列化。

因此，大多數(shù)用戶還是會使用 JSON、AVRO、或 Protobufs 來實現(xiàn)其數(shù)據(jù)格式上的序列化。

另外，您也可以輕松地通過設(shè)置 ACL，來限制各種 producers(生產(chǎn)者)和 consumers(消費者)能夠?qū)ο到y(tǒng)中的哪些 topic 進行讀取或?qū)懭?，以便您實現(xiàn)對所有消息的集中式安全控制。

因此，您會經(jīng)常看到 Kafka 被作為一種 firehose 式數(shù)據(jù)管道，用來接收潛在的超大量數(shù)據(jù)。

例如：Netflix 公司就聲稱，他們正在使用 Kafka 來處理每天二萬億條消息的體量。

值得注意的是，Kafka 的 consumers 具有一個重要的特性：隨著消息負載的增加，Kafka 的 consumers 會根據(jù)故障和容量需求的增多而發(fā)生變化，此時 Kafka 會自動地重新平衡各個 consumers 之間的處理負荷。

可見，開發(fā)者從需要保證微服務內(nèi)部的高可用性，轉(zhuǎn)移到了 Apache Kafka 服務本身。

相應地，Kafka 這種能夠處理流數(shù)據(jù)(streaming data)的運營能力，也將其從一個消息系統(tǒng)發(fā)展成為了一個流數(shù)據(jù)平臺。

而且可喜的是，Apache Kafka 的使用雖然給網(wǎng)絡(luò)新增了額外的“一跳”，但是它作為各種請求的微服務通信總線，卻沒有增加(或者說降低了)任何延時。

 

總之，上述提到的低延時、自動擴容、集中管理、以及成熟的高可用性，都讓 Apache Kafka 在微服務的通信開發(fā)中能夠脫穎而出，為您可能用到的各種流數(shù)據(jù)實時分析創(chuàng)造了穩(wěn)定的運行環(huán)境。

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】