2、Introduction介绍

1、Quick Start 快速上手 （详见链接）

2、Introduction 介绍

　　EasyNetQ是一个简单易用，独具风格的RabbitMQ .NET客户端 API，如果你仅仅希望快速上手简单使用，那么你看看Quick Start就好了。

　　EasyNetQ开发的目的是提供一个简洁的.NET的RabbitMQ库，为此EasyNetQ根据可能的RabbitMQ使用场景提供一种独具风格的视角。为了保证灵活性，EasyNetQ强制定义了一些约定。如下：

（1）消息即.NET类型

（2）消息通过.NET类型名进行路由

这意味着消息必须用.NET class来定义。每种不同的消息必须用一个class表示，这个类必须是public并带有一个默认构造函数和public可读写的属性。在这个消息中，通常不去实现任何功能，仅仅把这个消息定义为一个简单的数据容器或者DTO。下面是一个简单的消息。

public class MyMessage
{
    public string Text { get; set; }
}

EasyNetQ通过消息的class type名字来路由。当你发布一个消息，EasyNetQ会检查消息类型， 给它指定一个基于类型名称、命名空间和程序集的路由键。在消费者端，消费者去订阅这个类型。在订阅这个类型之后，消费者就会得到这个类型的消息。

默认情况下，EasyNetQ使用JSON序列化.NET类型（消息），这样消息会具有良好的可读性。因此你能够使用类似于RabiitMQ 管理端应用去获取消息来诊断和调试。

 

一、EasyNetQ API的设计

EasyNetQ是一个建立在RabbitMQ.Client库之上提供服务的组件集合。做了序列化、错误处理、线程管理、连接管理等事情，使用了一个微型的IoC容器。当然你也能很容易地用自己的实现替换这些组件。假如你喜欢用XML序列化而不是JSON，仅仅需要自己写一个ISerializer的实现，然后注册到这个容器中。

这些组件功能由IAdvancedBus API提供出来。该API里的方法看起来很像AMQP标准里定义的那样，这个API中对你隐瞒的唯一AMQP概念是信道channels。这是因为channels是一个复杂的底层概念，不应该放到AMQP标准的入门章节。 坦白地讲，这个‘Advanced’不是一个非常好的名字。用‘lAMQP’可能更好些。

 

在IAdvancedBus API之上的一层，是一系列消息模式：Publish/Subscribe, Request/Response 和 Send/Receive 的实现。这是EasyNetQ坚持的设计思想，这些模式是我们坚持要去实现的。这样有非常小的弹性，要么你接受我的方式，要么不要用EasyNetQ。这样做的目的是，不用你花费精力去重新发明轮子。你不必每次去做选择用哪种模式，你只需要简单的去Publish和Subscribe消息。这样设计是为了实现EasyNetQ的核心目标——尽可能简单的使用RabbitMQ。

这些模式的功能由 IBus API提供。这又是一个囧透的名字，它跟消息总线概念没有半毛钱关系。IPackagedMessagePatterns估计会是一个更好名字（消息模式的封装）。

80%的人在80%的情况下都会选择使用IBus，但它不是面面俱到的API，如果你需要的功能这个IBus没有提供，那么你应该使用IAdvancedBus。这样使用没有丝毫问题，EasyNetQ就是这样设计的。简单功能（IBus）应付简单需求，高级功能提供给复杂需求使用。

 

二、为啥需要EasyNetQ

RabbitMQ不是已经有了 .NET client？
确实如此。你可以在这里下载RabbitMQ .NET 客户端类库。

那么为什么我还需要EasyNetQ呢？RabbitMQ .NET client 实现了AMQP协议的客户端（RabbitMQ实现了服务器端）。 AMQP是为HTTP协议设计的。它的设计是跨平台的和与语言无关的。它也旨在灵活支持多种基于 “交换器/绑定/队列” 模型的消息传递模式。

RabiitMQ Client 非常地灵活,但是伴随着灵活性而来是复杂性，这意味着你需要写大量代码。通常，这些代码包括一下这些：

• 实现消息传递模式，例如Publish/Subscribe或Request/Response。尽管，公平来讲这个 .NET client 也提供了一些这样的支持。

• 实现路由策略。你需要设计如何绑定exchange与queue。并且你还可能需要设计生产者和消费者之间的消息路由。

• 实现消息的序列化/反序列化。RabbitMQ及其.NET client只关心和传递二进制消息，所以你需要自己序列化/反序列化消息对象。

• 为订阅去实现一个消费者线程。你需要一个专门的消费者——循环等待订阅的消息，那么如何处理多个订阅者，或者瞬间订阅者呢？比如一端发出请求，等待另一端的响应。

• 实现消费者重新连接。假如连接崩溃了或者RabbitMQ 服务挂了，你怎样检测并确保你所有的订阅都能被重建？

• 懂得和实施服务质量设置。你需要什么样的设置来确保客户端可靠性。

• 实现一个错误处理策略。假如接受到一个错误的消息，或者发生一个未处理异常被抛出，你的客户端应该做什么呢？

• 实现publisher confirms可靠消息传递。

EasyNetQ的目标是将所有这些问题封装到一个简单的库中，该库位于现有的AMQP客户端上层。这是多年来在高容量商业环境中使用RabbitMQ的经验的结晶。

 

三、性能评估

EasyNetQ的性能直接跟RabbitMQ broker代理服务器的性能相关，因网络和服务器性能不同而不同。在一个开发者机器上用本地RabbitMQ实例上测试，持续通宵执行实现了每秒50002K消息送到。每个EasyNetQ 终结点的内存使用，在一夜中能够稳定运行。

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