Azure 有三款消息队列相关的服务：

• Event Grid：push-push 模型，事件路由、处理服务
• Service Bus：push-pull 模型，queue 存储
• Event Hubs：push-pull 模型，log 存储

本文对 Event Hubs（2014 年推出）产品及近半年 GA 的特性做一些解读。

概念模型

对齐 Kafka 可以快速理清 Event Hubs 概念：

其弹性机制包括两部分：

1. 弹性单元（预付费）

1. Standard tier 的 throughput units (TUs)， Premium tier 的 processing units (PUs) ，Dedicated tier 的 capacity units (CUs) 。例如，1 TU 提供 1 MB/s 或 1000 events/s 的写能力，2 MB/s 或 4096 events/s 的读能力。
2. Auto-inflate：根据流量变化自动往上弹 TU，但不会缩减 TU 数。这是 namespace 级别配置，只在 Standard tier 上用到。

2. Event Hub 存储的 partition。Azure 建议按照业务尖峰规划 partition 数目：

1. partition 数在 Basic、Standard tier 上后期不支持修改。
2. partition 数跟费用没有关联，只服务于业务应用需要。

Tiers

全部规格列表

Event Hubs 提供四种计费规格，绑定差异化的功能集合：

除功能外，四种规格在吞吐能力、资源数量配额上也有差别。

由上可见，Basic/Standard tier 适合测试、轻度使用场景，本文不多赘述。

Premium tier

这是 2021 年 11 月 GA 的新规格：

• 通过资源（CPU/Memory Pod）隔离，满足可预期的访问延时需求。
• 相对于 Standard tier，Premium 支持动态 partition 扩容、更长存储周期（90 天）等功能。
• 三副本，多 AZ 数据存储。
• 新的 two-tier log storage 技术带来 pub/sub 吞吐能力大幅提升。
• 以新的 PU 作为弹性单元，每 PU 提支持 5~10 MB/s 写，10~20 MB/s 读。（实际性能取决于 producer/consumer 数目，包大小，partition 数目，重复消费次数等）。

根据 Azure Messaging 设计者 twitter 上发布的消息：Azure 花了两年时间重新设计 Event Hubs 后端架构来实现 Premium tier（第三代存储）支持。所谓的 two-tier log storage 是在最终存储（Azure Storage）之前加了一个 local store 服务层（使用 NVMe SSD 存储热数据），可以实现在 1ms 完成 AZ 之间的数据复制落盘，加上协议开销、borker 处理延时，端到端的从写入到可消费延迟低于 20 ms（个人猜测是消费热数据情况）。该新架构基于微软开源的微服务框架 Azure Service Fabric 部署。

Dedicated tier

通过独立部署提供了最大吞吐、存储能力以及 99.99% 的最高（四种 tier 中）SLA。

Dedicated tier 提供完整功能集，单租户环境。用户按照预分配的 CUs（包括 CPU/Memory 资源）每月付费。

新推出的 Premium tier 对比 Dedicated tier：

• Premium 提供在多租户上的弹性能力（PU 数可以动态调整），而目前 Dedicated 的扩、缩容还需要工单支持。
• 如要得到多 AZ 存储支持：Dedicated 需要至少 8 个 CU，而 Premium 的第一个 PU 就可以。
• Dedicated 的能力上限更高，Premium 建议在写吞吐低于 120 MB/s（低于 AWS MSK Serverless 的 200 MB/s 限制）时选择。

Capture

Event Hubs Capture 是一种数据投递功能，类似 AWS Kinesis Firehose，提供托管服务：捕捉 Event Hubs 的数据保存到指定存储（Azure Blob Storage 或 Data Lake Storage）。限于 Hubs 本身最大 TTL 是 90 天，Capture 集成的目标是为了补充数据的长期存储能力。

Capture 写出行为：

• 每个 partition 独立输出文件，按 time-based、size-based 两种方式触发写动作。
• 文件格式只支持 Apache Avro（主要是 Hadoop 生态），schema 如下：

Capture 功能不会占用读流量 Quota，实现上可能是基于内部存储 API 访问。

Capture 的处理能力受弹性单元限制，即 namespace 下 TU（Standard tier）、PU（Premium tier）数。

Capture 功能在 Premium/Dedicated tier 上不需要额外付费。

生态

Kafka 兼容

Event Hubs for Apache Kafka 生态提供全托管 Kafka 体验（兼容 Kafka 1.0+ clients)，无需运维 ZK。

作为云服务为了支持 RPC 访问，Event Hubs 使用一个固定的 vip 地址作为 endpoint，client 就不需要知道集群内的 broker 地址，所有的读写流量都经由该 vip。

