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

 

posted on 2017-12-04 11:09  困兽斗  阅读(206)  评论(0编辑  收藏  举报

导航