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

作者|PeterLawrey ， NickTindall
译者|Sambodhi
策划|褚杏娟
过去，为了从“内部”（通常都是位于同一地点）的硬件中获得最大的性能和最低的延迟，这些有低延迟需求的公司都是在裸机服务器上部署的，放弃了虚拟化和容器化的便利性和可编程性。
近来，这些公司日益转向公共和私有“云”环境，或为其所调整的低延迟/高容量（LL/HV）系统提供卫星服务，或在一些场合下用于LL/HV工作负载本身。
这个演示是在一个典型的云原生环境中实现了ChronicleQueue的复制。该解决方案实现了主动/被动冗余和由Consul服务注册表健康检查驱动的自动故障切换。使用Prometheus和Grafana仪表盘来显示实时指标。

文章图片
图1：指标面板：在测试设备上（一台配备NVMESSD的i9笔记本，使用Minikube和Docker驱动），我们看到第99个百分点的写到读的延迟在40us左右（从领导者到追随者的测量）。这个性能可以得到很大的改善，但是由于性能调整不在本文的讨论范围内，所以没有试图对部署和示例代码进行调整。
优势与挑战
云原生环境为简化复杂应用架构的定义和部署提供了一个通用平台和接口。这种基础设施使人们能够使用成熟的现成组件来解决常见的问题，诸如领导者选举、服务发现、可观察性、健康检查、自我修复、扩展和配置管理。
典型的模式是在这些环境中的虚拟机上运行容器。但是，如今各大云提供商（如云提供商亚马逊云科技、MicrosoftAzure、GoogleCloud等）都提供了裸机（或接近裸机）解决方案，因此即使是对延迟敏感的工作负载也可以在云中托管。
这是对Chronicle产品如何在这些架构中使用的第一次迭代演示，包括对我们的客户在云和其他环境中遇到的一些挑战的解决方案。通过利用常见的基础设施解决方案，我们可以将Chronicle产品的优势与现代生产环境的便利性结合起来，提供简单的低延迟、运行稳定的系统。
解决方案
该演示由一组可配置（和动态）规模的集群中的节点组成。我们选择Kubernetes进行演示，因为它是云原生基础设施的事实标准；然而，大多数协调平台实现了类似的功能。
集群中的每个节点都包含一些玩具业务逻辑，这些逻辑在复制的ChronicleQueue中存储其状态。

文章图片
图2：单个Pod的示意图，显示了重要的容器和卷。
集群中的节点各自维护一个ChronicleQueue的副本，这些副本通过ChronicleQueueEnterprise复制保持同步。在任何时候，其中一个节点被设置为"领导者"节点；领导者负责根据一些业务流程填充队列。当当前的领导者节点失败或从集群中移除时，其中一个"跟随者"节点将被提升为领导者。这是一个用于实现高可用性的常见模式。
【如何在云中部署低延迟解决方案】集群节点在Consul服务云提供商注册表注册自己，并配置一个简单的健康检查，通过HTTP轮询其指标端点来监控节点的健康状况。在生产部署中，这种健康检查可能更复杂。
每个节点都是StatefulSet中的一个KubernetesPod 。每个Pod都包含以下容器：
1.业务逻辑
这个容器运行玩具“业务逻辑” ，它可以填充或从队列中读取（取决于其角色）。就本演示而言，业务逻辑层只是在领导者时向队列写入一串数值，并作为跟随者将这些序列号输出。在真实的部署中，这将是一个真正的应用程序——例如，在HA（高可用性）模式下的ChronicleFIX、ChronicleMatchingEngine ，或一个自定义的应用程序。