Hangfire前端负载均衡及多节点部署可行性咨询

Hangfire 前端面板的负载均衡可行性 #

• 完全可以实现Hangfire前端的负载均衡，没有架构层面的阻碍。
  • Hangfire自带的前端Dashboard本质是嵌入在ASP.NET应用内的路由组件，本身完全无状态，你只需要把现有负载均衡设备上，对应该Hangfire路由的路径（默认是/hangfire）的转发规则对齐到两台后端IIS节点即可，不需要额外拆分独立站点部署。
  • 因为所有Dashboard展示的任务数据、执行日志都来自统一配置的共享Hangfire存储（比如SQL Server、Redis这类可跨节点访问的存储介质），不管用户的访问请求被负载均衡转发到哪台IIS节点，拉取的都是同一份存储里的数据，不会出现界面数据不一致、展示错乱的问题。
  • 注意要把Dashboard的授权逻辑和存储配置保持跨节点一致，避免因为负载均衡的跨节点转发，触发权限校验失效的问题。

双IIS节点运行Hangfire服务、Worker独立部署的可行性 #

• 这种拆分式部署是Hangfire原生支持的标准架构，完全可以落地。
  • 首先两台IIS节点同时运行Hangfire实例没有问题：只要两个节点的应用配置的是同一个共享Hangfire存储，Hangfire就会依托存储层的分布式锁机制做任务抢占式分配，不会出现同一个任务被多个节点重复执行的问题。
  • 如果你不希望IIS节点本身承担后台任务的执行负载，完全可以在这两个节点的应用初始化逻辑里，把Hangfire Server的工作线程数设为0，让这两个节点只负责提供Web请求处理、Hangfire Dashboard访问、以及后台任务的投递入口，不实际执行任何后台任务。对应的配置方式：

    // 共享存储连接配置和实际Worker节点完全一致
    GlobalConfiguration.Configuration.UseSqlServerStorage("你的共享存储连接串");
    // 挂载Dashboard
    app.UseHangfireDashboard("/hangfire");
    // 启动Hangfire Server但不分配工作线程
    app.UseHangfireServer(new BackgroundJobServerOptions {
        WorkerCount = 0
    });
    

  • 把Worker部署在额外独立服务器上的逻辑也很简单：你只需要在新服务器上部署一个无界面的Hangfire Server程序（可以是控制台应用、Windows服务形式），将它的Hangfire存储连接配置和两台IIS节点保持完全一致，程序启动后就会自动加入整个Hangfire的执行集群，自动从共享存储中拉取待执行的任务完成处理。
  • 这种拆分部署的实际收益很明确：可以实现Web请求处理负载和后台任务执行负载的资源隔离，避免耗时较长的后台任务占用IIS工作进程资源，影响正常Web业务的响应速度；同时可以根据后台任务的量级，灵活增减Worker节点数量，不需要改动前端Web节点的任何配置。

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