如何将Azure App Service文件保存至本地内网网络共享位置

前提说明：以下方案均基于Azure与本地内网底层连通已配置完成的基础，所有方案不需要改动现有本地网络共享的权限、配置，不会影响其他无管控权限的现有应用写入操作。

方案1：打通SMB端口后直接通过平台能力挂载共享（优先推荐） #

• 你遇到的端口阻断本质是ASE子网NSG、本地防火墙两侧拦截了SMB协议必需的TCP 445端口，不需要额外搭建中转组件：
  1. 在ASE所在子网绑定的网络安全组中，添加出站允许规则：目标为本地SMB服务器所属IP段，目标端口TCP 445，优先级高于默认拒绝规则
  2. 协调本地网络管理员在SMB服务器侧防火墙、本地网络边界防火墙上，放通ASE子网出口IP段到SMB服务器445端口的入站访问
  3. 进入Linux App Service的「配置-路径映射」页面，添加自定义SMB存储挂载：填写共享地址为//<本地SMB服务器IP>/<共享目录名>，设置容器内挂载路径（如/mnt/onprem-share），填入有共享写入权限的账号凭据，保存后应用会自动重启完成挂载
• 注意事项：不要在应用启动脚本里手动执行mount -t cifs命令挂载，App Service沙箱会在实例重启、扩容时清空自定义挂载配置，使用平台自带的路径映射是官方支持的持久化方案，扩容、重启实例都会自动重新挂载，应用代码不需要做任何修改，直接读写挂载目录下的文件即可。

方案2：本地侧部署轻量HTTP文件中转服务 #

• 如果安全策略不允许跨网直接放行SMB 445端口，可在本地内网与Azure连通的区域部署极轻量的HTTP/HTTPS中转服务，仅使用App Service默认允许出站的80/443端口通信：
  1. 中转服务不需要做文件持久化，核心逻辑仅为：校验请求鉴权信息，接收ASE侧应用POST上传的文件流，直接写入目标内网共享路径
  2. ASE侧应用仅需把原有写共享路径的逻辑，调整为调用中转服务的上传接口传输文件即可，文件落盘走本地服务到共享的原有通路，完全不触碰现有共享配置
  3. 安全层面可给接口加请求签名校验、配置IP白名单仅允许ASE子网调用、开启TLS加密传输，避免未授权访问
• 该方案中转程序逻辑极简，用几十行Go/Python/Node.js代码即可实现，单进程运行内存占用不超过100M，不需要额外采购高配置资源。

方案3：通过Azure混合连接中继SMB访问 #

• 不需要调整跨网防火墙端口规则的情况下，可使用App Service原生支持的混合连接能力打通SMB访问隧道：
  1. 进入App Service的「网络-混合连接」配置页，新建混合连接，设置目标地址为本地SMB服务器IP，目标端口为445
  2. 在本地内网一台能正常访问目标SMB共享、且能连通Azure公网/专线的服务器上安装混合连接代理，使用有共享写入权限的账号运行代理服务
  3. 配置完成后，App Service可通过加密隧道直接访问本地SMB服务的445端口，不需要公网暴露本地服务，也不需要开放跨网SMB端口规则，应用侧可直接通过SMB协议读写共享路径
• 该能力为平台原生集成，隧道流量默认TLS加密，符合多数企业的合规要求。

方案4：异步队列中转（高可靠场景适用） #

• 如果生成的文件体积大、对写入可靠性要求高、不希望应用可用性和本地共享状态耦合，可采用异步架构：
  1. 应用生成文件后先将文件上传到同VNet下的Azure Blob存储，同时向Azure队列存储/服务总线发送一条消息，携带文件的Blob地址、目标共享存储路径
  2. 在本地内网部署一个轻量队列消费程序，持续监听队列消息，收到消息后从Blob下载对应文件，写入目标内网共享路径，写入完成后可删除Blob中的临时文件
• 该方案完全解耦文件生成和写入流程，哪怕本地共享临时故障，消息会持久化在队列中不会丢失，故障恢复后消费程序会自动重试写入，适合生产环境高可靠场景。

选型参考 #

• 无特殊安全限制的情况下优先选方案1，零代码改动、无额外维护成本、文件读写性能最好
• 不允许跨网直接走SMB协议的场景优先选方案2或方案3，维护成本极低，改动量小
• 对写入可靠性要求高、大文件场景优先选方案4

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