负载均衡策略接口的多态设计

在高性能负载均衡器中，支持多种负载均衡策略是一个常见需求。不同的业务场景可能需要不同的策略：轮询（Round Robin）适合无状态服务，最少连接（Least Connections）适合长连接服务，哈希（Hash）适合需要会话保持的场景。

如何在保持高性能的同时，支持灵活的策略切换？本文将深入分析工业级代码中的策略接口多态设计，并用 Rust 进行净室重构演示。

从问题说起：策略的演进

在早期的负载均衡器中，策略通常是硬编码的：

// 伪代码 - 硬编码策略
if (strategy == "round_robin") {
    // 轮询逻辑
} else if (strategy == "least_connections") {
    // 最少连接逻辑
}

这种方式的缺点很明显：

新增策略需要修改核心代码
代码分支越来越多，难以维护
策略之间无法复用代码

工业级解法：接口抽象 + 工厂模式

原始代码中使用了经典的策略模式：

// 策略接口
class IPolicy {
public:
    virtual ~IPolicy() = default;
    virtual IBackend* Next(IAlgorithm* algorithm, bool fastAttempt) = 0;
    virtual void RegisterSuccess() = 0;
    virtual void RegisterFail() = 0;
};

// 策略工厂
class IPolicyFactory {
public:
    virtual THolder<IPolicy> ConstructPolicy(const TStepParams& params) noexcept = 0;
    virtual void FillFeatures(TPolicyFeatures& features) const noexcept = 0;
};

这种设计的核心思想是：

接口抽象：通过 IPolicy 接口定义策略行为
运行时多态：工厂模式在运行时创建具体的策略对象
特性探测：FillFeatures 允许框架查询策略特性，优化行为

权衡分析

优势

开闭原则：新增策略无需修改框架代码
解耦：策略实现与框架代码隔离
灵活配置：可以在运行时切换策略

代价

虚函数开销：每次策略调用都有 vtable 查找
堆分配：工厂模式通常涉及堆分配
间接跳转：代码可读性略有下降

额外的设计智慧：特性查询

原始代码中的 FillFeatures 方法是一个巧妙的设计：

struct TPolicyFeatures {
    bool WantsHash = false;
};

框架可以通过查询策略特性来决定是否传递哈希值，避免不必要的计算。

Rust 净室演示

下面是用 Rust 编写的净室演示，复述了上述设计思想：

#![allow(dead_code)]
#![allow(unused_imports)]

use std::sync::Mutex;

// Policy trait - 对应 C++ 的 IPolicy
trait Policy: Send + Sync {
    fn select_backend(&self, backends: &[Backend], params: &StepParams) -> Option<usize>;
    fn on_success(&self);
    fn on_failure(&self);
    fn requires_hash(&self) -> bool {
        false
    }
}

// 模拟后端服务器
#[derive(Clone)]
struct Backend {
    id: usize,
    weight: usize,
}

// 轮询策略
struct RoundRobinPolicy {
    counter: Mutex<usize>,
}

impl RoundRobinPolicy {
    fn new() -> Self {
        Self { counter: Mutex::new(0) }
    }
}

impl Policy for RoundRobinPolicy {
    fn select_backend(&self, backends: &[Backend], _: &StepParams) -> Option<usize> {
        if backends.is_empty() { return None; }
        let mut counter = self.counter.lock().unwrap();
        let idx = *counter % backends.len();
        *counter += 1;
        Some(idx)
    }
    fn on_success(&self) {}
    fn on_failure(&self) {}
}

// 最少连接策略
struct LeastConnectionsPolicy {
    connections: Mutex<Vec<usize>>,
}

impl LeastConnectionsPolicy {
    fn new(backend_count: usize) -> Self {
        Self { connections: Mutex::new(vec![0; backend_count]) }
    }
}

impl Policy for LeastConnectionsPolicy {
    fn select_backend(&self, backends: &[Backend], _: &StepParams) -> Option<usize> {
        if backends.is_empty() { return None; }
        let conns = self.connections.lock().unwrap();
        conns.iter().enumerate().min_by_key(|(_, &c)| c).map(|(i, _)| i)
    }
    fn on_success(&self) {}
    fn on_failure(&self) {}
    fn requires_hash(&self) -> true { true }
}

// 策略工厂
struct PolicyFactory;

impl PolicyFactory {
    fn create_policy(policy_type: &str, backend_count: usize) -> Box<dyn Policy> {
        match policy_type {
            "round_robin" => Box::new(RoundRobinPolicy::new()),
            "least_connections" => Box::new(LeastConnectionsPolicy::new(backend_count)),
            _ => Box::new(RoundRobinPolicy::new()),
        }
    }
}

fn main() {
    let backends = vec![
        Backend { id: 1, weight: 100 },
        Backend { id: 2, weight: 100 },
    ];
    
    let params = StepParams { attempts: 1, hash: None };
    
    // 使用轮询策略
    let policy = PolicyFactory::create_policy("round_robin", backends.len());
    if let Some(idx) = policy.select_backend(&backends, &params) {
        println!("选择后端: {}", backends[idx].id);
    }
}

总结

本文深入分析了负载均衡策略接口的多态设计，探讨了以下核心权衡：

接口抽象 vs 硬编码：用灵活性换取一定的性能代价
运行时多态 vs 编译时多态：Rust 的 trait object 提供了另一种选择
特性查询：让框架可以优化行为，无需策略实现感知

这种设计模式在大型系统中非常常见，理解其背后的权衡对于设计可扩展的系统至关重要。