Azure 消息 & 事件服务的选择 – 下篇

小提示：您能找到这篇{Azure 消息 & 事件服务的选择 – 下篇}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的Azure 消息 & 事件服务的选择 – 下篇内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

< ">在上篇和中篇我们分别对了消息/事件服务中五种类型服务做了介绍和对比，它们包括Storage queue、Service bus queue、Service bus topic、Event Hub和IOT。这篇文章我们继续对剩下的三种服务做介绍，其中Service bus Relay和Notification Hub相比较之前的五种消息服务，有比较大的区别，应用场景和功能也有比价突出的特点，而Event Gird则又是Azure平台最新推出的一种Serverless服务，接下来我们就这三种服务分别做介绍。

< ">1.Service bus Relay

< ">a.什么是Service bus Relay

< ">在解释这个问题前，我们可以先想一个问题，假设用户需要去连接一个运行在防火墙后面的应用有哪些解决方案：

< ">开启防火墙的一个端口

< ">设置VPN从而连接到应用所在的网络

< ">对于解决方案一，通常我们到拿到本地IT服务的许可才可以。对于方案二，不仅有方案一的问题，还需要考虑基础设施服务的费用问题，而Azure Service bus Relay提供给用户更好的第三种选择。

< ">Azure Service bus Relay是一项用来帮助用随州网站开发户构建混合集成解决方案的技术，用户可以通过使用Relay将组织外部的客户端与组织内部的资源进行连接，从而实现内外应用程序的相互访问和数据交互。

< ">b.服务特征

< ">Relay是如何工作的：

< ">Relay可以理解为托管在云中的"router"。用户的本地服务可以实现“联机”并打开Service bus Relay上的"endpoint"，这样客户端服务就能访问该"endpoint"并发送Web调用，Relay将该Web调用"router"到用户的本地服务中，从而实现客户端与本地服务的交互。

< ">下图显示了运行在组织外的客户端如何通过Service bus Relay与组织内的应用程序进行交互：

< ">Azure Relay提供两种用于连接应用程序和客户端的方式：

< ">Hybrid Connection:它是基于标准的Http/WebSocket协议实现的。Hybrid Connection可以在任何具有基本WebSocket功能的平台上使用任何语言来实现。

< ">WCF Relay:它是基于Windows Communication Foundation(WCF)的传统的中继产品，适用于完整的.NET Framework和WCF架构。用户通过使用一系列的WCF绑定实现本地和中继服务间的连接。

< ">下表是Hybrid Connection和WCF Relay间的区别：

< ">c.Service bus queueService bus topic和Service bus Relay的区别：

< ">下面的图表是对三种服务区别的总结：

< ">下图展示了三种服务是如何进行消息传递：

< ">d.适用场景

< ">基于Service bus Relay的特性，它主要适用于以下场景：

< ">云端和本地服务之间的通信

< ">本地的应用程序运行在组织内网，有防火墙隔离的环境中，需要与其他的应用程序（运行在本地或者云端）进行数据交互。

< ">2.Notification Hub

< ">a.什么是Notification Hub

< ">使用移动应用程序的用户有需求被定期推送他们感兴趣的内容，而不是定期自己去检查。因此移动应用开发者在开发程序时需要考虑增加通知推送功能。然而在实际的开发过程中，开发者需要考虑推送到多个平台、定制化的推送消息、处理不同版本的应用程序以及扩展性等等问题。

< ">Azure Notification Hub就是帮助开发者简化这一过程，通过使用Azure Notification Hub开发者可以专注于移动应用端的开发，而不需要开发者处理复杂的后端推送。

< ">b.服务特征

< ">Notification Hub为用户提供了一个可扩展的推送通知的基础架构，可以帮助用户有效的跨平台将消息推送到数百万的终端用户。

< ">Notification Hub解决的最主要的一个问题是“如何将推送通知通过各种各样的特定平台的服务传递给相应的设备”（例如，Windows Store应用程序只能通过Windows Notification Service(WNS)被推送得到通知，而IOS设备只能通过Apple Push Notification service(APNs)被推送通知，同样的，Android设备只能通过Google Cloud Messaging(GCM)被推送通知）。另外Notification Hub还提供给用户以下功能：

< ">i.设备管理：Notification Hub减轻了后端要存储管理Channel URL以及device token(用于各大推送服务推送消息)的压力。Notification Hub会安全可靠的帮用户存储处理PNS feedback、device token等信息。

< ">ii.基于tag的多播和pub/sub分发模式：一台设备在Notification Hub中注册时可以指定一个或多个tag，用来表示该用户对某类的通知感兴趣。这个功能提供给用户一个非常简单的方式，可以通过调用单个API向百万级别的目标设备端发送推送通知，而不需要用户自己考虑如何实现向每台设备发送通知的问题。

< ">iii.Notification Hub提供给用户基于template发送推送通知的功能，这样用户可以自定义通知的格式、内容等信息，同时也与后端代码保持独立。

