你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
Azure 通信服务的服务限制
本文介绍 Azure 通信服务 API 的限制和可能的解决方案。
限制模式和体系结构
当达到服务限制时,你会收到 HTTP 状态代码 429(请求过多)。 通常,以下最佳做法用于限制:
- 减少每个请求的操作数。
- 降低调用频率。
- 避免立即重试,因为所有请求都根据使用限制产生累积。
有关如何设置服务体系结构来处理限制的更多一般性指南,请参阅限制模式的 Azure 体系结构文档。 若要调高带宽限制,请向 Azure 支持部门发出请求。
- 转到 Azure 门户并登录。
- 选择“帮助+支持”。
- 选择“创建新的支持请求”。
- 在“描述问题”文本框中,输入“技术”,然后选择“转到”。
- 在“选择服务”下拉菜单中,选择“服务和订阅限制(配额)”,然后选择“下一步”。
- 在问题说明中,选择问题类型、订阅和配额类型值,然后选择“下一步”。
- 查看任何建议的解决方案(如果可用),然后选择“下一步”。
- 根据需要添加其他详细信息,然后选择“下一步”。
- 在“查看 + 创建”中检查信息,根据需要进行更改,然后选择“创建”。
按照步骤向 Azure 支持部门发出请求。
需要电话号码
在获取电话号码之前,请确保订阅满足地理位置和订阅要求。 否则无法购买电话号码。 以下限制适用于通过电话号码 SDK 和 Azure 门户购买号码。
操作 | 范围 | 期限 | 限制(请求数) |
---|---|---|---|
购买电话号码 | Azure 租户 | - | 1 |
搜索电话号码 | Azure 租户 | 一周 | 5 |
采取的操作
若要调高号码购买限制,请向 Azure 支持部门发出请求。
- 转到 Azure 门户并登录。
- 选择“帮助+支持”。
- 选择“创建新的支持请求”。
- 在“描述问题”文本框中,输入“技术”,然后选择“转到”。
- 在“选择服务”下拉菜单中,选择“服务和订阅限制(配额)”,然后选择“下一步”。
- 在问题说明中,选择问题类型、订阅和配额类型值,然后选择“下一步”。
- 查看任何建议的解决方案(如果可用),然后选择“下一步”。
- 根据需要添加更多详细信息,然后选择“下一步”。
- 在“查看 + 创建”中检查信息,根据需要进行更改,然后选择“创建”。
标识
操作 | 期限(秒) | 限制(请求数) |
---|---|---|
创建标识 | 30 | 1,000 |
删除标识 | 30 | 500 |
颁发访问令牌 | 30 | 1,000 |
撤销访问令牌 | 30 | 500 |
createUserAndToken |
30 | 1,000 |
exchangeTokens |
30 | 500 |
采取的操作
建议在创建聊天线程或开始调用之前获取标识和令牌。 例如,在网页加载或应用程序启动时执行此任务。
有关详细信息,请参阅向 Azure 通信服务进行验证。
短信
发送或接收大量消息时,可能会收到 429
错误。 此错误表示即将达到服务限制。 你的消息已排队,并在请求数低于阈值后发送。
文本消息的速率限制:
操作 | 数字类型 | 范围 | 期限 | 限制(请求数) | 每分钟请求单位数 |
---|---|---|---|---|---|
发送消息 | 免费电话 | 每个号码 | 60 | 200 | 200 |
发送消息 | 短代码 | 每个号码 | 60 | 6000 | 6000 |
发送消息 | 字母数字发件人 ID | 按资源 | 60 | 600 | 600 |
采取的操作
如果你的需求超出了速率限制,请向 Azure 支持提交请求,以启用更高的吞吐量。
有关文本消息 SDK 和服务的详细信息,请参阅文本消息 SDK 概述或文本消息常见问题解答。
电子邮件
你可以发送有限数量的电子邮件。 如果超出订阅的电子邮件速率限制,你的请求将被拒绝。 在“Retry-After”时间过后,可以尝试重新发起这些请求。 如果需要,请在达到限制之前采取行动,请求提高你的发送量上限。
Azure 通信服务中的电子邮件服务旨在支持高吞吐量。 但是,该服务会施加初始速率限制,以帮助客户顺利加入进来,并避免切换到新电子邮件服务时可能出现的一些问题。
建议在两到四周内逐步增加使用 Azure 通信服务的电子邮件服务处理的电子邮件量,同时密切监视电子邮件的传递状态。 这种逐步增加的方式可让第三方电子邮件服务提供商适应域中电子邮件流量的 IP 变化。 循序渐进的变化让你有时间保护发件人信誉,并维护电子邮件传递的可靠性。
Azure 通信服务电子邮件服务支持每小时最多 100-200 万封邮件。 可以根据以下几个因素启用高吞吐量,包括:
- 客户高峰流量
- 业务需求
- 能够管理失败率
- 域声誉
失败率要求
若要启用高电子邮件配额,电子邮件失败率必须小于 1%。 如果失败率很高,则必须在请求增加配额之前解决问题。 客户应主动监视其失败率。
如果在增加配额后失败率增加,Azure 通信服务将联系客户立即采取行动,确定解决时间线。 在极端情况下,如果在指定的时间线内未管理失败率,Azure 通信服务可能会减少或暂停服务,直到问题得到解决。
相关文章
Azure 通信服务提供丰富的日志和分析来帮助监视和管理失败率。 有关详细信息,请参阅以下文章:
- 提高发件人在 Azure 通信服务电子邮件中的信誉
- Email Insights
- 在 Azure Monitor 中通过诊断设置启用日志
- 快速入门:处理电子邮件事件
- 快速入门:使用管理客户端库管理 Azure 通信服务中的域抑制列表
注意
若要请求更高的限制,请按照电子邮件域的配额提升中的说明进行操作。 更高的配额仅适用于经过验证的自定义域,而不适用于 Azure 托管域。
电子邮件的速率限制
操作 | 范围 | 时间范围(分钟) | 限制(电子邮件数目) | 适用的限额更高 |
---|---|---|---|---|
发送电子邮件 | 每个订阅 | 1 | 30 | 是 |
发送电子邮件 | 每个订阅 | 60 | 100 | 是 |
获取电子邮件状态 | 每个订阅 | 1 | 60 | 是 |
获取电子邮件状态 | 每个订阅 | 60 | 200 | 是 |
下表列出了 Azure 托管域的限制。
操作 | 范围 | 时间范围(分钟) | 限制(电子邮件数目) | 适用的限额更高 |
---|---|---|---|---|
发送电子邮件 | 每个订阅 | 1 | 5 | 否 |
发送电子邮件 | 每个订阅 | 60 | 10 | 否 |
获取电子邮件状态 | 每个订阅 | 1 | 10 | 否 |
获取电子邮件状态 | 每个订阅 | 60 | 20 | 否 |
电子邮件的大小限制
名称 | 限制 |
---|---|
电子邮件中的收件人数 | 50 |
电子邮件请求总大小(包括附件) | 10 MB |
每个订阅经过身份验证的最大连接数 | 250 |
对于所有消息大小限制,请考虑到 Base64 编码会增加消息的大小。 需要增加大小值,以考虑到邮件附件和任何其他二进制数据经过 Base64 编码后所导致的邮件大小增加。 Base64 编码会让邮件的大小增加约 33%,因此编码后的邮件大小会比编码前的邮件大小大 33% 左右。 例如,如果指定的最大消息大小值约 10 MB,那么预期实际的最大消息大小值约为 7.5 MB。
资源限制
名称 | 限制 |
---|---|
每个域的 SenderUsername/Mailfrom 资源 | 100 |
链接到通信服务资源的域 | 100 |
发送大于 10 MB 的附件
若要通过电子邮件发送高达 30 MB 的文件附件,请发出支持请求。
如果需要发送大于 30 MB 的电子邮件文件附件,请使用此替代解决方案。 请将文件存储在 Azure Blob 存储帐户中,并在电子邮件中包含指向文件的链接。 可以使用共享访问签名 (SAS) 来保护文件。 SAS 提供对存储帐户中资源的安全委托访问。 使用 SAS 可以精细控制客户端访问数据的方式。
使用 Blob 存储帐户的好处:
- 可以处理大型文件。
- 可以使用 SAS 或密钥精确管理文件访问。
有关详细信息,请参阅:
采取的操作
若要提升电子邮件配额,请按照电子邮件域的配额提升中的说明进行操作。
注意
电子邮件配额增加请求可能需要最多 72 小时才能得到评估和批准,尤其是周五下午收到的请求。
聊天
Azure 通信服务支持聊天。
聊天的大小限制
名称 | 限制 |
---|---|
线程中的参与者数 | 250 |
参与者批次:CreateThread |
200 |
参与者批次:AddParticipant |
200 |
页面大小:ListMessages |
200 |
消息大小 | 28 KB |
每个 Azure 机器人服务的 Azure 通信服务资源数 | 1,000 |
聊天的速率限制
操作 | 范围 | 每 10 秒限制 | 每分钟限制 |
---|---|---|---|
创建聊天线程 | 每用户 | 10 | - |
删除聊天线程 | 每用户 | 10 | - |
更新聊天线程 | 每个聊天会话 | 5 | - |
添加或删除参与者 | 每个聊天会话 | 10 | 30 |
获取或列出聊天线程 | 每用户 | 50 | - |
获取聊天消息 | 每个用户,每个聊天线程 | 50 | - |
获取聊天消息 | 每个聊天会话 | 250 | - |
列出聊天消息 | 每个用户,每个聊天线程 | 50 | 200 |
列出聊天消息 | 每个聊天会话 | 250 | 400 |
获取已读回执(参与者上限为 20) | 每个用户,每个聊天线程 | 5 | - |
获取已读回执(参与者上限为 20) | 每个聊天会话 | 100 | - |
列出聊天线程参与者 | 每个用户,每个聊天线程 | 10 | - |
列出聊天线程参与者 | 每个聊天会话 | 250 | - |
发送、更新或删除消息 | 每个聊天会话 | 10 | 30 |
发送阅读回执 | 每个用户,每个聊天线程 | 10 | 30 |
发送键入指示符 | 每个用户,每个聊天线程 | 5 | 15 |
发送键入指示符 | 每个聊天会话 | 10 | 30 |
注意
参与者超过 20 人的聊天会话不支持已读回执和键入指示器。
聊天存储
Azure 通信服务会根据创建聊天线程时设置的保留策略存储聊天消息。
重要
本文中所述的功能目前以公共预览版提供。 此预览版在提供时没有附带服务级别协议,我们不建议将其用于生产工作负荷。 某些功能可能不受支持或者受限。 有关详细信息,请参阅 Microsoft Azure 预览版补充使用条款。
可以通过创建聊天线程 API 上的保留策略在无限期消息保留或在 30 到 90 天之间自动删除两者之间进行选择。 或者,可以选择不对聊天线程设置保留策略。
如果你有严格的合规性需求,建议使用删除聊天线程 API 来删除聊天线程。 在新的保留策略之前创建的任何会话不会受到影响,除非专门更改该会话的策略。
注意
如果意外删除了消息,系统无法恢复它们。 如果在保留策略删除已删除的聊天线程后提交该线程的支持请求,则无法检索该线程。 该线程的相关信息不再可用。 如果需要,请在创建会话后的 30 天内尽快开具支持票证,以便我们可以为你提供帮助。
语音和视频呼叫
Azure 通信服务支持语音和视频通话。
PSTN 通话限制
名称 | 范围 | 限制 |
---|---|---|
默认并发外呼数量 | 每个号码 | 2 |
注意
并发拨入呼叫没有限制。 还可以向 Azure 支持部门提交请求,请求调高并发拨出呼叫的限制。 我们的审查团队会审查所有请求。
呼叫最大限制
名称 | 限制 |
---|---|
参与者数 | 350 |
呼叫 SDK 流式传输支持
Azure 通信服务呼叫 SDK 支持以下流式传输配置:
限制 | Web | Windows/Android/iOS |
---|---|---|
可同时发送的传出本地数据流的最大数。 | 1 个视频或 1 个屏幕共享 | 1 个视频 + 1 个屏幕共享 |
可同时呈现的传入远程数据流的最大数。 | 9 个视频 + 1 个屏幕共享 | 9 个视频 + 1 个屏幕共享 |
虽然“通话 SDK”不会强制执行这些限制,但如果超出这些限制,用户可能会遇到性能降低的情况。
呼叫 SDK 超时
以下超时适用于 Azure 通信服务呼叫 SDK:
操作 | 超时(以秒为单位) |
---|---|
断开参与者的连接或移除参与者。 | 120 |
在呼叫中添加或删除新模态。 (启动或停止视频或屏幕共享。) | 40 |
呼叫转移操作超时。 | 60 |
一对一呼叫建立超时。 | 85 |
群组通话建立超时。 | 85 |
PSTN 呼叫建立超时。 | 115 |
将一对一呼叫升级到群组通话超时。 | 115 |
采取的操作
有关语音和视频呼叫 SDK 和服务的详细信息,请参阅呼叫 SDK 概述或 SDK 和 API 的已知问题。 你还可以向 Azure 支持部门提交请求,请求调高其中一些限制。 我们的审查团队会审查所有请求。
作业路由器
发送或接收大量请求时,可能会收到 ThrottleLimitExceededException
错误。 此错误表示你将达到服务限制。 请求会失败,直到在一定时间后补充用于处理请求的令牌存储桶。
作业路由器的速率限制
操作 | 范围 | 期限(秒) | 限制(请求数) | 超时(以秒为单位) |
---|---|---|---|---|
常规请求 | 按资源 | 10 | 1,000 | 10 |
采取的操作
如果需要发送超过速率限制的消息量,请发送电子邮件至 acs-ccap@microsoft.com。
Teams 互操作性和 Microsoft Graph
使用 Teams 互操作性方案时,可能会使用 Microsoft Graph API 来创建会议。
通过 Microsoft Graph 提供的每个服务都有不同的限制。 此网页更详细地介绍了服务特定的限制。
采取的操作
实现错误处理时,请使用 HTTP 错误代码 429 检测限制。 失败的响应包含 Retry-After
响应头。 使用 Retry-After
延迟来回退请求。 这是从限制中恢复的最快方法,因为 Microsoft Graph 在客户端受到限制时继续记录资源使用情况。
可以在 Microsoft Graph 文档中找到有关 Microsoft Graph 限制的详细信息。