Microsoft 发布用于统一事件处理的 Azure 事件网格

今天，Microsoft 发布了一项新服务，用于获取和处理云端事件。 Azure 事件网格（Event Grid）能够获取到从 Azure 服务中或者自定义应用程序中生成的事件，并且路由至所选择的处理程序。这项服务为开发者和运营商提供了一个单一事件流，可用于无服务器应用程序、应用程序集成或操作自动化。

Microsoft 的 Corey Sanders将此服务描述为“将事件定义为Azure 头等对象”的“全托管事件路由服务”。Azure 将事件路由到各种事件处理程序中。这些处理程序涵盖了从Azure Functions 到webhook【译注1】，它们支持事件过滤和保障可靠传递。Microsoft 声称，Azure 事件网格能够每秒支持数百万个事件。每月前10 万次操作都是免费的，之后用户需要为每百万次操作支付0.6 美元。

虽然包括Microsoft 在内的主要云服务提供商都为应用程序到应用程序之间的路由提供了一系列消息传递服务，但Azure 事件网格这一服务有些特别。Microsoft 提供了一个托管的或者自定义主题的单一事件结构。他们致力于为所有主流云服务提供内置的发布者支持。他们开箱即用的处理程序还能够让用户选择在Azure 平台触发行为，或者是通过webhook 在Azure 平台外部触发行为。例如，像Google Cloud Storage 这样的服务会将事件发送至 Google Cloud Pub/Sub，但是这仅仅适用于一部分服务，消息传递的主题是自我托管的。在 AWS 云服务中，SQS 从为数不多的服务中获取事件，然后 CloudWatch将事件分发至不同类型的处理程序。

为了获悉更多有关Azure 事件网格的信息，InfoQ 联系到了该项新服务的产品负责人 Dan Rosanova ，他也是该项目的首席项目经理。

InfoQ：Azure 事件网格源自哪里？它和 Service Fabric 一样吗，它也是从内部产品演化成为了公开发行的产品？还是一开始设计它的初衷就是面向客户的？

Rosanova： Azure 事件网格一开始就是以客户为中心而设计的，但是与此同时它也是为了满足我们的内部需求，用于 Azure 平台以及跨 Microsoft 产品的需求。这也就是说，这是我们专门为 Azure 以及我们的客户们所设计的常见应用场景。规模、可靠性、互操作性以及成本都被我们视作是至关重要的。

InfoQ：目前有哪些 Azure 服务能将事件发布到事件网格？它支持哪些地区？今后有什么计划呢？

Rosanova：目前 Azure 事件网格在美国西部以及美国中西部都可用。Azure 资源管理器、事件中心捕获（Event Hubs Capture）服务和存储二进制大对象服务都可以成为事件发布服务的提供者。我们将继续把这项服务部署到 Azure 的所有地区，并且随着时间的推移将其部署至所有的 Azure 服务上。

InfoQ：开发人员可以从他们自己的应用程序向 Azure 事件网格发布事件吗？如果这些应用程序是 Azure 平台之外的呢？他们该怎么做呢？

Rosanova：在 Azure 事件网格中，所有的事件都是从主题（topics）发出的。有一些主题是 Azure 特定的主题，例如你的存储账户。当你使用该存储账户时，它就会触发事件。你还可以生成自己的自定义主题，你可以将自己定义的事件发布到该主题，你自己或其他对其感兴趣的人可以订阅该主题用以接收感兴趣的事件。你可以通过使用 Header 中带有密钥或令牌的 HTTPS POST 来进行发布，密钥或令牌用以认证授权。我最喜欢的方式是通过 curl 使用 bash 变量将事件发送至事件网格：curl -X POST -H “aeg-sas-key: $key” -d “$body” $topicEndpoint。

InfoQ：开发人员是如何与 Azure 事件网格进行交互的呢？用户体验（UX）如何？