< ">iv.高度的可扩展性：Notification Hub支持用户注册百万级别的设备，用户只需要触发一条推送消息到Notification Hub，它会自动将推送消息通过推送服务以低延迟的性能发送到百万级别的设备端。

< ">下图显示了通过Notification Hub推送通知的过程：

< ">c.适用场景

< ">Azure Notification Hub是一种不同类型的消息传递服务。它不像上面我们介绍到的消息服务，用于应用程序之间或使用微服务架构来发送消息，Azure通知中心可以从任何服务（在Azure，本地或其他地方）向在移动设备（Windows，iOS或Android）上运行的移动端应用程序发送推送通知。

< ">基于Notification Hub的特性，它的使用场景非常明确，它非常适用于移动应用程序跨手机、平板和PG的消息推送场景。

< ">3.Event Grid(目前暂时在中国没有上线)

< ">a.什么是Event Grid

< ">Event Grid于2018年1月正式上线，是一项比较新的事件传递服务，在它使得基于事件的应用架构（如微服务和Event-Driven系统）的构建更容易。

< ">Event Grid提供给用户一种实时、可靠、可扩展且基于事件的应用架构，可用于管理事件路由且可以处理每秒百万级别的数据吞吐量。

< ">b.服务特征

< ">使用Event Grid时用户需要指定Source和Event Handdlers/WebHook，Source用于推送事件而Handler用于接收事件，Event Grid支持Azure平台中服务如Storage blob或Event Hub作为Source（数据来源），同时也支持第三方的资源或者用户使用自定义topic作为Source。用户可以通过Source将时间发送到某个topic中，而每个topic则可以有多个subscriber/handler。用户可以在Event Grid上使用filters将特定的event数据安全的路由到一个或者多个endpoint中。

< ">除了以上基本功能之外，Event Grid还提供给用户以下功能：

< ">i.Event Domains，它允许用户通过Azure Active Directory对多达数千个topic进行授权和身份管理，此外，Domain还支持partition的处理，换句话说，用户不需要单独向每个topic发布事件，而是将事件发布给domain，它可以确保将事件发送到正确的topic。

< ">ii.高级Filter，Event Grid也提供给用户更强大与Service bus topic的Filter功能，这体现在用户创建多个类型的Filter，例如数字、字符串、布尔值。这使得用户对事件的路由控有更好的控制和发挥空间。

< ">iii.管理：用户可以为Event Grid启用重试策略和死信队列功能，也可以检测匹配和不匹配事件以及每个subscriber上出现的错误和延迟。

< ">下图显示了Event Grid如何连接Source和Handlers:

< ">c.与Service bus topic的区别

< ">虽然Azure Event Grid也是采用pub-sub的模式分发消息并且也有topic的概念，但是这两个服务是不同的，有如下区别：

< ">i.消息接收模式：Event Grid是push的模式，而Service bus topic是pull的模式。也就是说当用户使用Service bus topic接收消息时需要管理并控制何时或者接收多少的消息，而使用Event Gird只要handlers保持与Event Gird的连接，事件就会被实时推送到对应的handlers中。也正是因为这点差异，用户使用Service bus topic更具有灵活性和可控性，如果当接收端接收的速度跟不上发送端的速度时，可以先将消息积存在topic服务中，而使用Event Grid用户需要保证Handler有足够的能力处理来事件的负载。

< ">ii.吞吐量：Event Grid可以保证每秒钟千万级别的的事件量，而这一点是Service bus topic远远达不到的。

< ">更多关于Serv浅析电竞界危机公关ice bus topicEvent Grid的区别，可以参考：官方链接。

< ">d.适用场景

< ">i.Serverless架构

< ">作为正真意义上的ServerLess服务，Event Grid可以很好的应用到各种ServerLess架构中，通过使用ServerLess类型的Handler服务（如logic app/function），用户可以充分利用ServerLess架构的强大功能对事件处理进行高度的扩展。

< ">ii.Enterprise integration

< ">Event Grid提供可靠的事件消息传递，包括重试和死信队列，因此可以保证用户事件不丢失，这非常好的满足企业集成方案的需求。

< ">iii.Cloud Events

< ">作为支持CloudEvents标准的首批服务之一，CloudEvents提供了一种允许跨平台处理事件的标准。随着Azure，AWS，Google，IBM等各大厂商支持此标准，通过这种方式我们可以使用任何平台或应用程序来处理事件，实现格式统一，从而轻松实现应用集成和相互操作。

< ">虽然这篇文章尽可能详细的介绍这几种不同的消息&事件服务的区别和选择，然而在实际的应用场景中，我们经常会将这几种服务结合在一起使用并且在不同的应用环境下，根据用户的考虑因素，产品的选择也会有不同。如果您通过以上的解释还是无法抉择选择哪种服务，欢迎您联系Microsoft技术支持团队，我们会就您的特定的需求和环境帮助您做进一步的分析和抉择。