选择 Azure 事件中心
某些应用程序可以从几乎同样多的源产生大量事件。 我们经常听到用于这些情况的术语“大数据”，它们需要唯一的基础结构来进行处理。
假设你为 Contoso Aircraft Engines 工作。 你的雇主制造的引擎有数百个传感器。 每天早上，飞机引擎需连接到测试工具并测试速度后才能起飞。 此外，当飞机连接到地面设备时，会流式传输缓存的飞行中数据。
你希望使用历史传感器数据，以在传感器读数中查找指示引擎可能很快会发生故障的模式。 也希望将实时传感器读数与这些故障模式进行比较。 然后，如果引擎显示的数据令人担忧，便可以近乎实时地警告用户。
什么是 Azure 事件中心？
事件中心是发布订阅通信模式的中介。 但是，与事件网格不同，它针对极高的吞吐量、大量的发布者、安全性以及复原能力进行优化。
事件网格非常适合发布 - 订阅模式，因为它只管理订阅并将通信路由到这些订阅服务器，而事件中心则执行相当多的附加服务。 这些附加服务使其看起来比简单的事件广播者更像服务总线或消息队列。
分区
事件中心接收通信时会将其划分为多个分区。 分区是保存通信的缓冲区。 由于事件缓冲区，事件并非是短暂的，并且不会仅仅因为订阅服务器繁忙或甚至脱机就错过事件。 订阅服务器总是可以使用缓冲区来“追赶”。默认情况下，事件会在缓冲区中保留 24 小时，然后自动过期。 缓冲区之所以称为分区，是因为会在它们之间划分数据。 每个分区都有一组单独的订阅者。
捕获
事件中心可以立即将所有事件发送到 Azure Data Lake 或 Azure Blob 存储，以实现实惠的永久持久性。
身份验证
所有发布服务器都经过了身份验证并已颁发令牌。 这意味着事件中心可以接受来自外部设备和移动应用的事件，而无需担心来自恶作剧者的欺诈性数据会破坏分析。
使用事件中心
事件中心支持将事件流管道传输到其他 Azure 服务。 例如，将其与 Azure 流分析结合使用，可以近乎实时地对数据进行复杂的分析，并能够关联多个事件并查找模式。 在此情况下，流分析会被视为订阅服务器。
对于我们的飞机引擎，我们将设置体系结构，以便事件中心会对来自引擎的通信进行身份验证。 然后我们让它使用捕获功能将所有数据保存到 Data Lake。 之后，我们可以使用所有保存的数据来重新训练并改进机器学习模型。 最后，流分析订阅者选取我们的事件流。 流分析使用我们的机器学习模型来查找传感器数据中可能指示问题的模式。
由于我们具有多个分区，并且每个引擎仅将其所有数据发送到一个分区，因此，我们的流分析订阅服务器的每个实例只需要处理整体数据的一部分。 它不需要筛选并关联所有数据。
应该选择什么服务？
就像选择队列一样，在这两个事件传递服务之间进行选择刚开始似乎比较麻烦。 两者都支持“至少一次”语义。
如果出现以下情况，请选择事件中心：
- 需要支持对大量发布服务器进行身份验证。
- 需要将事件流保存到 Data Lake 或 Blob 存储。
- 需要对事件流进行聚合或分析。
- 需要可靠的消息传递或复原能力。
否则，如果需要包含受信任的发布服务器（例如，自己的 Web 服务器）的简单事件发布订阅基础结构，应选择“事件网格”。
使用事件中心，可以生成大数据管道，不仅每秒能处理数百万个事件，而且延迟很低。 它可以处理来自并发源的数据，并将其路由到各种流处理的基础结构和分析服务。 它支持实时处理和重复重播存储的原始数据。