[[191118]]

人類如何做出決策? 在日常生活中，情感總是短路因素，導致在復雜或壓倒性的決定上扣動扳機。但對于做有長期影響，復雜決策，的表意識，不可能是純粹的沖動。高性能的人通常使用斷路器，“本能,” “直覺,” 或其他的情緒，只有一次他們的表意識，潛意識吸收了作出決定所需的所有事實。

今天有很多的消息傳遞技術, 數不清的 ESBs, 和近100 iPaaS供應商在市場上。 自然，這導致了有關如何為您的需要-特別是那些已經投資在一個特定的選擇，選擇正確的消息傳遞技術的問題 。我們批發選擇嗎? 用正確的工具做正確的工作?我們有沒有正確地布置手頭的工作以滿足業務需求? 鑒于此，對我來說，合適的工具是什么? 更糟糕的是，詳盡的市場分析可能永遠無法完成，但由于集成代碼的平均壽命，盡職調查是至關重要的。

這篇文章致力于給予潛意識，表意識 一些公平的考慮，從今天最現代，最受歡迎的選擇： RabbitMQ和Apache Kafka。 每個都有自己的起源故事, 設計意圖，使用案例，被應用, 整合能力，和開發人員的經驗。對于任何的軟件，起源揭示總體設計意圖，都是一個很好的起點。

起源

RabbitMQ 是一個 “傳統的” 消息代理，實現多種消息傳遞協議。 是第一個開源消息代理，達到合理的功能水平， 客戶端庫，開發工具，和質量文檔。 RabbitMQ 最初開發來實現AMQP，具有強大路由功能的消息傳遞的開放式路由協議。盡管Java有消息傳遞標準像JMS，但對需要傳遞消息的分布式非java應用沒有幫助，這嚴重限制了很多集成方案，微服務或單組件。隨著AMQP的到來，跨語言的靈活性，成為真正的開源消息代理。

Apache Kafka是用Scala開發的，起初應用于 LinkedIn ，作為一種簡化Hadoop 從 Apache Flume提取消息的方案。 從復數數據源消費和生產的數據，為每個源和目標配對編寫獨立的數據管道。Kafka 幫助 LinkedIn 標準化數據管道并允許將數據從每個系統中取出一次并存入每個系統一次，使管道 (和操作) 更簡單。Kafka是如今Apache Software軟件基金會的通用配置。特別地，很好的與Apache Zookeeper集成，形成了Kafka分布式分區的支柱。 許多人認為 Zookeeper的需求并不是那么高，它賦予了Kafka用戶集群的益處。

體系結構和設計

RabbitMQ i被設計為通用消息代理，采用點對點的幾種變化， 請求/答復，和發布-訂閱通信風格模式。它使用智能代理/啞消費者模型，專注于消息傳遞消費者的一致性，作為代理跟蹤消費者的狀態，保證以大致相同的速度消費。配置正確時表現良好，成熟，被支持的很好 (客戶端庫包括 Java, .NET, node.js, Ruby, PHP和很多其他語言)，有幾十個插件可用，將其擴展到更多用例和集成場景。

簡化的整體 RabbitMQ 體系結構(source).

RabbitMQ的通信，根據需要可以是同步或異步。推送者發送消息到交換區，消費者從隊列檢索消息。 通過發送消息到交換區的形式，將生產者解耦，確保生產者不承擔硬編碼路由壓力。 RabbitMQ 還提供了一些分布式部署方案 (要求所有節點可以解析主機名)。它可以設置為多節點集群為集群聯盟，并且不依賴外部服務 (但一些集群形成插件可以使用AWS APIs, DNS, Consul，等)。

Apache Kafka 是專為高容量發布-訂閱消息流設計的，意味著經久耐用， 快速，而且可擴展的。在其本質上， Kafka 提供持久的消息存儲，在某些方面類似于數據庫，在服務器集群中運行，存儲流記錄的類別稱為主題。

 全局 Apache Kafka 體系結構(1 主題, 1 分區, 4 復制因子). (source)

