EasyNetQ 是一個容易使用，專門針對RabbitMQ的 .NET API。
假如你盡可能快的想去安裝和運行RabbitMQ，請去看入門指南。EasyNetQ是為了提供一個盡可能簡潔的適用與RabbitMQ的.NET類庫。為了實現這些目標，EasyNetQ提供一種自認為你會在.NET下使用RabbitMQ的視圖。為了保持使用靈活性，簡單起見，EasyNetQ強制使用了一些簡單的約定。包括如下:
- 消息用 .NET 類型表示
- 消息通過.NET類型路由
這意味着消息必須用 .NET class定義。每一個你想發送的不同的消息類型必須用一個class表示。這個類必須是public並帶有一個默認構造函數和可以讀寫的屬性。在這個消息中，你通常不需要實現任何功能。僅僅把這個消息單做一個簡單的數據容器或者DTO。下面是一個簡單的消息。
public class MyMessage { public string Text { get; set; } }
EasyNetQ通過消息的類型來路由。當你發布一個消息，EasyNetQ會檢查消息類型， 然后給它一個基於類型名稱、命名空間和程序集的路由鍵。在消費者端，消費者去訂閱這個類型。在訂閱這個類型之后，消費者就會得到這個類型的消息。
默認情況下，EasyNetQ使用Newtonsoft.Json 序列化.NET類型為JSON.這樣有一個好處就是消息對與人類可讀性好。因此你能夠使用類似於RabbitMQ 管理端應用去調試消息問題。
API 設計
EasyNetQ是一個在RabbitMQ.Client類庫之上提供服務的組件集合。做了這些事情，像序列化、錯誤處理、線程管理、連接管理等。通過一個Mini-Ioc容器組織在一起。你能很容易用你自己實現去替換這些組件。所以如果你喜歡用XML 序列化而不是用JSON，僅僅需要以一個ISerializer的實現，然后注冊到這個容器中。
這些組件最上層是IAdvancedBus API。這看起來很像AMQP規格。實際也是你能夠通過這個API運行很多AMQP方法。這個API對你隱藏了唯一AMQP概念是channels。這是因為channels 是一個復雜的底層概念，不應該被放到AMQP部分規格的第一的位置。 坦白來說，這個API中 ‘Advanced’不是一個非常好的名字。用‘lamqp’可能更好些。
這個頂層高級API是一系列消息模式：Publish/Subscribe, Request/Response,和 Send/Receive. 這是EasyNetQ堅持的設計思想。這些模式是我們應該實現的。這樣有非常小的彈性。要么你接受我的處理方法，或者你就不要去使用。這樣做的目的是，不用你和使用者花費精力去重新發明輪子。你不需要每一次去做選擇，你只需要簡單的去Publish和Subscribe消息。這樣設計是未來實現EasyNetQ的核心目標，即盡可能簡單的使用RabbitMQ。
這些模式的后面是這個 IBus API. 再一次看到這個一個簡單的名字，它跟消息總線概念有關。IPackagedMessagePatterns可能是一個更好名字。
80%的用戶的工作，在80%的時間都會使用IBus。它不是完備的API，如果這個模式下，你想實現的功能這個IBus沒有提供，那么你應該使用IAdvancedBus。這樣使用沒有問題，EasyNetQ就這這樣設計使用的。
為什么我需要EasyNetQ？
RabbitMQ不是已經有了 .NET client？
確實如此。你可以在這里下載 .NET AMQP 客戶端類庫。
那么為什么我需要EasyNetQ呢？RabbitMQ .NET client 實現了AMQP協議的客戶端（RabbitMQ實現了服務器端）。 AMQP是為HTTP協議設計的。它的設計是跨平台的和與語言無關的。它也旨在靈活支持多種基於交換/綁定/隊列模型的消息傳遞模式。
RabiitMQ Client 非常地靈活,但是伴隨着靈活性而來是復雜性。這意味着你為了需要寫大量代碼，以便執行RabbitMQ client。通常，這些代碼包括一下這些：
- 實現消息傳遞模式，例如
Publish/Subscribe或Request/Response。盡管，公平來講，這個.NET client也提供了一些這樣的支持。 - 實現路由策略。你將需要設計你如何去
exchange-queue綁定。並且你將設計怎樣在生產者和消費者之間進行消息路由。 - 實現消息的序列化/反序列化。 你將如何轉換
AMQP的二進制消息為你編程語言能理解的格式？ - 為訂閱去實現一個消費者線程。你將需要有一個專門的消費者循環等待你訂閱的消息。你會如何處理多個訂閱者，或者瞬間訂閱者，像哪些等待答復的請求。
- 實現消費者重新連接。假如連接崩潰了或者
RabbitMQ服務掛了，你怎樣能檢測到並確保你所有的訂閱都能被重建？ - 懂得和實施服務質量設置。你需要什么樣的設置來確保一個可靠的客戶端。
- 實現一個錯誤處理策略。假如接受到一個錯誤的消息，或者發生一個未處理異常被拋出，你的客戶端應該做什么呢？
- 實現發布者可靠的消息確認。
EasyNetQ目標是在AMQP之上封裝所有這些關注點在一個簡單好用的類庫中。EasyNetQ有在高容量商業環境中數年使用RabbitMQ的經驗。
性能評估
EasyNetQ的性能直接跟RabbitMQ broker的性能相關。這可能隨着網絡和服務器性能不同而不同。在一個開發者機器上用本地RabbitMQ實例上測試，持續通宵執行實現了每秒50002K消息送到。每個EasyNetQ 終結點在一夜中穩定運行。