如何配置带Service Bus触发器的Node.js WebJob

注意：WebJobs SDK官方提供的Service Bus触发扩展仅面向.NET运行时，Node.js环境无法直接使用声明式绑定能力，可通过Service Bus官方SDK实现常驻消息监听，达到和Azure Functions Service Bus触发器完全一致的运行效果。

前置准备 #

• 已创建支持Node.js 16+ LTS版本的Azure App Service实例
• 已创建Azure Service Bus命名空间，提前建好需要监听的队列/主题及订阅，拿到具备消息监听、处理权限的连接字符串
• 本地安装匹配版本的Node.js开发环境

本地开发消息监听逻辑 #

1. 初始化项目
   新建空白项目文件夹，在文件夹内执行以下命令初始化项目、安装依赖：

   npm init -y
   npm install @azure/service-bus
   

2. 编写监听入口代码
   新建index.js作为核心逻辑文件，写入以下基础监听代码，业务逻辑可直接替换对应位置：

   const { ServiceBusClient } = require("@azure/service-bus");
   
   // 所有配置从环境变量读取，禁止硬编码敏感信息
   const connectionString = process.env.SERVICEBUS_CONNECTION_STRING;
   const queueName = process.env.SERVICEBUS_QUEUE_NAME;
   // 若监听主题订阅，替换为以下两行配置，同时修改接收器初始化逻辑
   // const topicName = process.env.SERVICEBUS_TOPIC_NAME;
   // const subscriptionName = process.env.SERVICEBUS_SUBSCRIPTION_NAME;
   
   async function startListener() {
     const sbClient = new ServiceBusClient(connectionString);
     // 初始化消息接收器，使用peekLock模式保证消息可靠性
     const receiver = sbClient.createReceiver(queueName, {
       receiveMode: "peekLock",
       maxConcurrentCalls: 5 // 根据业务负载调整并发处理数
     });
   
     console.log("Service Bus listener started, waiting for incoming messages...");
   
     // 注册消息处理回调
     receiver.subscribe({
       processMessage: async (message) => {
         try {
           // 替换为实际业务处理逻辑
           console.log("Received message content:", message.body);
           // peekLock模式下处理完成后SDK会自动确认消息，无需手动调用complete
         } catch (processErr) {
           console.error("Message process failed:", processErr);
           // 处理失败时放弃消息，使其重新入队等待重试
           await receiver.abandonMessage(message);
           // 若确认消息无法处理，可调用deadLetterMessage移入死信队列
         }
       },
       processError: async (err) => {
         console.error("Listener runtime error:", err);
       }
     });
   
     // 监听进程退出信号，优雅关闭连接
     const handleShutdown = async () => {
       await receiver.close();
       await sbClient.close();
       process.exit(0);
     };
     process.on("SIGINT", handleShutdown);
     process.on("SIGTERM", handleShutdown);
   }
   
   startListener().catch((startErr) => {
     console.error("Listener startup failed:", startErr);
     process.exit(1);
   });
   

3. 编写WebJob启动脚本
   在项目根目录新建run.cmd文件，写入启动命令，Azure WebJob部署后会自动识别该脚本作为启动入口：

   node index.js
   

4. 本地验证
   本地临时配置环境变量填入Service Bus连接字符串、队列名，执行node index.js启动服务，向对应队列发送测试消息，确认逻辑正常处理后再部署。

部署配置步骤 #

1. 项目打包
   将项目所有文件（包含package.json、index.js、run.cmd、node_modules目录）打包为zip压缩包，注意不要在压缩包内嵌套额外的父文件夹，保证打开压缩包根目录就能直接看到run.cmd文件。
2. 创建连续型WebJob
   进入Azure门户对应App Service实例，左侧菜单找到「WebJobs」选项点击添加：
   • 名称：自定义WebJob标识名称
   • 文件上传：选择本地打好的zip包
   • 类型：必须选择「连续」类型，手动/触发类型无法实现常驻监听效果
   • 规模：根据业务需求选择，单实例部署可避免多实例重复消费消息
     确认后提交，WebJob上传完成后会自动启动。
3. 应用参数配置
   回到App Service「配置」-「应用程序设置」页面，添加以下必填配置项：
   • SERVICEBUS_CONNECTION_STRING：值为Service Bus的访问连接字符串
   • SERVICEBUS_QUEUE_NAME：值为待监听的队列名称，若使用主题订阅则替换为对应主题名、订阅名的配置项
     额外建议配置以下参数保证服务稳定：
   • 打开「常规设置」中的Always On开关，避免App Service空闲时自动卸载进程导致监听中断
   • 添加配置项WEBJOBS_IDLE_TIMEOUT，值设为3600（单位秒），防止WebJob因长时间无控制台输出被判定为空闲回收

运维说明 #

• 日志查看：在WebJob列表点击对应作业的「日志」按钮，即可查看所有控制台输出、运行报错信息，也可自行对接Application Insights实现全链路监控
• 重试策略：peekLock模式下消息处理失败未被确认时，会按照队列配置的重试策略自动重试，超过最大重试次数的消息会自动进入死信队列，可额外添加死信队列监听逻辑处理异常消息
• 并发调整：通过接收器初始化时的maxConcurrentCalls参数调整单实例并发处理的消息数量，避免并发过高打垮下游服务

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