服务扩容可能引入的负面问题及解决方法

1.背景

为了让复杂的业务变得简单化、模块化，代码具有可伸缩性（Scalability）、可维护性等，集中式的功能模块开始走向服务化；
服务化的具体实现是将一个个功能以一个相对“单一”的组件（独立）部署运行。服务之间通过网络通信完成调用；
服务不可能独立存在，服务之间存在必不可少的依赖关系。
当针对一个依赖(调用)链中的一个服务进行横向扩容时，一定要考虑全面，否则一个瓶颈的解决可能引入另外一个瓶颈问题；

2.找出瓶颈点

3.扩容注意事项

这里假设一个场景：
假设我们发现了瓶颈点是服务B的处理能力低

除了优化代码外，立竿见影的做法是对服务B进行加机器多部署。
自然这样的扩容，使得B服务整体的吞吐量上来了。

3.1 横向和纵向“同比例”扩容

如果B服务需要使用大量的短连接和Redis进行通信，那么可能在对B服务进行翻倍（甚至翻几倍）扩容的情况下，
造成redis服务能力（比如：连接数不够用）不能与之匹配了。
因此在对B服务扩容的同时，要验证下redis服务能否跟得上，如果不能，那么就需要“同比例”扩容。

3.2纵向“同比例”扩容：

如果B服务扩容后，C服务可能不够用，那么也需要扩容；

3.3 让“扩容”停止扩散

如果B服务扩容后，C服务处理能力可能不匹配，那么也需要扩容，而C服务扩容后，mysql和D服务也可能要扩容。 这样是不是存在B服务的基础服务以及下游服务都需要扩容呢？ 我们的一开始的瓶颈点是B服务处理能力低，因此对B单独进行扩容，同时对B依赖的基础服务进行了同比例扩容； 经过此轮扩容，整个服务链流程是应该能够达到预期的。因此没必要再对B的下游服务进行扩容。 真正需要做的是，B对C的调用进行限流或者C对B进行限流以达到过载保护；