使用托管身份连接Azure Service Bus遇异常及权限问题排查

咱们一步步来拆解你遇到的这两个问题，先从第一个说起：

第一个异常：com.google.gson.JsonSyntaxException: java.lang.NumberFormatException #

这个问题是旧版本Azure Service Bus Java SDK的已知bug——早期版本的ManagedServiceIdentityTokenProvider在解析MSI令牌的过期时间时，默认用Gson处理数字时间戳，但某些环境下返回的过期时间是日期字符串格式（比如你遇到的"10/10/2020 6:50:38 AM +00:00"），导致Gson解析失败抛出异常。

你升级到SDK 3.2.0后异常消失，这完全正确，微软在后续版本修复了这个时间格式解析的兼容问题。建议后续尽量保持SDK版本在稳定的最新版，避免这类旧bug。

第二个异常：java.lang.RuntimeException: java.net.SocketException: Permission denied: connect #

虽然你给WebJob分配了Owner角色，但这个问题大概率和权限类型不匹配或者网络限制有关，咱们逐个排查：

1. 先修正角色分配：管理角色≠数据角色 #

Owner/Contributor属于管理平面角色，只能用来创建、删除Service Bus这类资源管理操作，但接收消息属于数据平面操作，需要专门的Service Bus数据角色：

• 如果你只需要接收消息，给托管身份分配Azure Service Bus Data Receiver角色
• 如果需要完整的数据操作（收发、管理队列等），分配Azure Service Bus Data Owner角色

管理角色无法授权数据平面的操作，这是很多人容易踩的坑，先把角色换成对应的数据角色试试。

2. 检查网络连通性 #

这个错误提示是“连接被拒绝”，大概率是WebJob无法访问Service Bus的端点，或者无法访问MSI元数据端点：

• 如果WebJob部署在App Service中：
  • 查看App Service的出站IP地址（在App Service的“属性”页面可以找到），确认这些IP已经添加到Service Bus的防火墙允许列表中；
  • 如果App Service启用了VNet集成，需要在Service Bus的网络设置中允许对应的VNet访问；
  • 测试阶段可以临时把Service Bus的防火墙设置为“允许所有网络”，排除网络限制的问题。
• 如果是本地测试WebJob：
  • 确保你已经用Azure CLI登录（az login），并且本地环境能访问MSI元数据端点http://169.254.169.254/metadata/identity/oauth2/token（本地测试时SDK会自动用Azure CLI的身份）。

3. 检查MSI配置和SDK代码 #

• 如果用的是用户分配的托管身份，需要在创建TokenProvider时指定MSI的Client ID：

  String userAssignedMsiClientId = "你的用户分配MSI的Client ID";
  TokenProvider tokenProvider = TokenProvider.createManagedServiceIdentityTokenProvider(userAssignedMsiClientId);
  ClientSettings clientSettings = new ClientSettings(tokenProvider);
  // 后续创建Receiver的代码不变
  ClientFactory.createMessageReceiverFromEntityPathAsync(namespace, queueName, clientSettings, ReceiveMode.RECEIVEANDDELETE).get();
  

• 如果是系统分配的托管身份，代码不需要额外参数，但要确认WebJob所在的App Service已经开启了“系统分配的托管身份”。

4. 查看详细日志 #

在WebJob的日志中找更详细的错误栈，比如是无法连接到Service Bus的端口（默认5671/443），还是无法获取MSI令牌，这能帮你更快定位问题。

内容的提问来源于stack exchange，提问作者Shreyanshi