何时选择horizontal scaling与vertical scaling？适用场景及替代扩容方案咨询

两类扩容方案的适用决策场景 #

优先选垂直扩容（单台机器升配置）的场景 #

• 业务是单实例绑定型负载：比如未做分布式改造的单体业务、重度依赖本地缓存的单点服务，横向加节点没法分摊压力，直接升CPU/内存/磁盘的收益最高
• 短期应急扩容需求：比如临时活动只需要扛1~2天的峰值流量，升级服务器配置的操作只要几分钟，远低于适配分布式架构的改造成本
• 核心数据库类业务：暂时扛不住压力但又不想搞分库分表的场景，垂直升级能避免跨节点事务、数据一致性等额外问题，性能提升没有额外副作用
• 团队缺乏分布式运维能力：垂直扩容不需要改代码、加负载均衡、适配多节点监控，基本不会引入额外的运维负担

优先选水平扩容（加机器节点）的场景 #

• 负载已经超过单台物理机的性能上限：比如当前云厂商最高配置的服务器都扛不住日常访问量，只能靠多节点分摊压力
• 核心业务要求高可用无单点：比如支付、用户登录这类不能停的服务，多节点冗余能避免单点故障，单节点异常时流量直接切到其他节点即可
• 流量波动极大的业务：比如直播、电商大促类场景，水平扩容支持按需弹性扩缩容，闲时缩节点降成本，忙时加节点扛流量，不需要长期持有高配置服务器
• 业务本身是无状态设计：比如API网关、静态资源服务，本身不存储本地数据，新增节点直接就能承接流量，改造成本几乎为零

其他可替代的扩容方案 #

很多时候不需要动硬件扩容，先做架构/逻辑层面的优化就能解决问题，常见方案如下：

• 代码与架构性能优化：优化慢SQL、同步逻辑改异步、热点请求加本地/分布式缓存，大部分场景下能带来数倍到数十倍的性能提升，完全不需要扩容
• 数据库读写分离：把读请求和写请求拆分到不同实例，主库扛写流量，多个从库扛读流量，不用改核心业务逻辑也不用分库分表，就能支撑数倍的读负载
• 流量削峰：针对订单提交、消息通知这类异步可延迟的场景，引入消息队列把突增的请求缓存下来慢慢消费，不需要扩容服务就能扛住数倍的突增流量
• CDN/边缘计算：把静态资源、边缘计算逻辑放到离用户更近的边缘节点，不用扩容中心服务就能承接大部分用户访问请求，还能降低访问延迟

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