1-EasyNetQ介紹（黃亮翻譯）

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.這樣有一個好處就是消息對與人類可讀性好。所以你可以使用相似於RabiitMQ 管理端應用去調試消息問題。

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 終結點在一晚上中穩定運行。

原文地址：https://github.com/EasyNetQ/EasyNetQ/wiki/Introduction