译者 | 李睿
审校 | 重楼
当开发人员着手重建托管Apache Kafka服务的核心引擎时，需要满足一些独特的需求，这些需求是成功的云原生平台的特征。这些系统必须是多租户的，易于扩展以服务数千个客户，并且主要由数据驱动的软件而不是运行人员进行管理。它们还应在工程师可以继续快速创新的环境中，为工作负载不可预测的客户提供强大的隔离和安全性。
软件服务提供商Confluent公司在去年展示了Kafka引擎的重新设计。其设计和实现的大部分内容适用于其他构建大规模分布式云计算系统的团队，例如数据库或存储系统。Confluent公司首席工程师Prince Mahajan表示，希望与更广泛的社区分享所学到的知识，可以使那些从事其他项目的人受益。
Kafka引擎重新设计的关键考虑因素
Confluent公司的目标很可能与一些企业基于云计算的系统目标相似：提高性能和弹性，为自己和客户提高成本效益，并在多个公共云平台之间提供一致的体验。此外，还增加了与当前版本的Kafka协议保持100%兼容的要求。
该公司重新设计的 Kafka 引擎（称为 Kora）是一个事件流平台，在AWS、Google Cloud和Azure的70多个可用性区域运行数万个集群。虽然企业可能不会立即以这种规模进行操作，但许多技术仍然适用。
以下是Confluent公司在新的Kora设计中实现的五个关键创新：
1.使用逻辑“单元”实现可扩展性和隔离
要构建高可用性和水平可扩展的系统，需要使用可扩展和可组合的构建块构建的架构。具体地说，可扩展系统所做的工作应该随着系统规模的增加而线性增长。最初的Kafka架构并不符合这个标准，因为负载的许多方面随着系统规模呈非线性增长。
例如，随着集群大小的增加，连接数量将呈二次方增长，因为所有客户端通常都需要与所有代理进行通信。同样，复制开销也呈二次方增长，因为每个代理通常在所有其他代理上都有追随者。最终的结果是，相对于带来的额外计算/存储容量，添加代理会导致开销不成比例地增加。
第二个挑战是确保租户之间的隔离。特别是，行为不端的租户可能会对集群中其他租户的性能和可用性产生负面影响。即使进行有效的限制和节流，也可能总是存在一些有问题的负载模式。而且，即使客户端运行良好，节点的存储空间也可能会减少。如果在集群中随机分布，这将影响所有租户，甚至可能影响所有应用程序。
Confluent公司使用一种称为单元的逻辑构建块解决了这些挑战。将集群划分为一组单元，这些单元交叉切入可用性区域。租户被隔离到单个计算单元，这意味着该租户拥有的每个分区的副本被分配给该计算单元中的代理，复制与该单元内的代理隔离。在单元级别上，向单元添加代理会带来与以前相同的问题，但是现在可以选择在集群中创建新的计算单元，而不会增加开销。此外，这提供了一种处理嘈杂租户的方法，可以将租户的分区移到隔离区。
为了评估这个解决方案的有效性，Confluent公司设置了一个具有 6 个代理单元的实验性 24 个代理集群。当运行基准测试时，集群负载(为测量Kafka集群上的负载而设计的自定义指标)在有单元时为53%，而在没有单元时为73%。
2.平衡存储类型以优化热数据和冷数据
云计算的一个关键优点是，它提供了具有不同成本和性能特征的各种存储类型。我们可以利用这些不同的存储类型在架构中提供最佳的性价比权衡。
块存储提供了控制各种性能维度的持久性和灵活性，例如IOPS(每秒输入/输出操作)和延迟。然而，随着规模的增加，低延迟磁盘的成本会越来越高，这使得它们不适合存储冷数据。相比之下，Amazon S3、Microsoft Azure Blob storage和Google GCS等对象存储服务成本低，可扩展性强，但延迟比块存储高。如果需要写入大量小文件，它们也会很快变得昂贵。
通过对架构进行分层以优化这些不同存储类型的使用，在降低成本的同时提高了性能和可靠性。这源于将存储与计算分离的方式，主要有两种方式：对冷数据使用对象存储，对更频繁访问的数据使用块存储而不是实例存储。
这种分层架构允许提高弹性——当只需要重新分配热数据时，重新分配分区变得容易得多。使用EBS卷代替实例存储还可以提高持久性，因为存储卷的生命周期与关联虚拟机的生命周期是分离的。
最重要的是，分层能够显著降低成本和提高性能。降低成本是因为对象存储是存储冷数据的更实惠和可靠的选择。而且性能也得到了提高，因为一旦数据分层，就可以将热数据放在高性能的存储卷中，如果没有分层，其成本将会非常昂贵。
3.使用抽象来统一多云体验
对于任何计划在多个云平台上运行的服务，跨云提供统一的、一致的客户体验至关重要。由于多种原因，这很难实现。云计算服务是复杂的，即使它们符合标准，云服务和实例之间仍然存在差异。类似云服务的实例类型、实例可用性甚至计费模型都可能以细微但有影响的方式发生变化。例如，Azure块存储不允许独立配置磁盘吞吐量/IOPS，因此需要配置更大的磁盘来扩展IOPS。相比之下，AWS和谷歌云允许用户独立地调整这些变量。
许多 SaaS 提供商都对这种复杂性不屑一顾，让客户担心实现一致性能所需的配置细节。这显然并不理想，所以对于Kora，Confluent公司开发了抽象差异的方法。
Confluent公司引入了三个抽象，使客户能够远离实现细节，并专注于更高级别的应用程序属性。这些抽象可以帮助显著地简化服务，并限制客户需要自己回答的问题。
（1）逻辑Kafka集群是访问控制和安全的单元。这是客户管理的同一个实体，无论是在多租户环境中还是在专用环境中。
（2）Confluent Kafka Unit (CKU)是Confluent公司客户的容量单位(也是成本单位)。CKU 表示为客户可见指标，例如入口和出口吞吐量，以及请求速率、连接等一些指标上限。
（3）最后，将集群上的负载抽象为一个称为集群负载的统一指标。这可以帮助客户决定是扩大还是缩小其集群。
有了这些抽象，客户就不需要担心底层的实现细节，服务提供商可以在新的硬件和软件选项可用时不断优化性能和成本。
4.自动化缓解循环以应对退化
故障处理对可靠性至关重要。即使在云中，故障也是不可避免的，无论是由于云服务中断、软件错误、磁盘损坏、错误配置还是其他原因。这些可能是完全故障，也可能是部分故障，但无论哪种情况，都必须迅速解决，以避免影响性能或对系统的访问。
遗憾的是，如果企业正在大规模运行云平台，则无法人工检测和解决这些故障。这将占用运营人员太多的时间，并且可能意味着故障的解决速度不够快，无法维持服务级别协议。
为了解决这个问题，Confluent公司构建了一个解决方案来处理所有这些基础设施退化的情况。具体来说，构建了一个由退化检测器组件组成的反馈循环，该组件从集群收集指标，并使用它们来决定是否有任何组件出现故障，以及是否需要采取任何措施。这使Confluent公司在不需要任何人工操作的情况下，每周能够解决数百个退化问题。
Confluent公司实施了几个反馈循环来跟踪代理的表现，并在需要时采取一些行动。当检测到问题时，将用不同的代理运行状况状态对其进行标记，并使用各自的缓解策略对每种状态进行处理。其中三个反馈循环解决本地磁盘问题、外部连接问题和代理降级问题：
（1）监控：一种从外部角度跟踪每个代理表现的方法。Confluent公司经常探测以进行跟踪。
（2）聚合：在某些情况下会聚合指标，以确保相对于其他代理的降级是显而易见的。
（3）React：特定于 Kafka 的机制，用于将代理排除在复制协议之外，或将领导权从复制协议中移走。
事实上，Confluent公司的自动缓解措施每个月都会检测并自动缓解全球三个主要云计算提供商的数千次部分降级。既可以节省宝贵的操作时间，同时确保对客户的影响最小。
5.平衡有状态服务的性能和效率
在任何有状态服务中，平衡服务器之间的负载都是一个难题，并且直接影响客户体验的服务质量。负载分布不均匀会导致客户受到负载最多的服务器提供的延迟和吞吐量的限制。有状态服务通常有一组密钥，需要平衡这些密钥的分布，使总体负载均匀地分布在各个服务器上，以便客户机以最低的成本从系统获得最大的性能。
例如，Kafka运行有状态的代理，并平衡分区及其副本分配给各种代理。这些分区上的负载可能以难以预测的方式上下波动，具体取决于客户活动。这需要一组指标和启发式方法来确定如何在代理上放置分区，以最大限度地提高效率和利用率。Confluent公司通过一个平衡服务来实现这一点，该服务跟踪来自多个代理的一组指标，并在后台持续工作以重新分配分区。
需要明智地重新平衡任务。过于激进的再平衡可能会破坏性能并增加成本，因为这些重新分配会产生额外的工作。过于缓慢的再平衡会让系统在修复失衡之前显著退化。Confluent公司不得不尝试大量的启发式方法，以收敛到适用于各种工作负载的适当反应级别。
有效平衡的影响可能是巨大的。Confluent公司的一位客户发现，在为他们启用重新平衡后，他们的负载减少了大约 25%。同样，另一个客户发现，由于重新平衡，延迟大幅减少。
精心设计的云原生服务的好处
如果企业正在使用新代码或使用现有的开源软件(如Kafka)构建云原生基础设施，希望本文介绍的技术将帮助他们实现性能、可用性和成本效益方面的预期结果。
为了测试Kora的性能，Confluent公司在相同的硬件上进行了一个小规模的实验，将Kora和完整云平台与开源Kafka进行比较。发现Kora提供了更大的弹性，扩展速度快了30倍；与Confluent公司管理的客户或其他云计算服务的故障率相比，可用性提高10倍以上，并且比自我管理Kafka的延迟要低得多。虽然Kafka仍然是运行开源数据流系统的最佳选择，但对于那些寻求云原生体验的人来说，Kora是一个很好的选择。
云原生系统的构建和管理可能非常复杂，但它们已经支持大量的现代SaaS应用程序，这些应用程序为当今的大部分业务提供动力。希望企业的云计算基础设施项目能够继续保持这一成功轨迹。
原文标题：5 tips for building highly scalable cloud-native apps，作者：Prince Mahajan
