这是个特别接地气的问题——不少刚接触架构扩展的朋友都会纠结这点：明明横向扩展要依赖网络，还可能带来延迟，为啥不干脆给单台机器堆硬件？其实从长期业务发展和运维稳定性来看，横向扩展的优势远大于那点网络开销，我来给你掰扯掰扯核心原因：

• 纵向扩展有无法突破的物理天花板
  单台服务器的硬件升级空间是有限的：就算你把CPU堆到顶、内存插满，也架不住业务爆发式增长——比如某天用户量突然翻5倍，单台机器再强也扛不住。而且高端硬件的性价比极低，比如一台16核服务器花3万，升级到64核可能要15万以上，越往上成本越离谱。

• 横向扩展的弹性和容错性是碾压级的
  横向扩展是靠加机器堆能力，你完全可以跟着业务流量动态调整：高峰期加8台机器扛负载，低谷期缩到2台省成本，灵活得很。更重要的是容错——如果其中一台机器挂了，其他节点能立刻接管请求，服务根本不会断。但纵向扩展的话，单台机器就是单点故障，一旦宕机整个服务直接趴窝，风险太高了。

• 网络延迟的问题早就有成熟解法
  你担心的网络延迟确实存在，但现在有一堆方案能把它压到用户感知不到的程度：

  • 用负载均衡器把请求均匀分发，优化路由路径，减少跨节点的无效传输
  • 加缓存层（比如Redis），把高频访问的数据存在靠近应用的地方，避免反复跨节点查数据库
  • 拆成微服务，把相关业务模块放在同一节点，让请求尽量在本地处理，减少跨节点调用
    这些手段组合起来，网络延迟完全不是阻碍。

• 横向扩展天生适配云原生时代
  现在云服务商的弹性伸缩、Docker容器、K8s编排这些工具，都是为横向扩展量身定做的——你可以一键完成机器增减、自动部署、运维监控，全程自动化。而纵向扩展在云环境里升级硬件往往要停机，或者只能选固定配置的实例，灵活性差得不是一点半点。

当然，也不是说纵向扩展完全没用：业务初期用户少的时候，单台服务器足够支撑，这时候用纵向扩展更简单、成本更低。但当业务到了一定规模，或者需要高可用性、弹性能力的时候，横向扩展肯定是更靠谱的选择。

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