曹 郁 朱志祥

（1.西安邮电大学 西安 710061）（2.陕西省信息化工程研究院 西安 710061）

1 引言

随着互联网的迅速发展，涌现出越来越多的应用和服务，这些服务导致用户数量激增及网络上的流量爆炸式膨胀，由此出现的分布式服务架构和虚拟化技术受到人们的广泛关注。Dubbo是一种开源的分布式服务框架，是阿里巴巴SOA服务化治理的核心框架，提供透明的RPC远程方法调用。Docker是一种轻量的虚拟化技术，具有易用性、隔离性和秒级启动等特性，它创建简便、构建快速并且可在任意平台运行，这种兼容性使得用户可以在不同平台间迁移应用。基于Docker容器的Dubbo系统，实现了应用的自动化部署和扩展管理，提高了硬件资源利用率。

一般情况下，服务所承载的负载是相对平稳的，但在一些特殊的场景里，如淘宝双十一、新品网上限量发售等活动中，短时间内成千上万的用户向服务发出大量的请求。这些请求在给服务提供者带来巨大利益的同时也会带来很大的工作负载。若无法及时应对，将会导致服务瘫痪，进而无法响应用户请求和继续提供服务。

在面对高并发的请求负载时，Dubbo框架本身带有四种负载均衡策略。但在部署到Docker容器的环境中，只能对已有的Dubbo容器节点进行负载均衡，一旦请求量超过所有容器节点的承载量，Dubbo服务仍将面临奔溃的危险［1］。针对这一问题，本文提出对Dubbo监控中心的改造，根据制定的弹性负载均衡策略，在突发式工作负载下，横向弹性伸缩，利用Docker容器秒级启动和快速部署的优点，迅速应对请求量的激增，保证Dubbo服务的正常运行［2］。

2 系统架构设计

系统将Dubbo中的服务提供者Provider，服务消费者Consumer，注册中心Zookepper和监控中心Monitor分别放在不同的容器集群中，通过节点之间的调用关系将容器连接起来。

Dubbo与Docker结合的架构如图1所示。

图1 Dubbo与Docker结合的架构

在提供的应用中Provider Cluster Node需在Zookepper注册中心注册服务，将自己所能提供的服务地址暴露到注册中心，在消费者调用时提供服务；Zookepper是应用的注册中心，节点都处在同一级别，并会自动推举一个Leader，如果其中一台宕机，则舍弃这个节点，若Leader宕机，则重新选择Leader；Consumer Cluster Node在注册中心查阅到自己所需服务，它只需关注和Zookepper的通信并对自己所需服务向提供者发起请求，请求通过采用Nginx作为高性能的HTTP和反向代理服务器为向提供者分发请求；在整个调用过程中Monitor负责管理监控连接到Zookepper注册中心的提供者和消费者，同时记录消费者和提供者的调用过程和系统运行情况［3］。

Dubbo框架中包含四种负载均衡策略，分别是随机策略、轮询策略、最少活跃调用数策略和一致性Hash策略。随机策略是按照权重设置随机概率，使用权比较均匀，有利于动态调整提供者权重；轮询策略是按照公约后的权重设置轮询比率，存在慢的提供者累计请求问题；最少活跃调用数是指调用前后技术差大的提供者收到更少的请求；一致性Hash策略是将相同参数的请求发到同一提供者，当其中一台提供者无法提供服务时，原本发往的请求基于虚拟节点，分摊到其他节点，从而不会引起巨大变动。

通过对Dubbo所提供的负载均衡策略的分析与研究可以发现，在一般访问量的情况下，Dubbo可以利用策略将来自网络的服务消费者的请求负载均衡到服务提供者的各个Docker容器，保证了容器正常平稳的运行［4］。但是当一些特定场景出现时，伴随着服务消费者请求的大量激增，负载到容器上的请求也会迅速增加，同时容器的性能指标CPU使用率和内存使用率也会随即上升。若不能及时处理，就会影响到容器的正常运行。基于上述所提到的问题，引出以下对监控中心的改造和弹性负载均衡算法［5］。

3 监控中心的改造

原始的Dubbo监控中心Monitor负责统计各服务调用次数，调用时间等，统计先在内存汇总后以固定时间间隔发送到监控中心服务器，并以报表展示，为服务的监控运维采集数据。本系统在现有的监控模块的基础上，增加了报警模块和伸缩模块。它们的交互关系如图2。

图2 监控中心时序图

由监控模块对系统进行实时监控服务的调用次数，并将采集的数据发送到报警模块。报警模块参照所设计的弹性负载均衡策略，将调用次数与所设定的阈值进行比较，根据比较结果进行判断是否需要进行伸缩调整。当报警模块确定所要进行的操作后，发送指令到伸缩模块，最终由伸缩模块完成Docker容器的启动、部署或停止［6］。

1）监控模块

监控模块实时监控服务提供者所提供服务的调用次数，同时也会监控到调用服务的成功次数和失败次数，以及Dubbo在运行过程中系统状态，管理员通过监控中心的数据更好地管理系统。

监控模块还集成了Docker Swarm Mode。Docker Swarm Mode是Docker原生的集群管理工具，它创建并初始化API监听服务模块［12］。注册、发现以及调度模块在容器中独立运行，负责监听端口或者连接到其他主机的端口，不需要编写容器植入性代码就可以实现服务、注册、调度集群，以及分布式的终端部署集成［7］。在监控调用次数的同时还可以查看Docker容器的运行和使用情况，观测到每个容器的CPU使用率、内存和网络情况，这样对于Dubbo管理员对系统日常维护提供了更加直观的数据。同时也可以在弹性负载均衡时提供更可靠的保障［8］。

