Meta 开源了 Rebalancer——一个已在其内部用于资源分配问题超过九年的通用高性能库。比“又多了一个求解器”更值得关注的是它的设计边界：问题如何描述、数据如何存储、算法如何求解，以及结果如何调试，被拆成了相互独立的关注点。
这种拆分对生产系统尤其重要。现实中的分配问题很少保持不变：业务会加入容量限制，基础设施会改变数据规模，算法团队会替换求解策略，值班工程师则需要知道为什么某个对象没有被分配到预期位置。如果这些逻辑都挤在同一层，任何变化都可能演变成一次高风险重构。
分配问题不只是“找一个最小值”
一个典型的分配问题可以抽象为：把一组对象分配给一组目标，同时满足约束，并优化成本或收益。例如：
- 把任务分配给服务器，降低跨机架流量；
- 把分片放到存储节点，兼顾容量与故障域；
- 把员工或机器分配给工作，最小化总成本；
- 在扩缩容后重新布局资源，同时减少迁移量。
真正棘手的部分通常不是目标函数本身，而是几类需求叠加：某些组合被禁止，目标有容量上限，现有分配应尽量保留，不同约束还可能有软硬之分。
Rebalancer 的公开介绍强调了四个独立层面：
- 问题定义：对象、候选目标、成本和约束如何表达；
- 内存表示：如何高效保存大规模问题；
- 求解过程：使用什么算法寻找可行或更优的分配；
- 调试能力：如何解释输入、约束冲突与输出结果。
这意味着业务代码不必直接绑定某一种内部数据结构或算法。即使团队后续替换求解器，问题定义和诊断工具仍有机会保持稳定。
为什么分层会直接影响性能和可维护性
许多资源分配系统最初都是一个函数：读取对象，构造二维成本矩阵，调用算法，然后写回结果。小规模时这样足够直接；规模扩大后，问题会逐渐暴露。
如果只有少量合法候选关系，完整的二维矩阵会浪费大量内存。若把稀疏存储方式写死在业务模型中，求解器又会被迫理解业务对象。再进一步，如果调试日志只能输出内部编号，运维人员很难回答“为什么分片 A 被迁移到节点 C”。
更稳妥的边界是：
- 业务层生成与领域相关的候选关系和约束；
- 存储层负责紧凑表示、索引与遍历；
- 求解层只处理规范化后的问题；
- 调试层保留内部编号到业务实体的映射，并验证结果。
这里不应仅把“高性能”理解成算法复杂度。内存布局、候选边数量、对象创建成本以及调试数据是否能按需启用，都会影响大型实例的吞吐和延迟。具体采用何种结构，应以 Rebalancer 的实际接口和项目文档为准，而不是假设它使用某一种固定实现。
一个可运行的微型分层示例
下面的 Python 程序不是 Rebalancer API，而是一个可以直接运行的教学示例，用来展示同样的关注点分离。它把问题定义、求解和结果验证拆开；为保持代码短小，求解器使用全排列穷举，因此只适合很小的输入。
将以下内容保存为 assignment_demo.py：
from dataclasses import dataclass
from itertools import permutations
from math import inf
from typing import Dict, List, Tuple
@dataclass(frozen=True)
class AssignmentProblem:
workers: List[str]
jobs: List[str]
# 未出现的 worker-job 组合视为禁止分配
costs: Dict[Tuple[str, str], int]
def solve(problem: AssignmentProblem) -> Dict[str, str]:
if len(problem.workers) != len(problem.jobs):
raise ValueError("This demo requires equal numbers of workers and jobs")
best_cost = inf
best_assignment: Dict[str, str] = {}
for ordered_jobs in permutations(problem.jobs):
candidate = dict(zip(problem.workers, ordered_jobs))
try:
total = sum(
problem.costs[(worker, job)]
for worker, job in candidate.items()
)
except KeyError:
# 缺失的边代表该组合不可行
continue
if total < best_cost:
best_cost = total
best_assignment = candidate
if not best_assignment:
raise RuntimeError("No feasible assignment")
return best_assignment
def debug_result(
problem: AssignmentProblem,
assignment: Dict[str, str],
) -> None:
if set(assignment) != set(problem.workers):
raise AssertionError("Some workers are missing")
if len(set(assignment.values())) != len(problem.jobs):
raise AssertionError("A job was assigned more than once")
total = 0
for worker in problem.workers:
job = assignment[worker]
cost = problem.costs[(worker, job)]
total += cost
print(f"{worker} -> {job}, cost={cost}")
print(f"total_cost={total}")
def main() -> None:
problem = AssignmentProblem(
workers=["alice", "bob", "carol"],
jobs=["api", "database", "queue"],
costs={
("alice", "api"): 4,
("alice", "database"): 8,
("alice", "queue"): 6,
("bob", "api"): 7,
("bob", "database"): 3,
# bob 不允许负责 queue，因此不提供对应成本
("carol", "api"): 5,
("carol", "database"): 6,
("carol", "queue"): 2,
},
)
assignment = solve(problem)
debug_result(problem, assignment)
if __name__ == "__main__":
main()
运行：
python assignment_demo.py
预期结果为：
alice -> api, cost=4
bob -> database, cost=3
carol -> queue, cost=2
total_cost=9
这个例子刻意让 AssignmentProblem 不知道算法细节，让 solve() 不包含业务名称解释，再由 debug_result() 验证一对一约束并输出可读结果。接入真正的高性能库时，可以保留问题构造和验证接口，只替换 solve() 的内部实现。
从演示代码走向生产系统
生产环境中的接入重点不是立即把所有规则塞进求解器，而是先确定清晰的模型边界：
- 区分硬约束与软成本：容量或安全限制通常不能违反；迁移次数、网络距离等指标可能适合作为成本；
- 避免无条件生成完整矩阵：如果每个对象只有少数合法目标，应优先评估稀疏候选表示；
- 保存稳定标识：内部整数索引需要能映射回分片、机器、租户等业务实体；
- 单独验证解：不要仅因为求解器返回成功就直接执行迁移，应再次检查容量、唯一性和禁止关系；
- 记录变更代价：重新平衡可能得到更优的静态布局，却造成大量数据搬迁或缓存失效；
- 准备不可行诊断：无解本身不够，系统还需要定位冲突约束和异常输入。
Rebalancer 的开源价值不仅在于提供一种求解能力，也在于展示了分配系统应如何组织边界。评估是否采用时，应使用真实规模和真实约束做基准测试，并重点检查内存占用、求解时延、解的稳定性、不可行问题的可诊断性，以及与现有执行流程的集成成本。