架构误区系列 1：扩容解决容量问题

大促，或者业务增长，造成短时流量激增的场景下，是否通过扩容就可以解决问题。

首先，这里要考虑不同资源的容量问题：网络资源、计算资源、存储资源。

网络资源一般不是太会成为瓶颈。外网资源不够，服务就大量被拒绝了。如果外网资源不够，不论是云服务还是自建 IDC，都需要重新申请扩容，这个时间会比较慢。内网资源不够的话，如果是自建服务的话需要升级内部的交换机，也比较耗时。

计算资源资源不够，一般通过扩容解决。但是，如果扩容的姿势不对，极端场景下也会造成扩容无效甚至越扩容量越小的情况。对于离线计算，一般直接扩容是 ok 的。但是对于在线服务的集群，我们需要考虑多方面因素。首先，我们要先确定目前计算集群的状态。如果当前集群的状态是 ok 的，入口的流量相比集群容量差距不大，直接扩容问题也不大。如果集群的状态目前大部分机器都处于线程池满的状态，也就是入口流量远大于了集群容量，集群处于一个很不健康甚至区域恶化的状态下。这个时候，我们首先需要通过限流保护集群的健康度，保证集群处于恢复状态时，再进行扩容。否则，很大可能性增加的机器瞬间也被流量打满不可服务，从而引起雪崩。

存储资源不够，这个就会更复杂一点。首先，要分析数据的特性是什么。如果是流水型的交易数据，同时修改比例较小的场景。通过增加分库，并采用双读迁移存量数据是可行的。如果是读多写少的状态型数据，扩分库一般不会带来多大的改善。这种类型的数据需要事先做缓存化处理、或者部署读写分离的架构。对于瞬间流量的暴增，无轮是加缓存还是扩库都不会有太大的改善空间。加缓存在混存冷启动的时候数据穿透对 DB 的压力还是不能减少。扩库数据迁移或者双读造成读写压力也不会对原库的性能带来改善。