[[191118]]

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

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

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

起源

RabbitMQ 是一個(gè) “傳統(tǒng)的” 消息代理，實(shí)現(xiàn)多種消息傳遞協(xié)議。 是第一個(gè)開源消息代理，達(dá)到合理的功能水平， 客戶端庫(kù)，開發(fā)工具，和質(zhì)量文檔。 RabbitMQ 最初開發(fā)來(lái)實(shí)現(xiàn)AMQP，具有強(qiáng)大路由功能的消息傳遞的開放式路由協(xié)議。盡管Java有消息傳遞標(biāo)準(zhǔn)像JMS，但對(duì)需要傳遞消息的分布式非java應(yīng)用沒有幫助，這嚴(yán)重限制了很多集成方案，微服務(wù)或單組件。隨著AMQP的到來(lái)，跨語(yǔ)言的靈活性，成為真正的開源消息代理。

Apache Kafka是用Scala開發(fā)的，起初應(yīng)用于 LinkedIn ，作為一種簡(jiǎn)化Hadoop 從 Apache Flume提取消息的方案。 從復(fù)數(shù)數(shù)據(jù)源消費(fèi)和生產(chǎn)的數(shù)據(jù)，為每個(gè)源和目標(biāo)配對(duì)編寫?yīng)毩⒌臄?shù)據(jù)管道。Kafka 幫助 LinkedIn 標(biāo)準(zhǔn)化數(shù)據(jù)管道并允許將數(shù)據(jù)從每個(gè)系統(tǒng)中取出一次并存入每個(gè)系統(tǒng)一次，使管道 (和操作) 更簡(jiǎn)單。Kafka是如今Apache Software軟件基金會(huì)的通用配置。特別地，很好的與Apache Zookeeper集成，形成了Kafka分布式分區(qū)的支柱。 許多人認(rèn)為 Zookeeper的需求并不是那么高，它賦予了Kafka用戶集群的益處。

體系結(jié)構(gòu)和設(shè)計(jì)

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

簡(jiǎn)化的整體 RabbitMQ 體系結(jié)構(gòu)(source).

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

Apache Kafka 是專為高容量發(fā)布-訂閱消息流設(shè)計(jì)的，意味著經(jīng)久耐用， 快速，而且可擴(kuò)展的。在其本質(zhì)上， Kafka 提供持久的消息存儲(chǔ)，在某些方面類似于數(shù)據(jù)庫(kù)，在服務(wù)器集群中運(yùn)行，存儲(chǔ)流記錄的類別稱為主題。

 全局 Apache Kafka 體系結(jié)構(gòu)(1 主題, 1 分區(qū), 4 復(fù)制因子). (source)

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

需求和用例

許多開發(fā)人員開始探索消息傳遞，當(dāng)他們意識(shí)到他們必須把很多東西連接在一起，和其他集成模式，如共享數(shù)據(jù)庫(kù)是不可行的或太危險(xiǎn)的時(shí)候。

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

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

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

• 您的應(yīng)用程序需要，與現(xiàn)有協(xié)議組合，比如AMQP 0-9-1, STOMP, MQTT, AMQP 1.0.
• 你需要成熟，容易理解的一致性保證，為您的信息傳遞。
• 你的應(yīng)用需要多種類型的點(diǎn)對(duì)點(diǎn)協(xié)議，請(qǐng)求/應(yīng)答，和發(fā)布/訂閱 消息.
• 復(fù)雜的消費(fèi)者路由，整合多個(gè)服務(wù)/應(yīng)用程序，使用難以掌握的路由邏輯。
• 當(dāng)與你現(xiàn)有的 IT 基礎(chǔ)設(shè)施整合很重要， RabbitMQ 更好。

RabbitMQ 也可以有效地解決幾個(gè)上面的Kafka強(qiáng)有力的用例，但要借助額外的軟件。RabbitMQ經(jīng)常與Apache Cassandra配合使用，當(dāng)應(yīng)用程序需要訪問流歷史時(shí)，或與LevelDB插件，對(duì)于應(yīng)用程序需要 “無(wú)限” 隊(duì)列， 但都不是RabbitMQ自帶的。

