你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 事件中心是一个实时数据流式处理平台和事件引入服务，每秒可以接收和处理数百万个事件。 它提供具有时间保留缓冲区的统一流式处理平台，将事件生成者与事件使用者分离。 事件中心原生与 Azure 分析服务集成，并支持多个协议，包括 AMQP、Apache Kafka 和 HTTPS，用于灵活的事件流式处理体系结构。
本文假设作为架构师，你已查看 消息传送决策树 ，并选择 Azure 事件中心作为工作负荷的消息传送解决方案。
本文中的指南提供了对应于 Well-Architected 框架支柱原则的架构建议。
技术范围
此次审查重点分析以下 Azure 资源的相关决策：
- Azure 事件中心
Reliability
可靠性支柱的目的是通过 建立足够的复原能力和从故障快速恢复来提供持续的功能。
可靠性设计原则 为各个组件、系统流和整个系统提供高级设计策略。
工作负荷设计清单
根据可靠性设计评审核对清单开始实施您的设计策略。 确定其与业务需求的相关性，同时牢记应用程序的性质及其组件的关键性。 扩展策略以根据需要包含更多方法。
查看可能限制设计的配额和限制： 分析影响体系结构决策 的配额和限制 。 对于大规模方案，请注意与不同服务层关联的分区限制，因为它们差异很大。
确定所需的吞吐量单位或处理单位数。 这些设置定义消息引入容量并为工作负荷建立缩放边界。 将有效负载保持在所选层的最大消息大小内。
选择与服务层匹配的相应消息保留期，并满足恢复和重播要求。 围绕每个命名空间的使用者组限制规划应用程序体系结构。
通过故障模式分析预测潜在故障： 故障模式分析提供了一种系统的方法，可帮助你识别故障并创建缓解策略，使消息传送服务具有复原能力。
Failure 缓解措施 命名空间不可用 为早期检测实施监视和警报（请参阅监视注意事项）。 规划跨区域故障转移功能。 分区不可用 设计分区分布策略以防止单一故障点。 在生产者和消费者中实现带有指数回退的重试逻辑。 高消息量超过吞吐量限制 规划容量缩放以处理流量高峰。 使用断路器模式实现客户端侧限速保护。 定义事件流式处理工作负荷的可靠性目标： 设置明确的可靠性目标，指导体系结构决策和作实践。 定义服务级别目标（SLO），其中包括消息引入可用性、使用者处理延迟和端到端传递性能。 使用服务级别指示器（SLI）来度量这些指标。
设置可用性目标，以符合服务级别协议（SLA）的保证：标准层为 99.9%，专用层为 99.99%。 评估直接影响工作负荷的恢复目标和层级选择决策的保留期限要求。
实现冗余策略以消除单一故障点： 添加多个冗余层，包括可用性区域、异地复制和分区分布。 在高级层和专用层中启用区域级冗余，实现跨可用性区域的自动复制，并在同一区域内具有透明的故障转移功能。
对专用层命名空间使用异地复制，以跨多个区域实时异步复制事件和元数据。 此方法提供区域故障转移功能。
添加分区和应用程序级冗余，并使用有效的分区键分布来防止热点。 部署生产者和消费者冗余模式，以确保在实例发生故障时操作能够持续进行。 添加存储帐户冗余以保护使用者状态管理所需的检查点数据。
设计可靠的扩展能力以处理可变的工作负载： 在标准级别和高级级别中通过自动扩展配置基础设施的扩展。 此功能在流量高峰期间自动缩放吞吐量单位。 使用专用层实现具有预留容量的可预测性能。
仔细规划分区缩放，因为创建后无法减少分区计数。 使用跨分区分配负载的生成者模式实现应用程序级缩放。 为获得最佳吞吐量，请选择适当的分区键，并将使用者组实例与分区计数保持一致。
实现对可靠性的监视和警报： 配置 Azure Monitor 以收集指标。 跟踪消息引入量、吞吐量利用率和使用者滞后时间。 添加基础结构指标以监视命名空间运行状况。
配置与 SLO 及业务影响严重性保持一致的阈值。 监视多维指标，了解命名空间、事件中心和分区级别的粒度可见性。
为事件中心配置自我保存和正常降级： 事件中心不包含内置死信队列。 实现自定义模式来处理有害消息，并使用断路器模式在恢复方案中保护流量。
通过为每个组创建只有一个活动接收器的单独使用者组来隔离使用者。 设置 SDK 的异常处理，以正确捕获重试策略中的
EventHubsException或OperationCancelledException。 启用捕获功能，为事件重播和恢复方案提供持久存储。进行可靠性测试以验证复原能力： 使用可靠性测试来验证工作负荷是否满足可用性和性能目标。 包括以下测试：
在现实的流式处理条件下测试分区可用性、使用者延迟恢复和吞吐量缩放。
运行压力测试，以验证预期和高峰流量条件下的性能。
执行使用者滞后测试，以确保处理与引入速率保持同步。
使用混乱工程测试解决方案的复原能力，并引入有意的故障。
执行故障转移测试以验证异地灾难恢复和区域冗余功能。
测试 Azure 存储和其他服务依赖项的依赖项故障。
为业务连续性设计灾难恢复策略： 对专用层使用标准层和高级层的异地灾难恢复或异地复制来提供区域故障转移功能。 根据业务需求定义恢复时间目标（RTO）和恢复点目标（RPO）。 选择 DR 模式，例如主动-被动（用于成本优化）或主动-主动模式（对于最小 RTO）。
对标准层和高级层使用异地灾难恢复，以跨区域在配对命名空间之间启用元数据复制。 此设置在区域性服务中断期间提供自动故障转移功能。 实现客户端故障转移功能，以加快恢复速度。 评估所选模式的数据一致性要求。
创建操作连续性计划，其中包括元数据和使用者偏移的记录备份过程、实施执行手册、通信计划以及定期安排的灾难恢复测试。
配置建议
| 建议 | 益处 |
|---|---|
| 通过选择具有可用性区域支持的 Azure 区域来创建命名空间时启用 可用性区域冗余 。 | 以最少的恢复时间提供自动数据中心级故障转移，且不会更改应用程序。 |
| 为专用层命名空间启用 异地复制 ，实时跨多个区域复制事件和元数据。 使用适当的网络连接配置主要区域和次要区域，并监视复制滞后指标，以确保跨区域的数据一致性。 |
启用区域故障转移功能，并在区域性中断期间尽量减少数据丢失。 |
| 设置主命名空间和辅助命名空间之间的 异地灾难恢复 配对，然后为命名空间对配置别名。 更新连接字符串以使用别名实现透明故障转移功能。 | 使用别名连接启用具有透明客户端故障转移的跨区域故障转移功能。 此配置可确保区域性中断期间的业务连续性。 |
| 为事件分发实现 基于哈希的分区键 ，并在创建事件中心期间设置适当的分区计数。 监视分区级指标，以便进行热点检测和负载均衡验证。 | 防止分区热点，并通过跨分区的均衡负载分布实现水平缩放。 |
| 为标准层命名空间启用 自动膨胀 ，并根据峰值负载预测设置最大吞吐量单位。 将高级层用于需要可预测性能的持续高吞吐量工作负荷。 | 防止引入限制通过自动容量缩放，并在负载变化期间保持一致的可用性，而无需手动干预。 |
|
在 Azure Monitor 中为使用者延迟、吞吐量利用率和限制事件配置事件中心警报。 设置符合服务水平目标（SLO）的阈值。 为连接和身份验证失败启用警报，然后为事件响应创建警报作组。 |
启用早期问题检测、减少事件响应时间，并通过监视覆盖范围提供容量规划见解。 |
安全性
安全支柱的目的是为工作负荷提供 保密性、完整性和可用性 保证。
安全设计原则通过对 Azure 事件中心的技术设计应用方法，为实现这些目标提供了高级设计策略。
工作负荷设计清单
根据 设计评审清单制定针对安全 的设计策略，并确定漏洞和控制，以增强安全防御能力。
为事件中心工作负荷建立安全基线： 查看解决关键 安全域的事件中心安全基线 。 为事件中心应用Microsoft云安全基准控制，这些控制措施涵盖静态和传输中的数据加密、网络隔离功能和精细访问控制机制。
实施分段策略以隔离事件中心资源并控制访问边界： 跨工作负荷的多个方面应用隔离策略，例如基于标识的访问控制、网络边界和资源组。 将 Microsoft Entra ID 与基于角色的访问控制（RBAC）配合使用，为基于标识的分段创建逻辑访问控制边界。
设置网络分段以隔离流式传输流量。 使用虚拟网络集成和专用连接选项以避免暴露于公共互联网。 配置命名空间级隔离以分隔租户边界，并为共享事件中心部署中的多租户事件处理实现使用者组分离。
设置标识和访问管理： 使用 Microsoft Entra ID 作为受信任的标识提供者，在事件中心工作负荷中集中进行身份验证和授权。
通过 SendOnly 和 ListenOnly 策略为细粒度访问控制配置角色授权。 这些策略将发布者和使用者权限分开。 根据设备合规性、网络位置和用户上下文，启用用于上下文感知安全的条件访问策略。
为管理和高特权标识分配单独的角色，并启用实时访问。 使用托管标识可消除服务间通信模式中的凭据管理开销。
添加网络安全控制来保护事件中心流量和连接： 使用专用终结点、服务终结点和 IP 防火墙规则保护流式传输流量免受未经授权的访问。 配置专用终结点以避免互联网公开。 启用服务终结点以在没有公共路由的情况下提供安全的虚拟网络连接。
设置网络安全组以在子网级别筛选流量和控制流。 配置 IP 防火墙规则以仅允许从特定 IP 地址和 CIDR 范围进行访问。
为事件中心事件流和元数据配置数据加密： 启用客户管理的密钥，以实现增强的加密控制和法规合规性。 对需要额外保护的方案使用双重加密。 将 TLS 1.2 设置为安全客户端连接和服务间通信的最低配置。
建立涉及客户管理密钥的操作过程的密钥轮换策略。 在组织需要高安全性密钥存储时部署托管 HSM。
强化事件中心命名空间和实体配置以减少攻击面： 如果不需要使用自动扩张来管理容量，请将其关闭。 禁用其他未使用的功能和协议以删除潜在的攻击途径。
删除未使用的使用者组和事件中心，并仅启用工作负载所需的功能。
通过适当的机密管理保护事件中心连接字符串和访问密钥： 使用托管标识作为首选身份验证方法，以避免存储凭据。 必须使用连接字符串或 SAS 令牌时，请安全地存储它们并定期轮换它们。
将事件中心连接字符串存储在 Azure Key Vault 中，并为生成者和使用者配置单独的密钥，以强制实施最低特权原则。 为不同的使用者和环境维护不同的访问密钥，以便可以撤销特定访问权限。 部署生存期较短的 SAS 令牌，以减少安全风险。
在事件中心操作中实现安全监视和日志记录： 配置诊断日志记录以捕获身份验证事件、数据平面访问模式和配置更改。 设置身份和访问监控以跟踪身份验证失败和提升权限的尝试。
通过检查连接的来源来监视网络访问模式，以检测未经授权的访问。 保留用于配置更改和管理作的日志，以支持合规性和安全分析。
启用威胁检测，以警报通知您可疑活动，包括异常访问量或未知来源。 监视使用者组作和分区访问模式以检测异常。 使用用户和实体行为分析来识别可能指示安全事件的异常使用模式。
为事件中心流式处理工作负荷实现安全测试和验证过程： 通过验证数据所有者、数据发送方和数据接收方角色在命名空间、事件中心和使用者组范围内正常运行来测试分配。 验证条件访问策略是否有效阻止未经授权的生成者和使用者连接。
通过专用终结点连接测试、IP 防火墙规则检查来验证事件中心的网络安全，以及通过虚拟网络集成验证来实现流式传输流量的隔离，从而确保生成者和使用者的访问安全。
测试事件数据和元数据的客户管理的密钥加密，验证 AMQP 和 HTTPS 连接的 TLS 1.2 强制实施，并确认双重加密是否按预期工作。 运行特定于流的渗透测试，包括生成者身份验证绕过尝试、使用者组枚举和分区级访问检查。
配置建议
| 建议 | 益处 |
|---|---|
| 使用Microsoft Entra ID 授权访问事件中心 资源。 根据访问要求，在适当的范围级别分配内置角色，包括数据所有者、数据发送方和数据接收器。 将这些分配范围限定在命名空间、事件中心或使用者组级别，以获得符合作需求的精细访问控制。 |
实现跨范围的细粒度访问控制，并明确分隔生产者、消费者和管理操作。 |
| 在专用子网中部署 专用终结点 进行网络隔离，并配置网络安全组以控制流向事件中心子网的流量。 或者，在命名空间级别为已知源网络应用 IP 防火墙规则 ，并根据安全区域跨虚拟网络组织命名空间。 |
通过专用连接消除公共 Internet 公开，并将网络级流量控制与组织安全区域保持一致。 |
|
在命名空间级别启用 Microsoft Entra ID 身份验证，并在托管身份可用的情况下禁用 SAS 身份验证。 创建需要合规设备 的条件访问策略 ，并阻止来自不受信任的位置的访问。 对于具有事件中心数据所有者角色的用户，需要多重身份验证（MFA），以增强管理安全性。 |
命名空间级配置启用中央身份验证设置，适用于所有事件中心实体。 禁用 SAS 会消除共享凭据管理开销。 |
| 将命名空间范围内的 最低 TLS 版本设置为 1.2 ，以阻止较旧的易受攻击的协议。 在 Log Analytics 中启用诊断日志记录并查询 TLS 版本冲突，以识别不合规的客户端。 | TLS 1.2 可防止利用可能导致传输中的数据泄露的旧 SSL 或 TLS 漏洞。 |
| 在 Key Vault 中创建 RSA 2048 密钥，并将 Key Vault 加密服务加密用户角色分配给命名空间托管标识。 将命名空间配置为使用 客户管理的密钥 ，并在 Key Vault 中设置 90 天的轮换策略。 创建命名空间时启用 双重加密 ，因为以后无法添加此功能。 |
CMK 配置为数据主权要求提供法规遵从性。 90 天的轮换策略平衡安全与作稳定性。 创建时双重加密从一开始就提供额外的保护层。 |
| 分配 将事件中心配置为在订阅范围内使用专用 DNS 区域 的策略，以便实施一致的配置。 为 Microsoft.EventHub 写入操作创建活动日志警报规则。并通过操作组发送通知。 查看每周针对事件中心命名空间的 Microsoft Defender for Cloud 建议。 |
订阅范围内的策略分配可确保跨命名空间配置一致。 每周 Defender for Cloud 评审可帮助你确定安全性改进。 |
| 将连接字符串存储在 Key Vault 中，并设置了 90 天的到期日期，并将 Key Vault 机密用户角色分配给应用程序的托管标识。 如果需要 SAS 令牌，请生成具有一小时到期时间的实体级令牌，并仅使用“发送”或“侦听”权限。 | 90 天的到期时间要求定期更换凭据。 使用托管身份访问 Key Vault 消除了对辅助凭据存储的要求。 一小时的 SAS 令牌过期限制凭据公开窗口。 在令牌泄露的情况下，发送/仅侦听权限可减少爆炸半径。 |
| 将 诊断日志 发送到 Log Analytics 工作区，并在数据连接器下 Microsoft Sentinel 中添加事件中心数据连接器，以便进行高级威胁检测。 为 RequestsAuthenticationError 指标创建警报，该指标的阈值超过每小时 10 个，用于检测身份验证攻击和潜在的安全事件。 |
Microsoft Sentinel 连接器将事件中心安全事件与其他 Azure 资源集中用于威胁检测。 UEBA 检测到静态规则错过的异常访问模式。 RequestsAuthenticationError 指标警报实时通知身份验证攻击，以便响应事件并缓解安全威胁。 |
| 在 Azure Pipelines 中添加 Azure Policy 符合性检查任务 ，并在部署之前使用 Microsoft 安全 DevOps 扩展扫描 Bicep 或 ARM 模板。 配置管道环境审批以要求零违反策略。 在进行渗透测试之前，请在 Azure 门户中提交 渗透测试通知 。 |
策略符合性检查可防止部署配置错误的资源。 安全 DevOps 扩展在部署之前检测到常见的 IaC 安全问题。 门户通知可确保符合Microsoft渗透测试要求，并在安全评估期间符合 Azure 安全策略。 |
成本优化
成本优化侧重于 检测支出模式、优先考虑关键领域的投资，以及优化其他 以满足组织预算，同时满足业务需求。
成本优化设计原则提供了一种高级设计策略，以实现这些目标，并在与 Azure 事件中心及其环境相关的技术设计中根据需要做出权衡。
工作负荷设计清单
根据投资的成本优化设计评审核对清单开始实施您的设计策略。 微调设计，使工作负荷与分配的预算保持一致。 设计应使用正确的 Azure 功能，监视投资，并查找随时间推移进行优化的机会。
为事件中心工作负荷创建和维护成本模型： 根据峰值和平均流量模式评估吞吐量单位或处理单元要求，以便进行准确的容量规划。 在成本估算中包括自动膨胀成本和服务层级分析（基本层、标准层、高级层和专用层）。
根据保留期和消息卷计算消息保留存储成本。 包含事件中心捕获、操作和目标存储的成本。 考虑架构注册表成本、跨区域数据传输成本和次要区域的灾难恢复费用。
为事件中心资源实现成本监视和预算警报： 配置Microsoft成本管理，以便进行精细的成本跟踪和分析。 应用资源标记，以便跨工作负荷和业务部门进行准确的成本分配。 激活成本异常情况检测以标记意外支出模式并监视吞吐量单位利用率。
跟踪消息保留的存储成本和增长趋势，监控数据捕获成本和目标存储费用，并为逐步增加和突然激增设置预算警报。 保持跨区域数据传输费用的可见性。
优化事件中心容量规划和自动缩放配置，提高成本效益： 分析流量模式，以确定最佳吞吐量单位或处理单元分配。 监视分区利用率以获取优化机会。 使用适当的缓冲区规划稳定状态和峰值需求的容量，实现经济高效的性能。
在标准层部署中设置自动膨胀最大限制，以防止意外的成本增加。 微调分区计数，实现高效的吞吐量利用率和使用者缩放。 使用负载测试来验证容量假设。
通过根据工作负荷特征比较服务层级成本和性能权衡来评估层成本效益。 假设专用层适用于大容量的可预测工作负荷，其中一致的性能提供更好的总拥有成本。
为事件中心部署建立成本防护措施和治理策略： 创建 Azure Policy 定义，以强制实施吞吐量单位限制并限制服务层选项。 定义保留期策略以防止长期存储成本增长。
为高容量部署和层升级设置审批工作流。 允许对合法需要进行策略豁免。 构建治理流程，包括定期审查资源利用率和记录的程序，以帮助您进行容量规划。
优化开发和测试环境以降低事件中心成本： 将基本层或标准层与最小吞吐量单位和较短的保留期一起使用，以用于开发和测试方案。 使用事件模拟和综合数据来降低流量成本。 维护真实的测试功能。 单独的开发环境预算。
实现自动化生命周期管理，以在非工作时间计划关闭。 安全允许时，通过共享多个项目的命名空间来建立资源共享。 此方法可提高成本效益，而不会降低工作效率。
自动执行成本优化和持续改进过程： 根据流量模式自动调整吞吐量单位，并根据数据访问模式自动执行保留期调整。 自动合并未充分利用的资源以提高总体利用率。
使用 Azure 自动化来协调例程任务和生命周期管理过程。 集成 Azure 顾问成本优化建议。
跨工作负荷合并和优化事件中心资源利用率： 评估工作负荷是否可以安全地共享命名空间和资源，并确认其流量模式相互补充。
实现具有明确隔离边界的多租户体系结构，并分离使用者组以隔离共享事件中心内的工作负荷。 合并捕获目标以优化存储成本和管理开销。
通过共享资源的退款机制建立成本分配。 为工作负载载入审批创建策略。
配置建议
| 建议 | 益处 |
|---|---|
| 配置 成本管理 ，以便进行精细的成本跟踪和分析。 为多阶段成本控制警告创建带有 50%、75%、90%和 100% 警报阈值的预算。 设置每周和每月计划的自动化成本报告，以实现一致的成本可见性和趋势分析。 |
实现跨工作负荷的准确成本分配和退款，并通过多级警报提供成本溢出的预警。 |
| 根据经济分析选择适当的 服务层级 （基本、标准、高级或专用）。 通过预算限制配置自动膨胀，并设定最大吞吐量单位限制。 |
将层与工作负荷匹配可优化成本。 为自动膨胀设置最大值可防止意外成本增加。 |
| 配置 保留期，例如标准层的 1-7 天或专用层最多 90 天。 将这些时间段与数据访问模式和合规性要求保持一致。 启用 事件中心捕获 以使用 Azure Blob 存储或 Azure Data Lake Store 进行长期存储。 为很少访问的捕获数据选择冷存储层或存档存储层。 |
通过优化的保留策略降低存储成本，并提供负担得起的长期存档选项。 |
| 部署 Azure Policy 定义 ，以设置吞吐量单位上限并限制允许的层来强制实施成本控制。 为受控灵活性设置策略豁免审批工作流。 |
通过基于策略的控制提供自动化成本治理，并降低成本溢出风险。 允许通过结构化审批流程对合法业务需求进行受控的例外。 |
| 创建 自动化 脚本，以在周夜和周末关闭非生产环境，以降低运行时成本。 使用 Azure Functions 在开发时间段中配置自动启动触发器。 将 环境标记 应用于自动化目标和成本分配。 |
通过自动化生命周期管理减少开发和测试成本，并为开发工作负荷提供适当的功能，并降低成本。 |
| 使用事件中心筛选器配置 Azure 顾问成本建议 ，以自动识别优化机会。 若要系统地提高成本，请使用 Azure 逻辑应用自动处理顾问建议。 使用 Azure Functions 根据警报触发器调整吞吐量单位，实现自动化成本优化。 |
通过自动化分析和调整提供持续成本优化。 |
卓越运营
卓越运营主要侧重于 开发实践、可观测性和发布管理的各个过程。 卓越运营设计原则 提供了一个高级设计策略，用于实现这些运营需求目标。
工作负荷设计清单
根据 卓越运营的设计评审清单 启动设计策略，以定义与 Azure 事件中心相关的可观测性、测试和部署过程。
对配置更改应用安全部署做法： 为命名空间级别更改实现蓝绿部署。 通过隔离的用户组为用户应用程序进行金丝雀部署。
监视部署期间的分区运行状况、使用者滞后趋势和吞吐量指标，以确保部署成功。 启用滚动更新，使使用者逐渐移动到新版本，而不会停机。
设计基础结构即代码（IaC）策略进行资源管理： 根据事件中心资源属性覆盖范围和依赖项管理的需求，使用 ARM 模板、Bicep 或 Terraform。
将命名空间级别配置（例如定价层、自动膨胀设置和网络安全）与特定于事件中心的设置（例如分区计数、保留期和使用者组）分开。 为层特有的变体添加参数，例如吞吐量单位限制和保留期。
为流处理关键设置（如分区计数）实现漂移检测。 为吞吐量单位更改和使用者组生命周期任务设置自动修正过程。
为工作负荷建立生成和部署管道： 创建持续集成和持续部署（CI/CD）管道，用于部署事件中心基础结构、应用程序和架构。
将部署阶段视为必需步骤。 在单独的阶段部署基础结构，然后部署具有正确排序和架构管理的使用者应用程序。
实现监控和日志记录：监控解决流式特征的指标，例如分区使用率、消费者滞后时间、吞吐量速率和命名空间容量使用率。
结构化日志记录有助于排查问题并支持操作。 添加关联 ID，以跟踪从生产者到消费者的整个事件过程。
生成自定义仪表板以查看分区运行状况并监视使用者组性能。 为使用者延迟和吞吐量单位耗尽配置警报阈值，以便进行主动响应。
设计操作和应急响应过程：为消费者组管理、分区重新均衡、吞吐量单元缩放和保留策略调整制定操作流程。
设计事件响应程序以解决具体情况，包括分区不可用、消费者延迟累积和吞吐量限制控制。
规划主要区域故障的异地灾难恢复、协调使用者应用程序故障转移和定期测试过程，以确保有效性。
自动执行管理、监视和支持任务： 自动执行使用者组创建、分区缩放分析、吞吐量单位调整和使用者延迟监视。
使用自动化运行手册来执行例行任务，包括轮换访问策略、获取配置更新，以及维护命名空间。 确保实现一致，并减少人为错误的可能性。
使用 Azure Policy 检测设置之间的配置偏移。 设置自动事件响应，以解决使用者延迟修正、吞吐量缩放和连接故障恢复。
为流式处理工作负荷实施测试和验证策略： 测试分区分配算法，以确保负载分布均衡，验证生成者批处理和分区键有效性，并在不同的吞吐量方案中测试使用者组缩放行为。 运行端到端流媒体测试，以模拟真实的事件量和消费者延迟模式。
在开发初期验证事件中心配置，包括分区计数、吞吐量单元分配和保留期设置。 测试架构演变与架构注册表的兼容性，确认使用者组检查点管理，并在生产部署之前检查生成者重试逻辑和使用者错误处理模式。
配置建议
| 建议 | 益处 |
|---|---|
| 在 Bicep 或 Terraform 中创建 IaC 模板，以定义事件中心命名空间、事件中心配置、分区计数、吞吐量单位和使用者组，使用适当的参数来设置环境特定值。 | 确保跨环境进行一致的部署。 减少手动配置错误，并通过自动化验证功能实现版本控制的基础设施更改。 |
| 实现多阶段 CI/CD 管道 ，用于隔离基础结构、使用者应用程序和架构部署的阶段，包括生产阶段和自动化测试阶段的审批入口。 | 组织和协调部署。 启用集成测试和验证，并提供管道整体功能性能的可见性。 |
| 通过自定义仪表板、具有结构化相关 ID 的诊断日志记录和 Application Insights 集成配置 Azure Monitor，以便跨生成者和使用者应用程序进行端到端事务跟踪。 | 提供操作可见性和实时监控功能。 支持使用分布式跟踪、审核和异常情况检测进行高效故障排除。 |
| 使用 Azure Monitor 工作簿编写操作手册。 使用这些操作手册记录消费者组管理、吞吐量扩展步骤、分区重新均衡过程，以及消费者延迟问题修复和连接问题的交互式故障排除步骤。 | 标准化操作流程。 加快事件响应速度，确保跨运营团队的一致做法，并提供交互式指导。 |
| 实现 自动化运行手册以进行访问策略轮换和吞吐量更改。 部署强制实施诊断设置、保留期和网络限制的 Azure Policy 定义 。 | 减少人工操作开销。 通过自动合规性监视和主动管理防止配置偏移。 |
| 实现 Azure 负载测试 方案，用于模拟实际生成者事件速率、使用者模式和分区键分布。 在生产升级之前，将负载测试集成到部署管道中，以便进行自动化性能检查。 | 确认实际负载下的性能，以最大程度地减少生产问题并启用数据驱动的容量规划。 |
性能效率
性能效率就是通过管理容量来保持用户体验，即使负载增加也不例外。 该策略包括缩放资源、识别潜在瓶颈和优化性能。
性能效率设计原则 提供了一个高级设计策略，用于根据预期使用量实现这些容量目标。
工作负荷设计清单
根据性能效率设计审查清单开始策略设计。 定义基于 Azure 事件中心的关键绩效指标的基线。
规划 Event Hubs 工作负载容量需求： 评估峰值摄取速率、并发生产者、消费者吞吐量和保留需求。 确定当前流式处理模式和消费者处理能力的基线。 考虑季节性变化和预期增长预测。
考虑事件中心缩放选项，包括吞吐量单位缩放（垂直）和基于分区的缩放（水平）。 考虑可在流式处理体系结构中创建瓶颈的下游依赖项。
若要确认容量估计，请执行负载测试并使用实际流量和模式。 根据实际使用情况指标监视和调整配置，以获得随时间推移的最佳性能。
根据性能需求选择事件中心层和 SKU： 选择符合性能要求的层，包括引入速率、分区限制和保留期。 另请考虑集成需求，例如 Kafka 协议兼容性、架构注册表功能和流分析连接。
对于中等吞吐量方案，标准层最多支持 32 个分区和 1-7 天的保留期。
高级层提供增强的网络、客户管理的密钥和改进的 SLA 保证。
专用层提供高达 1,024 个分区和 90 天保留期的企业级功能，以实现高吞吐量方案。
设计事件中心缩放策略以实现最佳性能： 根据工作负荷特征选择吞吐量单位缩放（垂直）或分区缩放（水平）。 使用摄取速率、使用者滞后和分区利用率作为关键缩放触发器。
实现基于分区的缩放以提高使用者并行度。 请避免将事件发布到各个分区，并根据需要实现下游排序。 为吞吐量单位配置自动膨胀，并建立使用者组缩放模式。
设计具有分布良好的分区键和均衡负载分布的无状态使用者。 在突发流量、持续负载和使用者滞后恢复方案中测试缩放行为，以检查有效性。
实现事件中心性能监视： 建立基线引入速率、使用者滞后时间、吞吐量单位利用率和分区分布。 收集关键指标，包括入口和出口吞吐量、每个分区的使用者滞后时间以及连接指标。 实现分布式跟踪以获得端到端的可见性。
分析趋势，以确定模式、季节性变化和性能下降的迹象。 配置警报，以降低吞吐量、增加的使用者延迟和不均衡的分区利用率。
执行事件中心性能测试： 测试事件中心如何响应实际的工作负荷模式，例如突发引入、持续吞吐量和使用者滞后方案。 使用与生产特征匹配的真实事件负载来测试生产者和消费者。
在测试期间建立引入速率、使用者吞吐量和端到端延迟的基线。 在各种负载条件下验证自动通胀有效性和使用者缩放行为，以确保缩放机制按预期运行。 分析吞吐量指标、使用者滞后模式和资源利用率，然后根据基线进行验证。
通过配置和设计模式优化事件中心性能： 优化连接池、批大小、压缩和重试策略，以实现最佳吞吐量。
优化分区键设计、批处理策略和使用者组组织，以均衡吞吐量分布。 利用 AMQP 协议优化、Kafka 兼容性和架构注册表集成来提高序列化效率。
选择靠近生产者和使用者的 Azure 区域。 为分布式方案实现异地复制。 应用体系结构模式，例如事件溯源、CQRS 和发布-订阅，以获得最佳性能。
配置建议
| 建议 | 益处 |
|---|---|
| 根据标准层和高级层命名空间的容量规划估算值设置初始 吞吐量单位 ，并启用 自动膨胀。 配置成本控制的最大吞吐量单位限制，并将利用率阈值触发器设置为 80-90% 利用率。 在各种负载方案中测试缩放行为，以确认自动缩放按预期工作。 |
自动缩放消除了流量高峰期间的手动干预，并根据需求优化成本。 设置最大吞吐量限制可防止高峰期出现意外成本溢出。 |
| 为专用层群集配置 容量单位缩放，依据工作负载性能测试和资源利用率监控。 创建群集时启用 “支持缩放 ”选项，以便调整缩放。 | 专用群集缩放通过预先分配的 CPU 和内存资源提供可预测的企业级性能。 |
| 实现 事件处理程序主机 或 Azure Functions 以自动管理分区并避免手动分配。 配置预提取设置以提高吞吐量。 监视每个分区的使用者滞后指标，以确定处理瓶颈。 |
跨使用者实例的自动分区分布简化了缩放，并消除了手动干预。 使用者延迟可见性可识别针对目标优化工作的处理瓶颈。 |
| 为命名空间和事件中心资源启用 诊断设置 ，以捕获指标和日志。 为性能仪表板创建 Azure Monitor 工作簿 ，并为使用者延迟和吞吐量阈值配置警报。 监视吞吐量利用率和自动膨胀事件，以验证缩放行为和容量管理有效性。 |
基于阈值的警报主动检测问题并防止性能下降。 历史分析支持容量规划。 集中式仪表板提供操作可视性。 |
| 在生成者和使用者应用程序中集成 Application Insights SDK 以收集遥测数据。 配置相关 ID，以便可以端到端跟踪事件，并测量下游依赖项之间的延迟。 | 通过事件流式处理管道的端到端可见性，可以更轻松地自动分析性能和发现异常。 相关跟踪可加速故障排除。 |
| 使用 Azure 负载测试 或自定义框架模拟真实的生产样式工作负荷。 实现包括生成者、使用者和故障条件的测试方案。 在每次测试运行和记录结果、基线和最佳配置设置期间监视性能指标，以供将来参考。 |
验证的容量限制和缩放行为提高了对生产部署的信心。 建立的性能基线可以更轻松地规划容量，并随着时间的推移微调环境。 |
| 在 SDK 设置 中配置批大小、预提取值和重试策略，以提高生成者和使用者性能。 使用连接池以减少开销，并通过与架构注册表的集成启用压缩。 | 批处理和预提取调优可以优化吞吐量。 连接池和压缩可降低网络开销。 通过基于指标的优化进行数据驱动的优化可实现持续性能改进和高效的资源利用率。 |
| 为 流分析和Azure Functions 配置专用使用者组以优化下游处理。 为事件元数据和处理结果添加缓存。 根据处理模式优化检查点频率。 | 专用使用者组优化下游处理。 缓存可减少冗余处理并提高效率。 优化检查点机制平衡了弹性和性能要求。 |
Azure 策略
Azure 提供了与 Azure 事件中心及其依赖项相关的大量内置策略。 可以通过 Azure Policy 审核上述一些建议。 例如，可以检查以下情况：
- 事件中心命名空间使用客户管理的密钥进行加密
- 事件中心命名空间已启用双重加密
- 事件中心的资源日志已启用
若要进行有效的治理，请查看 事件中心的 Azure Policy 内置定义 ，以及可能影响消息传送基础结构安全性的其他策略。
Azure 顾问建议
Azure 顾问是一名个性化的云顾问，可帮助你遵循最佳做法来优化 Azure 部署。
有关详细信息，请参阅 Azure 顾问。
示例体系结构
演示关键建议的基础体系结构： 使用 Azure 流分析进行流处理。