微服务架构开发实战：微服务的高级主题，自动扩展的常见模式

自动扩展的常见模式

本节将介绍自动扩展的常见模式，以方便读者识别哪些场景下应使用哪种自动扩展策略。

自动扩展的不同级别

自动扩展可应用于应用程序级别或基础架构级别。简而言之，应用程序扩展只是通过复制应用程序二进制文件来扩展，而基础架构扩展则是复制整个虚拟机，包括应用程序二进制文件。

1.应用程序级别的自动扩展

在应用程序级别的自动扩展情况下，扩展是通过复制微服务来完成的，而不是复制像虚拟机这样的底层基础架构。这种情况下，虚拟机或物理基础设施池可用于扩展微服务。这些虚拟机包含了应用程序所需要的任何依赖项(如JRE)，并且微服务应用本质上是同质的。所谓同质，是指应用程序都是由相同的编程语言编写的，或者应用编译后，所需要的依赖项都是一样的。这为在不同服务中重复使用相同的虚拟或物理机器提供了灵活性。

如图14-3所示，在场景-一中，虚拟机3用于服务实例C,而在场景二中，服务实例B也可以使用相同的虚拟机3。在这种情况下只交换应用程序库，并不会进行底层的基础架构的交换。

这种方法提供了更快的实例化，因为只处理应用程序二进制文件，而不处理底层的虚拟机。由于二进制文件的尺寸较小，因此切换更容易，速度也更快，也不需要操作系统引导。然而，这种方法的缺点是，微服务通常是使用相同的技术栈来实现的，如果某些微服务需要操作系统级别的调优或使用多语言技术，那么动态交换微服务将不会有效。

2.基础架构级别的自动扩展

与之前应用程序级别的自动扩展的方法相反，基础架构级别的自动扩展往往需要将整个基础设施也一并自动提供。在大多数情况下，这将根据需求即时创建新虚拟机或销毁虚拟机。

如图14-4所示，保留的服务实例被创建为具有预定义服务实例的虚拟机镜像。当有服务实例A的需求时，虚拟机1和虚拟机4会移动到活动状态。当有服务实例B的需求时，虚拟机2和虚拟机5则被移到活动状态。

如果应用程序依赖于基础结构级别的参数和库(如操作系统)，则此方法非常有效。此外，这种方法更适用于多语言构建微服务的场景。

其不利的因素-方面是虚拟机镜像的文件体积比较大，更加占用系统资源;另一方面，在做基础架构置换的时候，往往需要准备好一个新的虚拟机。在这种情况下, Docker等轻量级容器是首选，而不是传统的重量级虚拟机。

自动扩展的常用方法

自动扩展是通过考虑不同的参数和阈值来处理的。下面将讨论常用的自动扩展的方法和策略。

1.根据资源限制进行自动扩展

根据资源限制进行自动扩展是基于通过监测机制收集的实时服务指标的。一般来说，资源调整方法需要基于CPU、内存或机器磁盘来进行决策。这也可以通过查看服务实例本身收集的统计信息(如堆内存使用情况)来完成。

当机器的CPU利用率超过60%时，一个典型的策略是可能需要新增另外个实例。同样，如果堆大小超出了一定的阈值，那么也可以添加一个新的实例。当资源利用率低于设定的阈值时，缩小计算容量也是一样的，可以通过逐渐停止服务器来完成，如图14-5所示。

在典型的生产场景中，创建附加服务不是在首次发生超过阈值时完成的。最合适的方法是定义一个滑动窗口或等待期。

以下是一些常见的例子。

●一个响应滑动窗口的例子是，设置了60%的响应时间，当一个特定的事务总是超过设定的阈值60秒的采样窗口，那么就增加服务实例。

●在CPU滑动窗口中，如果CPU利用率一直超过70%，并超过5分钟的滑动窗口，那么就创建一个新的实例。

●例外滑动窗口的例子是，当80%的事务在60秒的滑动窗口，或者有10个事物连续执行导致特定的系统异常( 例如，由于耗尽线程池导致的连接超时)，在这种情况下，就创建一个新的服务实例。

在很多情况下，通常会设定一个比实际预期的门槛更低的门槛。例如，不是将CPU利用率阈值设置为80%，而是将其设置为60%，这样，系统在停止响应之前就有足够的时间来启动一个实例。

同样，当缩小规模时，就会使用比实际更低的阈值。例如，此时将使用40%的CPU利用率，而不是60%。这就会有- .个冷静的时期，以便在关闭时不会有任何资源竞争来影响关闭实例。

基于资源的缩放也适用于服务级别的参数，如服务吞吐量、延迟、应用程序线程池、连接池等。

这也同样适用于应用程序级别的参数。

2.根据特定时间段进行自动扩展

根据特定时间段进行自动扩展是指基于一天、一个月或一年中的特定时段来扩展服务，以处理季节性或业务高峰的一一种方法。例如，在“双十一”期间，各大电商网站都会迎来全年交易量的高峰，而在平时，交易数量就相对而言没有那么多。在这种情况下，服务根据时间段来自动调整以满足需求。如图14-6 所示，实例根据特定时间段来进行自动扩展。

又如，很多OA系统会在白天的工作时间使用的人数较多，而在夜间，就基本上没有人用。那么，这种场景就非常适合将工作时间作为自动扩展的基准。

3.根据消息队列的长度进行自动扩展

当微服务基于异步消息时，根据消息队列的长度进行自动扩展是特别有用的。如图14-7所示，在这种方法中，当队列中的消息超出- -定的限制时， 新的消费者被自动添加。

这种方法是基于竞争的消费模式。在这种情况下，--个实例池被用于消费消息。根据消息阈值添加新实例，以消耗额外的消息。

4.根据业务参数进行扩展

根据业务参数进行扩展是指添加实例是基于某些业务参数的，如在处理销售结算交易之前就扩展一个新实例。这样，一旦监控服务收到预先配置的业务事件，就会新增一一个新的实例，以处理预期到来的大量交易。这样就做到了根据业务规则来进行细化控制。

如图14-8所示，在这种方法中，接收到有特定的业务参数时，新的实例会被自动添加。

5.根据预测进行扩展

根据预测进行扩展是一-种新型的自动扩展范式，与传统的基于实时指标的自动扩展有着非常大的不同。预测引擎将采取多种输入，如历史信息、当前趋势等来预测可能的事务模式。自动扩展是基于这些预测来完成的。预测性自动扩展有助于避免硬编码规则和时间窗口。相反，系统可以自动预测这样的时间窗口。在更复杂的部署中，预测分析可以使用认知计算机制来进行预测。

在突发的流量高峰的情况下，传统的自动扩展可能无济于事。在自动扩展组件对这种情况做出反应之前，这个高峰就会对系统造成不可逆的损害。而预测系统可以理解这些情景并在实际发生之前预测到它们。

Netflix Scryer就是这样一个可以提前预测资源需求系统的例子。

本篇文章内容给大家讲解的是微服务的高级主题一自动扩展的常见模式

下篇文章给大家讲解的是如何实现微服务的自动扩展；

觉得文章不错的朋友可以转发此文关注小编；

感谢大家的支持！