在网络代理服务运行过程中，路由规则经常需要根据后端节点状态或业务策略进行调整。如果每次变更都重启进程，不仅会断开已有连接，还会带来短暂的请求失败。使用Ruby语言监听配置文件变化并动态重载路由表，可以让代理服务在无需停机的情况下生效新规则，这种能力被称为热更新。下面从实现机制到工程细节逐步展开。
文件变化监听的基本原理与Ruby实现
文件系统事件监听的本质是操作系统向应用层通知目录或文件的写、删、改动作。Linux下通常基于inotify机制，macOS使用FSEvents，Windows则有ReadDirectoryChangesW。Ruby生态中的listen库对这些系统调用做了统一封装，能够在不同平台以相同API接收事件，避免开发者自己处理底层差异。
在代理服务启动时，我们创建一个监听实例，把路由配置文件所在目录交给它，并注册回调。当文件被保存，回调会被触发，此时不应直接在回调里做复杂加载，而应通过队列交给独立线程处理，防止阻塞事件循环。以下示例展示了最基本的监听代码：
require 'listen'
path = '/etc/proxy/routes.yml'
listener = Listen.to(File.dirname(path)) do |modified, added, removed|
if (modified + added).include?(path)
puts 'routes file changed, reload needed'
end
end
listener.start
sleep
上面的代码仅打印提示，实际项目中要把“重新加载”动作异步化。需要注意编辑器保存文件时可能产生临时文件或多次写入，listen本身有防抖合并能力，但仍建议在回调中判断真实目标路径，并忽略编辑器产生的交换文件，否则会出现重复加载。
另外，监听目录比监听单个文件更可靠，因为某些编辑器采用先删后建的方式保存，单文件句柄会失效。监听整个目录并在回调中过滤路径，是生产环境常用做法。结合日志记录每次事件，有助于排查规则未生效的问题。
路由规则的安全重载与线程模型
热更新最核心的风险在于旧请求还在使用旧路由，而新请求要用新路由。如果直接覆盖全局变量，可能导致部分转发逻辑读到半初始化状态。正确方式是使用双缓冲：在内存中保留两份路由表，加载完成后通过原子赋值切换引用，Ruby的常量或带互斥锁的实例变量都能实现这一点。
下面代码演示了用互斥锁保护切换过程，并在加载失败时保留旧规则。我们约定路由文件为YAML格式，包含后端地址与匹配前缀：
require 'yaml'
require 'mutex_m'
class Router
def initialize(file)
@file = file
@lock = Mutex.new
@routes = load_file
end
def reload
new_routes = load_file
@lock.synchronize do
@routes = new_routes
end
puts 'routes reloaded safely'
rescue StandardError => e
puts "reload failed: #{e.message}, keep old routes"
end
def match(path)
@lock.synchronize do
@routes.find { |r| path.start_with?(r['prefix']) }
end
end
private
def load_file
data = YAML.load_file(@file)
raise 'empty routes' if data.nil? || data.empty?
data
end
end
在match方法中加锁读取，虽然会带来微小性能开销，但保证了不会读到切换瞬间的不一致对象。对于读多写少场景，也可以改用Concurrent::AtomicReference存放路由数组，读操作完全无锁，仅在写时替换引用，性能更优。
还要注意文件解析异常。YAML缩进错误会抛出Psych::SyntaxError，若此时清空了路由，代理将拒绝所有请求。因此加载函数必须在校验通过后才返回新对象，任何异常都应向上抛出并由reload捕获，确保旧表继续服务。这就是热更新区别于冷启动的关键容错设计。
与进程信号及完整集成示例
除了文件监听，很多运维系统习惯向进程发送SIGHUP触发重载。我们可以同时支持两种方式：listen自动发现变更，信号作为手动刷新手段。在Ruby里用Signal.trap注册处理器，把同一个reload方法挂接上去，既灵活又符合Unix惯例。
下面给出一个将监听、信号、路由结合的精简服务骨架。它启动后既能被文件改动驱动，也能通过kill -HUP刷新，且每次重载打印版本号便于追踪：
require 'listen'
require 'yaml'
class Proxy
def initialize(route_file)
@route_file = route_file
@routes = load
@version = 0
end
def start
Signal.trap('HUP') { reload }
Listen.to(File.dirname(@route_file)) do |m, a, _r|
reload if (m + a).include?(@route_file)
end.start
puts 'proxy running, version 0'
sleep
end
def reload
old = @routes
@routes = load
@version += 1
puts "reloaded to version #{@version}"
rescue StandardError => e
@routes = old
puts "reload error: #{e.message}"
end
def load
YAML.load_file(@route_file)
end
end
Proxy.new('/etc/proxy/routes.yml').start
这个示例中reload方法先保存旧值再赋值，异常时回退，符合前面提到的安全原则。实际代理转发时，每次请求调用@routes最新内容即可，由于Ruby的赋值原子性，不会看到部分更新的哈希。
在容器环境里，可以把路由文件通过ConfigMap挂载，修改后Kubernetes刷新文件内容，listen捕获到变化自动重载，无需重启Pod。相比Nginx的reload需要主进程重开worker，Ruby方案在单进程内完成，资源占用更低，也更容易在已有业务进程中嵌入路由热更新能力，适合中小规模自定义代理场景。