每條消息包含一個鍵，一個值和一個時間戳。 同RabbitMQ幾乎相反， Kafka使用了笨代理， 并使用智能消費者讀取其緩沖區。 Kafka不嘗試跟蹤那些被消費者消費的消息，只保留未讀消息;相反, Kafka保留所有消息的一組時間，消費者負責跟蹤他們在每個日志的位置 (消費狀態)。 因此，用正確的開發者人才 創建消費者代碼， Kafka 可以支持大量的消費者并且保留大量數據以很少的開銷。如上圖所示，Kafka確實需要外部服務運行 – 在這種情況下，Apache Zookeeper, 通常被認為是必要，理解，設置，和操作的。

需求和用例

許多開發人員開始探索消息傳遞，當他們意識到他們必須把很多東西連接在一起，和其他集成模式，如共享數據庫是不可行的或太危險的時候。

Apache Kafka 將其描述為分布式流媒體平臺，但更為人知的是一個持久的存儲庫，有著很好的Hadoop/Spark 支持。文檔做得很好，討論流行的用例，比如網站活動跟蹤，指標，日志聚合，流處理，事件溯源和提交日志。這些用例之一，它描述了消息，可能產生一些混亂。 所以讓我們打開一點，看的更清晰，關于哪種消息方案更適合Kafka，比如：

• 從A到B的流沒有復雜的路由， 有最大吞吐量(100k/sec+)，按分區順序交付至少一次。
• 當你的應用程序需要訪問流歷史，按分區順序交付至少一次。Kafka是持久的消息存儲和客戶可以得到一個 “replay” 事件流的需求，相對于更傳統的消息代理，一旦一個消息被交付，就會從隊列中移除。
• 當你有聰明的消費者，能可靠地跟蹤他們的日志偏移。
• 如果您的應用程序需要 “無限的” 隊列。

RabbitMQ是一個通用消息傳遞解決方案，通常用于， 當用戶等待結果時，允許web服務器快速響應請求，而不是被迫執行重資源程序。也有利于分發消息到多個消費者進行消費， 或在高負荷條件下平衡worker之間的荷載 (20k+/sec)。當你的需求超越吞吐量， RabbitMQ有很多提供： 特性，可靠消息傳遞， 路由，聯合會， HA， 安全, 管理工具和其他特性。讓我們看看一些最適合RabbitMQ的場景，比如：

• 您的應用程序需要，與現有協議組合，比如AMQP 0-9-1, STOMP, MQTT, AMQP 1.0.
• 你需要成熟，容易理解的一致性保證，為您的信息傳遞。
• 你的應用需要多種類型的點對點協議，請求/應答，和發布/訂閱 消息.
• 復雜的消費者路由，整合多個服務/應用程序，使用難以掌握的路由邏輯。
• 當與你現有的 IT 基礎設施整合很重要， RabbitMQ 更好。

RabbitMQ 也可以有效地解決幾個上面的Kafka強有力的用例，但要借助額外的軟件。RabbitMQ經常與Apache Cassandra配合使用，當應用程序需要訪問流歷史時，或與LevelDB插件，對于應用程序需要 “無限” 隊列， 但都不是RabbitMQ自帶的。

開發經驗

RabbitMQ正式支持Java, Spring, .NET, PHP, Python, Ruby, JavaScript, Go, Elixir, Objective-C, Swift – 與許多其他 客戶和開發工具，通過社區插件。RabbitMQ 客戶端庫是成熟且良好文檔的。

Apache Kafka 在這一領域已經取得了長足進步，雖然他主要是Java客戶端，有越來越多的社區目錄 開放源碼客戶端， 生態系統項目，以及作為適配器 SDK 允許您建立自己的系統集成。大部分的配置已經設定好了，通過.properties 文件或編程方式。

