如何在云中部署低延迟解决方案( 二 ) 作者|PeterLawrey

集群必须提名一个领导者Pod ，负责填充队列，所以业务逻辑层参与Consul领导者的选举。业务逻辑层的伪代码如下：while(running){role=runLeaderElectionwhile(role==leader){//Doleaderlogic}while(role==follower){//Dofollowerlogic(ifany)}}
业务逻辑容器从/到“复制状态”卷的读/写队列。
2.replicator
这个容器运行ChronicleEnterpriseQueue的复制过程。它监控“replicationconfig”卷中复制配置文件的更新，当检测到更新时，它用新的配置重新启动复制。如果复制配置不存在或无效，它不会启动复制。
当集群发生变化时，重启复制是我们推荐的一种常见模式，重启本身发生在几毫秒内，这意味着复制的中断是最小的。
3.config-generator
因为我们有Consul作为服务注册表，而且我们的领导者选举是通过Consul键值存储进行的，所以我们可以仅从Consul的状态中得出我们的复制配置。
这个容器使用Consul模板来监控Consul在集群中的变化（例如，增加或移除节点）或当前领导者的变化。当任何这些变化发生时，复制配置会重新生成到“复制配置”卷中。
4.exporter-merger
这个容器运行一个进程，将来自复制器和业务逻辑容器的普罗米修斯指标组合起来。
监控
Consul使用云提供商可配置的检查来监控容器的健康状况。如果健康检查发现一个节点失败了，它就会放弃领导权（如果持有的话）并从集群中移除。 Kubernetes也监控每个Pod的健康状况，当一个Pod出现故障时，它将被关闭，并创建另一个Pod来代替它。

文章图片
图3：Consul服务注册表UI显示健康的复制集群
业务逻辑和复制容器都通过Prometheus发布指标，公开集群的状态。通过Prometheus发布的指标会被Grafana渲染成一个仪表盘。
图1显示了指标仪表板。你可以看到在这个快照中， replica-0是领导者，其他副本是跟随者。由于其他复制体的回执，复制体-0的读取率非常高。
总结
Consul维护一个集群成员的注册表，我们的应用程序注册健康检查，以删除任何不健康的节点。 Consul还促进了领导者的选举，确定哪个节点应该是领导者，哪个节点应该是追随者。然后， ChronicleQueue复制配置是由Consul中的集群状态衍生出来的。
该演示有以下属性：当领导者节点失败时，一个追随者节点会自动晋升为新的领导者节点。如果使用Kubernetes的“scale”命令来改变集群的大小，节点的配置将自动调整。这种扩展也可以根据负载情况自动进行。新的节点由Prometheus发现，其指标会自动包含在仪表盘中。故障转移大约发生在（检测故障所需时间，即健康检查超时）+（传播Consul状态的时间）+（到Consul服务器的TCP往返），在演示环境中，健康检查超时占主导地位。对于更多地理分布的部署，传播Consul状态的时间将变得更加重要。这些功能大部分是通过配置而不是代码实现的。有一些插入标准Chronicle接口的瘦身适配器可以实现这种行为。
结论
本文展示了将一个动态的、低延迟的、基于Chronicle队列的应用程序部署到Kubernetes集群的一种方法。
Kubernetes（StatefulSets、动态配置）和Consul（服务注册表、领导者选举、配置模板）中的一些结构与ChronicleQueueEnterprise中的概念非常匹配，大大简化了操作层面。
标准的Chronicle接口允许发布关键指标，以提供部署应用程序状态的实时视图。
作者介绍：
PeterLawrey ，开发者。
NickTindall ， ChronicleChronicle顾问。