confluent博客解读part0 云原生消息系统设计

发表于 分类于 阅读次数： 本文字数： 999 阅读时长 ≈ 3 分钟

背景

confluent博客解读是一个系列，主要是对confluent以下博客内容的一个阅读总结。

今天我们介绍的是第一篇，设计云原生数据系统时的设计考量，这篇文章是一篇导览性质的文章，具体的细节介绍会在各个part的文章解读中和大家进一步分享。

一些基本概念与输入

  • twelve-factor app可以一定程度上解释云原生应用是怎样的
  • confluent从用户眼中了解到用户对云原生数据平台的期望，也是confluent理解的cloud-native data system索要具备的特点：
    • elasticity：可以一键弹性；可以基于策略自动伸缩
    • infinite scale：可以有无限规模，在云上的话，某种程度来说，确实是这样的
    • resiliency: 高可用性
    • multi-tenancy: 服务最好是以高度抽象的形式提供，例如像S3一样通过API请求，用户无需关心底层资源
    • pay per use: 按用量计费，只对实际使用的资源进行付费。这些资源可以是高层抽象过的资源，例如读写请求，也可是底层的物理资源，例如CPU和内存的用量。用户无需为没有使用的量进行付费
    • cost effective: 主要指价格便宜，这个采用cloud service通过多租、pay per use等手段可以使得服务价格很便宜
    • global: 全球化的，云原生数据系统是全球化的，用户涉及全球化的一些数据复制时，通过一个checkbox或者api调用就可以轻松搞定

弹性

confluent为用户提供弹性的细节技术会在Part 1: Making Apache Kafka Serverless: Lessons From Confluent Cloud中进一步分享，包括：

  • 实现上采用事件驱动的微服务来组织控制面(choreography pattern)：好处是各个开发小组可以独立管理他们控制面自己的逻辑，基于event log的方式也可以刚好的去容错、恢复。
  • 两种核心功能：
    • Self Balancing Clutsets(SBC): confluent server的附加能力，可以自动探测负载做自动均衡。
    • tiered storage: 分层存储使得转移负载成为可能

性能和可伸缩性

confluent完成性能和伸缩性的重点是感知和理解用户的workload。在Speed, Scale, Storage: Our Journey from Apache Kafka to Performance in Confluent Cloud 这篇文章中会讨论到confluent设计高性能的云原生数据系统采用的一些原则。

要做到高性能和可伸缩，需要设计的系统在多个维度进行相关工作，从硬件、操作系统到软件的各个维度。关键是要形成一个严格的生产反馈环（tight feedback loop with production），通过生产级的可观测性，探测、分析性能和弹性事件，快速调整。

多租户

云和自建的系统都可以提供多租户的能力，但是云和自建的系统呈现出来的多租户效果是不同的。云有透明弹性的能力，租户不需要做容量评估或者做一些资源预置造成浪费。From On-Prem to Cloud-Native: Multi-Tenancy in Confluent Cloud 这篇文章介绍了多租户的三个维度：

  • 访问隔离(access isolation)
  • 命名空间隔离（namespace isolation）
  • 性能隔离(performance isolation)

存储持久审计

这个持久审计主要指的是数据质量的审计功能。避免数据丢失或者不一致。confluent的云服务在这块有很多额外投入，自建的话就需要自己建设这方面的能力了。Protecting Data Integrity in Confluent Cloud: Over 8 Trillion Messages Per Day 这篇文章主要介绍了这块能力的建设。