開發(fā)經(jīng)驗(yàn)

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

Apache Kafka 在這一領(lǐng)域已經(jīng)取得了長(zhǎng)足進(jìn)步，雖然他主要是Java客戶端，有越來(lái)越多的社區(qū)目錄 開放源碼客戶端， 生態(tài)系統(tǒng)項(xiàng)目，以及作為適配器 SDK 允許您建立自己的系統(tǒng)集成。大部分的配置已經(jīng)設(shè)定好了，通過.properties 文件或編程方式。

這兩個(gè)選項(xiàng)的流行，在許多其他軟件供應(yīng)商，有很強(qiáng)的影響力，確保RabbitMQ 和Kafka正常工作，通過他們的技術(shù)。

安全和操作

安全和操作都是RabbitMQ的強(qiáng)項(xiàng)。 RabbitMQ管理插件提供了HTTP API，一個(gè)基于瀏覽器的 UI 用于管理和監(jiān)控，加上CLI工具給予操作員。 外部工具，如果長(zhǎng)期監(jiān)測(cè)數(shù)據(jù)存儲(chǔ)，比如CollectD, Datadog或者New Relic也是需要的。 RabbitMQ還提供了API和監(jiān)控工具，審核和應(yīng)用故障排除。除了支持TLS，RabbitMQ附帶RBAC支持通過內(nèi)置數(shù)據(jù)存儲(chǔ)， LDAP或外部基于HTTPS的供應(yīng)商，并支持身份驗(yàn)證使用x509證書，代替用戶名/密碼對(duì)。額外的身份驗(yàn)證方法 可以使用插件相當(dāng)直接地?cái)U(kuò)展。

這些領(lǐng)域?qū)pache Kafka.構(gòu)成了挑戰(zhàn)。在安全方面，最近的Kafka 0.9版本附加了TLS,，JAAS基于角色的訪問控制，Kerberos/plain/scram認(rèn)證，使用CLI管理安全策略。 這使得早期版本大幅改善，當(dāng)時(shí)您只能在網(wǎng)絡(luò)級(jí)別鎖定訪問權(quán)限，對(duì)于共享或多用戶，這不起作用。

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

性能

Kafka照以下設(shè)計(jì)：100k/sec性能往往是人們選擇 Apache Kafka的關(guān)鍵驅(qū)動(dòng)力。它的實(shí)現(xiàn)很大依賴開發(fā)者能夠?qū)懗雎斆鞯南M(fèi)者代碼。

當(dāng)然，每秒消息速率是很難狀態(tài)和量化，因?yàn)樗麄円蕾嚭芏?，包括你的環(huán)境和硬件，工作負(fù)載的性質(zhì)，使用哪種交貨保證 (e.g. 持久性是昂貴的，鏡像更是如此), etc.

20K/sec是很容易使用一個(gè)Rabbit隊(duì)列實(shí)現(xiàn)的， 事實(shí)上跟多一些也不是很難，只要沒有太多要求的擔(dān)保。隊(duì)列的支持，通過一個(gè)， 在本地操作系統(tǒng)線程池上進(jìn)行協(xié)作調(diào)度的，輕量級(jí)的Erlang線程 – 因此，它自然成為了單隊(duì)列的關(guān)鍵點(diǎn)或瓶頸，永遠(yuǎn)不會(huì)做比CPU周期內(nèi)能得到的更多的工作。

增加信息秒速率通常歸結(jié)為妥善利用可用的并行性環(huán)境，通過諸如通過聰明的路由打破交通跨多個(gè)隊(duì)列 (從而可以同時(shí)運(yùn)行不同的隊(duì)列)。當(dāng)RabbitMQ實(shí)現(xiàn)一百萬(wàn)每秒的消息傳遞， 它通常會(huì)明智的慢下來(lái) – 但通過使用大量的資源，周圍 30 RabbitMQ節(jié)點(diǎn)。 大多數(shù)RabbitMQ使用者享受由三到七個(gè)RabbitMQ節(jié)點(diǎn)提供的高性能。

Making the Call

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

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