這兩個選項的流行，在許多其他軟件供應商，有很強的影響力，確保RabbitMQ 和Kafka正常工作，通過他們的技術。

安全和操作

安全和操作都是RabbitMQ的強項。 RabbitMQ管理插件提供了HTTP API，一個基于瀏覽器的 UI 用于管理和監控，加上CLI工具給予操作員。 外部工具，如果長期監測數據存儲，比如CollectD, Datadog或者New Relic也是需要的。 RabbitMQ還提供了API和監控工具，審核和應用故障排除。除了支持TLS，RabbitMQ附帶RBAC支持通過內置數據存儲， LDAP或外部基于HTTPS的供應商，并支持身份驗證使用x509證書，代替用戶名/密碼對。額外的身份驗證方法 可以使用插件相當直接地擴展。

這些領域對Apache Kafka.構成了挑戰。在安全方面，最近的Kafka 0.9版本附加了TLS,，JAAS基于角色的訪問控制，Kerberos/plain/scram認證，使用CLI管理安全策略。 這使得早期版本大幅改善，當時您只能在網絡級別鎖定訪問權限，對于共享或多用戶，這不起作用。

Kafka使用管理CLI由shell腳本、 屬性文件組成，特別是格式化JSON文件。 Kafka 經紀人，生產者，和消費者排放指標 通過Yammer / JMX，但不維護任何歷史，這實際意味著使用第三方監測系統。使用這些工具，操作能夠管理分區和主題，檢查消費者偏移位置，與使用Apache Zookeeper為Kafka提供的HA和FT功能。例如，一個3節點Kafka 集群 即使兩個節點失敗也能提供功能。然而，如果你想支持Zookeeper最大數目的失敗，你需要額外的5個Zookeeper節點 ，Zookeeper是基于法定人數的系統，只能容忍 N/2+1的失敗。這明顯的不應該共存與Kafka節點 – 因此，要建立的3節點卡夫卡系統，您需要大約八臺服務器。 運營商當推理任何卡夫卡系統的可用性時，考慮到ZK集群屬性，無論是資源消耗還是設計。

性能

Kafka照以下設計：100k/sec性能往往是人們選擇 Apache Kafka的關鍵驅動力。它的實現很大依賴開發者能夠寫出聰明的消費者代碼。

當然，每秒消息速率是很難狀態和量化，因為他們依賴很多，包括你的環境和硬件，工作負載的性質，使用哪種交貨保證 (e.g. 持久性是昂貴的，鏡像更是如此), etc.

20K/sec是很容易使用一個Rabbit隊列實現的， 事實上跟多一些也不是很難，只要沒有太多要求的擔保。隊列的支持，通過一個， 在本地操作系統線程池上進行協作調度的，輕量級的Erlang線程 – 因此，它自然成為了單隊列的關鍵點或瓶頸，永遠不會做比CPU周期內能得到的更多的工作。

增加信息秒速率通常歸結為妥善利用可用的并行性環境，通過諸如通過聰明的路由打破交通跨多個隊列 (從而可以同時運行不同的隊列)。當RabbitMQ實現一百萬每秒的消息傳遞， 它通常會明智的慢下來 – 但通過使用大量的資源，周圍 30 RabbitMQ節點。 大多數RabbitMQ使用者享受由三到七個RabbitMQ節點提供的高性能。

Making the Call

市場上的其他高級選項的一些研究。如果你想深入與最流行的選擇，查看 Nicolas Nannoni碩士論文 ，它獨具特色的一面，比較表在4.4節 (page 39) 兩年后仍然相當準確 – 值得一讀。

在研究時，盡可能形成涉眾和業務的循環。理解商業用例是為你的情況做出正確的選擇的最大的單因素 。 然后， 如果你是流行技術粉，你最好的辦法就是睡在上面， 讓它滲透，讓你的本能接管。 你就明白了。