Rosanova：Azure 事件网格是 Azure 中的拓展资源（Extension Resource），也就是说，它需要锚定于其它资源（如存储）。当你想要在存储账户上创建事件订阅时，实际上，你会转至该存储账户的 UX。因此，事件确实是对于你在 Azure 中已使用资源的自然拓展。你还可以通过自己的 UX 来和 Azure 事件网格进行交互，但是我们更倾向于使用事件发布者的 UX。对于自定义主题，其锚点是你的自定义主题本身，因此你只需导航至你的主题并订阅那里的事件即可。这种体验真的是和我们内部所使用的模型和技术是完全相同的，我们把它直接提供给了我们的客户。

InfoQ：“事件”是什么样的呢？header/payload 有哪些部分是必须的呢，哪些是可选的呢？

Rosanova：

复制代码

 
aeg-sas-key: <key azure="" custom="" event="" from="" grid="" my="" topic="">
 
[
 
{
 
​ "id": "'"$RANDOM"'",
 
​ "eventType": "recordInserted",
 
​ "subject": "myapp/vehicles/motorcycles",
 
​ "eventTime": "'`date --iso-8601=seconds`'",
 
​ "data":{
 
​ "make": "Ducati",
 
​ "model": "Monster"
 
​ }
 
}
</key>

在上述的例子中， header 中的 aeg-sas-key 是必不可少的，它也被称为 header 中的 SAS 令牌 aeg-sas-token。在 body 中，id、eventType、subject、eventTime（ISO 8601）以及有效 JSON 格式的 data 对象都是不可或缺的。你不需要预注册 eventTime 或 subject，但是你可以通过它们来为事件订阅者启用事件过滤，因此你在事件建模中应该考虑使用它们。

InfoQ：这是为了可靠消息传递这一场景所设计的吗？

Rosanova：事件网格提供至少一次送达（ at least once delivery）。如果你的端点没有以 200/202 的状态码回复我们的请求，我们会以指数退避算法（exponential back off）来进行重试。最后这个重试间隔会变为 1 小时，在 24 小时之后我们会删除未送达的事件。至少一次的意思是，你可能会不止一次收到这些事件，尤其是当你没有确认已经收到这些事件时。

InfoQ：有效的事件消费者是什么？自定义应用程序？webhook？Azure 服务？

Rosanova：上述提到的那些全部都是。我们不对事件发生的地点加以区分，我们也不会将其限制在特定区域或者云端。事件消费者可以是其它 Azure 服务，例如 Azure Logic Apps 和 Azure Functions，它们都具有直接集成至 Azure 事件网格的 UX，但是事件消费者也可以是运行在 Azure 上或者其它任何地方的 HTTP 端点。

InfoQ：Microsoft 提供为数不多的与消息传递相关的服务，包括 Azure Service Bus、Azure Event Hubs、Logic Apps 等等。Azure 事件网格的明确使用用例是什么呢？

Rosanova：Azure 事件网格填补了当前云平台中消息传递服务的空白，填补的不仅仅是 Azure 的空白，而是涵盖了所有云服务提供商。我们提供消息传递、消息队列以及消息遥测（telemetry）服务，但是这仍然无法进行全方位的事件处理，尤其是对于跨服务或者跨云平台的场景。如果你着眼于一个典型的电子商务应用程序，你可能会去使用像 Service Bus 这样的服务来进行销售交易、其它物料交易或金融交易，你也可能会使用像事件网格这样的服务，让所有的模块都报告它们的状态，就像是“拉动式库存（inventory pulled）”，你还可能会去使用像 Event Hub 这样的服务来跟踪所有不同组件的遥测信息。我们认为，对于 Azure 事件网格来说，最具意义的三个方面是：无服务器、操作和集成。每个方面都有自己存在的原因并且都专注于服务略有差异的不同人群。

译注 1：webhook 是用户通过自定义回调函数的方式来改变 Web 应用的一种行为，通过 webhook 开发者能够自定义一些行为通知到指定的 URL。

查看英文原文： Microsoft Ships Azure Event Grid for Unified Event Processing

感谢薛命灯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。