2021-04-22 扩容是稳定性保障终极大招？

起因

前文提到我们在活动期间系统“挂了”20分钟，为了保障下次活动不“挂”，在产品和研发的指导下对应用系统进行扩容，扩容数量先按当前资源的一倍靠齐。

扩容真的能解决问题吗？

假设我们都是不差钱，不需要考虑roi
扩容在某些场景下非常有效，但在某些场景下就是就是杯水车薪。
那在那些场景下有效呢？

• 代码的响应时间比较低，最多不超过200ms，且并发请求远大于CPU数量时，增加CPU，有效。
• 线程在没有挂起，阻塞，死锁的情况下，线程数量不够，通过增加线程数量（本机内存足够的情况下，调整参数增加线程；横向增加实例），有效。
• 在没有高并发且full gc ，超大结果集情况下，增加内存可以缓解内存溢出、swap交换，有效。

有效/无效是有条件限制的，不是砸钱/机器就可以解决问题的

那什么时候才无效呢？
很简单和有效条件相反就是无效。举例子

• 曾经某系统做活动，某个URL运行时间在1-2秒间，加了96个CPU，不到5分钟使用率100% ，换言之单CPU的tps为 1的，就不要加CPU了。
• 不是机器越多越好的，要看系统架构的，Oracle rac为例，128个节点。。。。这种架构甚少出现，512g内存一个实例，在Oracle的内存管理中是带来负担的，而不是优势。当然我举得例子是有状态架构，可能不适合。我们的应用都是无状态的，是不是就多多益善呢？也不一定是，首先说，应用无限扩容后，发现zookeeper没有更上，结果在注册时把zookeeper搞挂了，还有如果你后台是一个集中式数据库，那你就把压力压到数据库上了，这时数据库挂了，系统也挂了。
  类似盲目扩容带来的负面影响比比皆是。

怎么科学扩容？

• 整体考虑，不要头痛医头，脚痛医脚。从前到后考虑整体资源搭配。除了应用服务器还要考虑db连接数，网络，安全设备这些因素。
• 压测容量输出，指导机器配置，这里的压测指的是综合场景压测，全链路压测，单个接口压测指导机器配置意义不大。
• 曾经考虑过通过rps，响应时间，CPU，线程数，full gc 多个纬度结合起来用数学模型推算我们的容量，尝试计算容量和计算资源关系。

最后

这里没有说太多的公式和原理，只有一些经验之谈，希望有一天真的可以把这些经验变成公式，模型科学指导我们扩容。