任务分配带来的复杂度递增：从单机到多任务分配器集群

当单机性能撑不住业务量时，最直观的思路是”加机器”，但从1台服务器变成2台服务器这一步，架构复杂度就已经明显跳升了，而且这种复杂度会随着继续加机器而持续累积、并非线性增长。从1台到2台时，首先要新增一个任务分配器（可能是硬件网络设备如F5/交换机，也可能是软件负载均衡如LVS、Nginx、HAProxy，或者自研系统），选择合适的任务分配器本身就要综合权衡性能、成本、可维护性、可用性；其次任务分配器和业务服务器之间要建立连接并管理连接（连接建立、连接检测、连接中断后如何处理）；最后任务分配器要决定用什么分配算法（轮询、按权重、还是按负载分配，按负载分配又要求业务服务器能主动上报自己的状态）。假设单台服务器每秒能处理5000次请求，理论上2台能撑到10000次（实际打8折约8000次），但如果业务量继续增长到每秒10万次这个量级，单纯堆业务服务器数量到25台并不够——因为随着业务服务器数量增加，任务分配器自己会先撑不住变成新的瓶颈，这时任务分配器本身也要从1台扩展成多台。这一步带来的复杂度比”1台任务分配器连多台业务服务器”要高出一个量级：多台任务分配器意味着要先把不同用户分配到不同的任务分配器上（常见手段有DNS轮询、智能DNS、CDN、GSLB全局负载均衡），任务分配器和业务服务器之间的连接关系也从简单的”一对多”变成了”多对多”的网状结构，机器数量、状态管理、故障处理的复杂度都随之大幅上升。这个演进过程说明：”加机器”这件事本身不是线性变复杂的——每一次跨越一个量级的扩容，都可能触发架构层面新的一轮结构性调整，而不只是简单地把原有架构复制粘贴几份。

结构图：

flowchart TB
  A["单台服务器<br/>约5000次请求/秒"]
  A --> B["2台服务器 + 1个任务分配器<br/>新增：分配器选型/连接管理/分配算法<br/>理论约10000次/秒(实际约8000)"]
  B --> C["业务量增至10万次/秒<br/>⚠️单任务分配器自身成为新瓶颈"]
  C --> D["多台业务服务器(约25台) + 多台任务分配器(约5台)<br/>新增：用户分配(DNS轮询/智能DNS/CDN/GSLB)<br/>连接关系从一对多变为多对多网状结构"]