Azure ServiceBus 学习记录

最近对Azure ServiceBus的功能感兴趣，准备花一些时间学习一下，主要的学习资料来源于Azure document和网上的一些资料。

Azure ServiceBus是干什么？

ServiceBus顾名思义，翻译成服务总线， 是应用程序之间构建的消息传递基础设施，用于在应用程序之间以松散耦合的方式相互交换消息，以改善可扩展性和弹性。目前看到比较多的应用场景:

• 企业的应用本身都在Azure上，servicebus为应用之间提供了高可用的消息传递机制。
• 企业有一个或多个部署在本地的商业应用程序（如 SAP 和 Oracle EBS）, 无法直接和外部程序直接连接， 因此它可以通过servicebus传递消息，这样其他的应用就可以从中获得消息。总之， 按照官方说法是，servicebus can connect anywhere!

Azure ServiceBus都有哪些组件？

根据应用场景的不同，Azure ServiceBus提供了4种不同的组件：

• Queues, 从名称就可以看出，它就是我们常说的队列，提供单向的消息传递机制，Queues充当着消息的中间存储者，直到消息被读取，每一条消息只能被一个client读取。至于一个queue能存储多少条消息，能存多久，以后的博文会详细记录，这只是一个总体概况。
• Topics, 这个和Queue非常的类似，仍然是单向的消息传递机制，也是消息的中间存储者，不同的是它具备观察者模式，即每一条消息都是发给一个topic，而在这个topic上可以注册多个 subscription, subscription可以定义一个filter来过滤出自己想要被通知的消息， 因此一个消息可以被多个client读取，只要消息本身符合filter的条件。
• Relays, 也就是中继器，它是双向通信机制，不存储任何消息，收到消息后直接转发到目的应用中。
• Event Hubs, 事件中心，它的特点是支持海量数据，并且延迟低，高可用，适用于应用的日志事件的中转。

Queues

由上图可以看出，每一条queue message都包含body和key-value形式的属性值. 当一个client要读取queue中的消息时，有两种方式：
- ReceiveAndDelete，读取后立即删除，即使它在处理这条消息时由于某种原因失败了，消息也无法恢复了，也就是说其他的client再也无法读取这条消息，使用于对丢失消息不敏感的业务场景。
- PeekLock，读取queue中的消息，并给这条消息加上锁，使其对其他的client不可见，直到以下3种条件触发：
- Client 调用Complete方法，消息从队列中删除。
- Client无法处理消息，调用Abandon方法，消息锁解除，其他client可以读取它了。
- 在指定时间(默认60秒)内，如果没有接受到上面两种方法的调用，就以Abandon的形式处理。

总之，如果你的需求是想要异步处理消息，但是消息的发送者和处理者的能力不太统一，或者它们运行的时间就不一样，queue是一个不错的选择。而且由于可以有多个client同时处理queue的消息，queue也有一种load balance的感觉。

Topic

topic与queue非常类似，甚至消息的结构也是一样的，但是topic支持client创建自己的subscription，并且定义自己的filter。 举个例子：

• 订阅者甲只接收属性值中 age = “18”, 也就是说只有消息中有age属性，并且值是18的消息才会被发送给甲。
• 订阅者乙定义多个filter的组合，例如age > 18 and/or Amount>10000
• 如果想接收所有的消息， filter设置为true就可以。

Relay

设想一个场景，应用A和应用B都是在2个企业的内部网中，它们都各自在自家的防火墙里，或者由于NAT的原因，没有固定的IP地址，如何做到让它们直接相连呢？ Relay就是为了解决这个问题的，应用所需要做的就是与Relay建立TCP连接并保持打开， Relay负责将2者连接起来。由于连接是从内网发起的，防火墙并不需要打开一个新的端口，同时也解决了NAT问题。

Event Hubs

Event hubs 的特点是能够每秒处理数百万的事件， 使你的能够游刃于海量的数据中。典型的应用场景是日志信息的处理，由于线上系统产生的日志量大而且快，Event hub能够快速接受并存储， 后端你的日志分析系统便可以处理其中的事件信息，更详尽的信息在后面对EventHub的单独研究中再写。

总结

现在只是对Azure ServiceBus有了大概的了解，后面需要对每个组件进行单独研究实验并且记录下来。