Event Hubs 的 Kafka 兼容有以下限制：

• 不支持 Kafka 事务特性，messaging 场景建议使用 Service Bus。
• 不支持 log compaction。
• 不支持 Kafka Streams，Azure 称这部分需求主要来自 ksqlDB 场景，建议用自家或开源的流计算引擎。
• Kafka Connect 也基本不支持，做过一个 PoC 场景，但不建议生产上使用。

Event Hubs 访问协议支持：Rest、Kafka(1.0+)、AMQP 1.0，其完整上下游生态包括：

• Kafka API 给 Event Hubs 带来更多 clients 支持。
• AMQP 生态。
• Azure 内部生态，例如：用 Azure Functions 做数据无状态处理，用 Azure Stream Analytics 实现有状态计算。

Schema Registry

这也是 2021 年 11 月 GA 的一项新功能，为事件驱动、中心化消息处理应用提供 schema 中央仓库。使得 producer、consumer 之间交换数据不需要关心 schema 管理、共享工作。

概念上有两层：

• schema groups：提供简单的治理框架（schema 关系的重用和管理），包含多 schema。
• schema：支持多版本，定义生产者、消费者的协议，一个样例如下：

{

 "namespace": "com.azure.schemaregistry.samples",

 "type": "record",

 "name": "Order",

 "fields": [

   {

     "name": "id",

     "type": "string"

   },

   {

     "name": "amount",

     "type": "double"

   }

 ]

}

官网文档图很清楚地解释了其工作流程：

安全设计

访问控制

Event Hubs 支持两种权限模型：

1. SAS（shared access signatures）

一条规则包括：名称、权限、token。

SAS 提供基础的访问控制，用户需要自己管理SAS token 生命周期。

2. Azure Active Directory

微软推荐方案。基于角色的访问控制，支持细粒度的权限设置。

一个安全规则包括：user、group、应用规则。

AD 会返回 OAuth 2.0 token 给客户端，在客户端代码中将不再需要硬编码 token。

网络安全

service tag：标识一组 ip 地址（用于访问 Azure 服务）的前缀，Azure 会自动维护 service tag 的 ip 地址前缀更新。service tag 可以被用在网络安全组规则或 Azure IP Firewall，使用它可以最小化地址维护成本。

IP Firewall：默认情况下可以从公网访问 Event Hubs，通过 IP Firewall 可以设置指定 CIDR 区间的 IPv4 地址访问规则（Event Hubs 的 namespace 级别配置）。

VNet(Virtual Network) Service Endpoints：将 Event Hubs 的 namespace 绑定到 service endpoint，可以提供通过虚拟网络（例如 VM 访问源）的访问路径。Standard/Dedicated tier 提供该支持。

Private Link：Azure Private Link Sevice 提供给一个私有 endpoint（占用 VNet 的一个私有 IP 地址，相当于网卡）供应用访问 Azure 服务（包括 Event Hubs、Cosmos DB 等），提供最高级别的访问粒度控制。从虚拟网络到 Azure 服务的网络流量是通过微软骨干网络。除 Basic tier 外都支持。

Azure 在网络安全实践上有一篇详尽的 Security baseline 文章。

可用性

Event Hubs 提供比较高的 SLA（Dedicated tier：99.99%）。

从写的角度，多 Partition 存储设置以及 round-robin 发送策略可以避免单点短暂异常导致的可用性下降。

谈一个灾难恢复话题，Event Hubs 提供如下方案：

1. namespace 分 primary、secondary，在两者直接 Azure 提供单向的 metadata（消费组、namespace 配置等）自动同步（每分钟 50~100 个配置项）。
2. 在 primary 故障时，应用（前提需要配置 Fully Qualified Domain Name 连接串来访问 namespace）快速切换到 secondary 上。这个切换让应用具备一定的故障逃逸能力：在瞬间完成切换；但不会复制数据内容（primary 上的老数据要等 AZ 恢复后可读）。
3. 这一故障恢复机制并不能处理一些复杂情况，例如消费位置 offset 在切换前后的 namespace 并不能直接使用。需要重启消费者程序并主动指定新的消费开始位置。

如下是一个高可用架构最佳实践，从 Event Hubs、应用两个层面都增加冗余：

价格

在写入、读取流量上，Event Hubs 并无计费项设计，吞吐能力绑定在 tiers 上。

以 Premium tier 为例，PU 绑定了存储量、流量、投递能力，因此 PU 单价也不便宜；如果业务用得满（例如对于数据多次消费业务场景），费用上会比 Confluent、AWS MSK 有优势。这与一般的按量（流量、存储量）付费模型还是有较大区别。

参考资料

Azure 官网文档