ASP.NET类Azure Web App与WCF类Azure Web App通信问题咨询

一、两个Azure Web App之间的常用通信方式 #

• 直接调用WCF公开的服务端点：若WCF应用已暴露可访问的服务地址，ASP.NET应用直接通过WCF客户端代理调用即可，不需要额外开发适配层
• 借助Azure内置服务间接通信：如有异步解耦需求，可使用Azure队列存储、服务总线队列/主题做消息中转，适合不需要实时返回结果的场景
• VNet集成内网调用：两个应用都开启同VNet的集成后，走内网私有地址通信，流量不需要走公网，安全性和延迟表现更好

二、是否需要专门搭建通信通道 #

• 普通业务场景不需要：如果对安全性、延迟没有极致要求，直接调用WCF公开的公网端点即可，不需要额外搭建独立通道
• 高安全/低延迟场景推荐配置VNet集成：仅需要在两个Web App的网络配置中开启同VNet的集成，不需要单独部署虚拟机、网关等额外资源，配置成本极低

三、是否需要将NET TCP协议替换为HTTP #

注意：Azure Windows 托管计划的Web App目前已原生支持NET TCP协议，不需要强制切换为HTTP，分场景说明如下

• 若使用Windows操作系统的App Service计划：不需要替换协议，只需要在WCF应用的配置中启用NET TCP绑定，同时在Azure门户的Web App配置>应用程序设置中添加WEBSITE_LOAD_CERTIFICATES（如有证书验证需求）、确认协议绑定配置正确即可沿用原有NET TCP协议
• 若使用Linux操作系统的App Service计划：由于Linux环境下Azure Web App默认不支持NET TCP协议，该场景下需要将WCF的绑定改为BasicHttpBinding、WSHttpBinding等HTTP类绑定，或者切换为Windows托管计划
• 额外提示：即使沿用NET TCP协议，也需要使用Azure Web App允许的固定端口，不能自定义任意端口，公网可访问的NET TCP端口固定为808/8080，对应HTTP/HTTPS的80/443逻辑

四、迁移后可能出现的常见问题 #

• 协议端口不匹配：本地IIS可自定义NET TCP端口，Azure Web App有固定端口限制，容易出现连接超时错误
• 安全策略拦截：默认Azure Web App的防火墙可能拦截非HTTP协议的入站请求，需要提前在配置中开启对应协议的支持
• 证书验证失败：如果WCF的NET TCP绑定使用了自签名证书或者私有CA证书，Azure Web App的默认信任根不包含该证书，会抛出验证错误
• 实例间通信异常：如果WCF应用开启了多实例横向扩展，未开启会话亲和性的话，NET TCP的长连接可能在实例漂移时断开
• 带宽限流：免费/基础层级的App Service计划有带宽上限，大流量的NET TCP通信可能触发限流导致请求失败

五、重点注意事项 #

• 优先确认托管计划的操作系统类型：如果要沿用NET TCP协议，必须选择Windows版的App Service计划，Linux和容器部署的Web App不支持NET TCP
• 安全配置优化：如果走公网调用，建议给两个应用都开启传输层加密，同时在WCF端配置IP限制，只允许ASP.NET应用的出站IP访问服务端点；如果走VNet内网调用，不需要配置公网访问权限，安全性更高
• 绑定配置适配：迁移时不要直接照搬本地IIS的WCF配置，需要将端点地址改为Azure Web App的实际域名，端口修改为Azure允许的NET TCP端口
• 测试验证优先级：迁移后先测试单实例场景下的通信是否正常，再开启多实例扩展，同时测试长连接的稳定性、超时时间配置是否符合业务需求
• 日志排查配置：提前开启两个Web App的诊断日志、应用程序日志，出现通信问题时可以直接通过日志查看连接失败的具体原因，比如是网络不通、证书错误还是协议不匹配

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