Qlik关联引擎使用了一个自定义度量 来监测每个引擎Pod中活动的会话数量 (请注意，您的项目也许会有所不同)。开源的监测工具Grafana负责监测，同时您可以使用Prometheus来监测和微调您的自动扩展度量。

当Pod需要更多的容量，新节点就会被自动添加到集群之中。而当集群存在多余的容量时，节点就可以被删除。在本例中，Pod水平自动扩展 (HPA) 的配置为在一个引擎上最多放置20个会话——虽然这是一个比较低的设置，但非常适合进行实验。引擎部署配置为每个节点运行一个引擎。

随着活动会话的增加，HPA将向现有节点添加一个新的pod，或者根据需要启动尽可能多的新节点。使用新的引擎Pod启动一个新节点通常需要30秒到5分钟。这一时长取决于云供应商及其创建新节点的速度 (理论上，节点越大，创建新节点所需的时间就越长)。因此，您无需再担心应用的访问量激增，Qlik Core可以帮助您轻松处理这种情况。并且，您还可以享受到云计算的一个关键优势——仅为您所使用的资源付费。

用例2 : 辅助处方应用

接下来，让我们将目光转向另一个用例——我们正在部署一个能够支持多个用户访问相同Qlik关联引擎实例的数据应用，而与此同时，该应用也需要扩展以处理增加的活动。

该医学分析应用以全世界范围内的医生群体为目标，提供了有关药物、治疗和反应方面的先进分析能力。我们通过一个自定义的web用户界面，以单一的Qlik关联引擎文档为多个用户提供了基于Qlik Core的服务。

创建这个多用户应用所面临的关键挑战就是平衡负载。我们的设计有多个Qlik关联引擎实例，它们服务于同一个文档。用户将根据一个简单的循环负载平衡器被分配到各个Qlik关联引擎实例。

虽然我们可以认为这样的应用拥有相对固定的用户量，但是我们也需要为激增的活动进行准备——比如遇到流行病传播期。这很可能将成为云架构和容器编排拯救生命的时刻。

我们选择使用Docker Swarm将应用托管在AWS上，当然您也可以使用其他容器编排服务将其部署到其他云供应商。Qlik关联引擎运行在单个Docker集群中，拥有一个管理节点和两种工作节点。

管理节点使用开源的度量工具Grafana和Prometheus来处理我们的web网关、身份验证、会话管理和监测工作。

每个引擎工作节点负责运行一组最小的服务，以支持单个Qlik关联引擎实例。这些节点非常易于伸缩。

最后，ELK (Elasticsearch、Logstash和Kibana) 工作节点负责运行ELK堆栈以及用于搜索、数据处理和可视化的服务。这个节点卸载了一些可能影响Qlik关联引擎性能的工作。

然后，您可以使用一个单一的脚本在AWS中部署一个运行这些节点的Docker Swarm。默认情况下，它将为每个实例启动两个引擎工作节点。因此，实现扩展变得和添加更多的引擎工作节点一样简单，而这些新的工作节点将自动启动Qlik关联引擎。除此之外，您还可以在有效平衡负载的同时使用标准的监测及日志收集工具。