由于容器的性能时时刻刻都在发生变化，过于频繁的采样会给系统带来计算负担，所以需要采用区间采样。监控中心每隔一个固定时间间隔采集一次数据，再将数据发送给报警模块［9］。

2）报警模块

报警模块的主要任务是将监控中心传来的数据进行分析，在满足伸缩的情况下，触发伸缩模块的扩展操作或者收缩操作。

报警模块不断等待传过来的调用次数数值，当接收到数据时，就把数据与所设定的阈值进行比较。若超过阈值，则按照相应的算法，会触发相应的伸缩机制。伸缩扩展时首先计算出所需扩展容器的数量，然后确定是为服务提供者集群节点增加相应数量的容器个数。最后将所确定的伸缩对象和伸缩数量作为伸缩方案，发送给伸缩模块［10］。

3）伸缩模块

伸缩模块一直处于等待伸缩方案状态，当方案到达时，就会按照其中的伸缩对象和伸缩数量进行调整。每次操作完成后就会重新更新容器数量，并进入冷却状态，以免造成系统“抖动”，且伸缩的整个过程不能被中断。

首先判断是否是伸缩指令，若不是，则继续等待；若是则判断是否是伸缩扩展指令，若不是就进入冷却状态，若是，则根据方案中的伸缩对象进行扩展操作，即对服务提供者的Docker容器增加相应的容器数量，待伸缩扩展完成后进入冷却状态。最后判断指令是否结束，若无继续操作的指令，伸缩模块任务结束。

4 弹性负载均衡算法

基于阈值的伸缩方案可实现对系统工作负载的动态适应，但关键问题是如何设定适当的伸缩规则和系统性能指标。本方案采用服务的调用次数作为性能指标进行弹性伸缩。系统的工作负载主要来自服务消费者的请求，而这些请求在系统中的直接体现就是监控中心所监测到的调用次数。所以选择服务的调用次数作为算法的指标可以更好地体现弹性负载均衡的特点。

高并发的服务消费者的请求进入系统的时候，直观和迅速地反映到系统的监控中心。监控中心会立即将系统的服务调用次数统计出来，而请求会通过Dubbo所提供的策略负载均衡到各个服务提供者的Docker容器节点［11］。突发式的工作负载所带来的就是容器的CPU使用率和内存使用率急剧上升。每个容器都有自己所能提供的工作上限，当容器的使用率达到一定的数值时，若不能及时处理，就会面临宕机的危险［12］。

首先设定阈值K，K是定值，调用次数Ki超过K时，报警模块就要制定伸缩方案。若在t1时刻，Ki第一次超过K时，报警模块就记录此刻的调用次数。在t2时刻监控中心发送的调用次数再次超过K值时，报警模块就触发伸缩机制。即满足

当x≥0时，则启动伸缩模块进行容器的扩容。统计从t1时刻到t2时刻所有的并发量是为了防止突发的工作负载只是短暂的，不会对系统造成影响，并且迅速恢复到系统可承载的请求量。监控中心在t1至t2时间段内，若所监测到的调用次数始终处于高于阈值的状态，则再去调用报警模块制定伸缩方案，使伸缩模块完成弹性负载均衡过程。这种策略能够更加及时有效地应对高并发的负载，减少资源的浪费。

容器收缩时不能一次全部释放，而是要逐步释放，并在释放的过程中需保证监控中心监测到的调用次数总是小于阈值。这样处理的好处就是避免因释放过多资源而导致系统损失大量性能，且在释放的时间段内，一旦调用次数高于阈值，可立即启动还未释放的容器。Docker具有快速部署，秒级启动等优点，可以迅速分担工作负载［13］。每次释放完容器后都会有一个短暂的冷却时间，时间的设定只需按照经验取即可［14］。

5 实验验证

1）创建系统运行环境

实验采用Dockerfile制作所需的镜像，使用容器编排工具docker-compose一键式构建基于dock⁃er容器的Dubbo实验环境。

图3 基于Docker的Dubbo系统

2）模拟用户发送请求

系统监控中心设定监控时间为30s，设定用户调用次数的阈值是600。实验采用webbench进行压力测试，-c表示调用次数，-t为请求响应时间，URL为请求响应地址。

如图4模拟用户请求为600次，即调用次数是600：

图4 模拟用户请求

3）结果分析

图5 不同时间段的请求次数折线图

图6 容器数量变化折线图

由图5可知，在120s时，调用次数达到阈值600次，并在150s时持续增长至1000次，此时调用报警模块调用弹性负载均衡算法，x=30*1000-30*600=12000＞0，所以调用伸缩模块进行扩容操作。

图6显示，在180s时容器扩容，由原来的4个容器扩至6个，并在240s时，请求量低于阈值时，容器减少到5个，从而体现容器递增步长扩容，固定步长缩容的特点。

6 结语

监控中心能够监控服务的调用次数，并将次数传送到报警模块，报警模块通过数据与阈值的比较结果，根据弹性负载均衡算法判断是否触发伸缩模块，从而实现系统的弹性负载均衡。

将Dubbo框架部署到Docker容器中节约了系统资源，避免了当应用越来越大时所带来启动时间的延长和持续部署的难度。同时在监控中心部分增加了弹性负载均衡策略，使得系统更加快速高效地应对高并发的用户请求。