引言：云原生转型与“经济型操作系统”
要理解 Apache Kafka 当前的架构发展方向，首先需要明确其本质。Kafka 是一个分布式事件流平台，旨在实时发布、订阅、存储和处理记录流。其演进由开源社区通过 “Kafka 改进提案”（KIP）来推动，这些正式的设计文档概述了主要的架构变更和功能特性。
多年来，Kafka 一直严格依赖于一种专为优化裸机部署的“无共享”设计。它将顺序的仅追加日志直接写入本地代理磁盘，并直接从操作系统的页面缓存中提供读取服务，从而实现了其传奇般的个位数毫秒级延迟。这种方法既保证了低延迟，又保证了高吞吐量。然而，将这种受硬件限制的架构“原样迁移”到现代云环境中，却暴露出了严峻的财务问题。
以 Discover Financial Services 的现代化转型历程为例。Discover 总部位于伊利诺伊州的里弗伍兹，其全球网络每天处理数百万笔交易。为了提高工程开发速度并支持数据科学项目，Discover 将其传统的信用卡结算环境迁移到了以 Apache Kafka 作为核心事件主干的云原生架构上，将信用卡结算交易实时流式传输至下游处理层（包括 Amazon EMR 和 Apache Spark），用于欺诈检测和风险评分。此次迁移将价格变更的落地时间从六个月大幅缩短至仅三周，使该平台能够在短短九分钟内处理四百万条交易记录（亚马逊云科技客户案例研究、2021 年亚马逊云科技 re:Invent 大会上的演讲）。
在现代化技术栈中，Kafka 发挥着独特的作用：其事件流架构为风险分析和欺诈检测提供了实时处理的主干，可以持续地为下游模型提供数据，而 EMR 和 Spark 则负责批处理结算。
然而，将一个庞大的多租户平台迁移到云端，会暴露出云端单位经济性的现实问题。在可用区（AZ）之间对交易数据进行三次镜像复制，会产生巨额的网络出站费用。此外，将数 PB 的审计日志或历史事件流式存储在高级云块存储上，成本很快就会高得令人望而却步。
为了在云环境中生存，Kafka 正从一个严格受硬件限制的系统，逐步演变为一种由严格财务控制所主导的高度解耦的架构。虽然这种架构常被称为“经济型操作系统”，但这一术语不仅仅是一个比喻；它代表了一种具体的运营现实，即平台团队必须积极构建基于遥测数据的成本分摊管道，推行注重成本的回放治理工作流，并有选择地应用队列语义来管理波动剧烈的云支出。
下图所示的决策矩阵说明了架构师应该如何将具体的工作负载与这些不断演进的能力进行匹配：
图 1. 将工作负载映射到分层存储能力的决策矩阵（图片由作者提供）
如图 1 所示，架构师应该根据事务顺序要求、延迟敏感度以及数据保留需求，将具体的工作负载映射到这些不断演进的能力上。
在本文中，我们将结合从分层存储到无盘未来的各个架构演进阶段，探讨现实中的运营挑战，并详细说明架构师和平台团队必须如何调整其部署策略。
解耦计算与存储容量：分层存储的实践现状
KIP-405：Kafka 分层存储通过将数据保留划分为两个独立的层，改变了代理与状态之间的关系：一个是利用块存储的、针对延迟进行优化的本地层，另一个是利用对象存储（如 Amazon S3）的、针对存储容量进行优化的远程层。一个名为“远程日志管理器”（Remote Log Manager）的内部代理组件充当协调器，当滚动日志段超过特定的大小或时间阈值时，会将其异步地从本地磁盘移动到外部存储。
实用指南：何时启用分层存储
平台团队不应该盲目地在所有集群中启用 Kafka 分层存储。架构师必须根据三个因素来评估磁盘存储与对象存储之间的取舍：数据保留时长、读取模式以及当前块存储卷的成本状况。那些数据保留时间远超其活跃处理窗口（通常超过七天）的集群是最理想的候选对象，因为其中存储的大部分数据都属于冷数据，可以以远低于块存储成本的价格迁移到对象存储。然而，对于保留窗口较短或具有延迟敏感型热读取模式的集群，收益可能微乎其微，甚至会因为对象存储 API 的开销（参见下文的请求放大效应）而增加成本。有多种标准可以帮助我们做出有利的取舍。
合规与审计需求
你的工作负载需要长期保留数据（例如，为符合《萨班斯-奥克斯利法案》（SOX）或《支付卡行业数据安全标准》（PCI-DSS）而保留七年的审计日志）。假设某金融机构在 EBS gp3 卷上（根据 AWS EBS 定价页面，费用为 0.08 美元/GB-月）为每个 Kafka 代理存储 50 TB 的审计日志。若 Kafka 复制因子为 3，仅是块存储每月每代理的成本就约为 12288 美元（50 TB × 1024 GB/TB × 0.08 美元 × 3 ）。将冷数据段迁移至 S3 Standard（根据 AWS S3 定价页面，0.023 美元/GB-月）可以将数据保留成本降至每月约 1178 美元，节省约 90%。对于使用预配置 IOPS 高性能 io2 卷（ 0.125 美元/GB-月）的集群，节省幅度可以超过 93%。这些数据基于 2025 年美国东部（北弗吉尼亚）的标价；实际成本因区域、协商折扣及数据检索模式而异。读者可使用亚马逊云科技的定价计算器验证并自定义这些估算值。
基于回放的深度分析
机器学习管道和数据科学团队经常需要通过扫描多年的历史交易数据来重建状态存储。分层存储通过远程层处理这些读取请求，从而将本地磁盘上对延迟敏感的实时交易处理与高 I/O 负载相隔离。
采用短保留窗口需慎重
如果你的工作负载主要属于实时处理，数据保留时间不足七天，那么架构复杂性的增加以及潜在的 API 开销将导致无法带来正向的投资回报。
FinOps 风险：请求放大
虽然分层存储能大幅降低块存储的开支，但云对象存储 API 的引入却带来了严重的 FinOps 风险。云基础设施提供商对对象存储的计费不仅基于静态存储的千兆字节数，还基于 API 交互的数量（例如，按每千次 GET 请求收费）。
本质上，Kafka 消费者执行的是顺序读取操作，因此，如果配置错误的消费者试图获取数年的历史数据，就可能会引发请求放大效应，导致每秒产生数千个独立的 S3 GET 请求，使 API 费用急剧飙升。
架构措施：为降低请求放大风险，平台工程师应该考虑将消费者的 max.partition.fetch.bytes 与消息代理的远程分段大小保持一致。其原理很简单：如果消费者的获取窗口与远程对象的大小高度匹配，那么代理在每次获取数据时发出的单独 GET 调用就会减少，从而可以降低尾部延迟并减少 API 成本暴露。不过，这仍然只是一种优化模式，而非放之四海皆准的方案；实际的对象存储 API 调用次数取决于分段大小、获取频率、消费者的并行度以及访问局部性。
值得注意的是，社区已经意识到了这一调优鸿沟：KIP-1178 提议引入一个专用的 remote.max.partition.fetch.bytes 消费者配置，将远程获取的大小与本地获取行为解耦，并且承认，当前 1 MB 的默认值与典型云连接器的 4 MB 数据块大小不匹配。在 KIP-1178 或类似提案投入生产环境之前，团队应该将抓取大小调优视为一项经验性操作，并通过远程抓取指标验证其对特定工作负载的影响，而不是假设它能普遍消除 API 成本风险。
弥补可视化方面的不足：FinOps 与成本归因
起初，分层存储会让平台工程团队在财务方面处于“盲区”。如果内部开发团队启动了一个扫描五年交易记录的重型批处理任务，云服务账单就会飙升，但运维人员却无法将成本归因于特定的应用程序，因为传统的 Kafka 指标仅在代理或主题级汇总数据。正是这一治理缺口催生了 KIP-1267：分层存储成本归因指标。该提案建议引入客户端 JMX 遥测数据，包括 RemoteFetchBytesPerSec 和 RemoteFetchRequestsPerSec 等指标，实现针对每个消费应用的精细化成本归因。
重要提示：KIP-1267 目前正处于社区讨论阶段，尚未被采纳或合并到 Apache Kafka 的发布版本中。下文所述的遥测管道（利用 Prometheus 抓取这些指标，并通过 Grafana 可视化每个客户端的成本归因）代表了该 KIP 投入生产环境后的预期架构模式，并非当前上游 Kafka 版本中已有的功能。对于在 KIP-1267 发布前就需要进行成本归因的组织，可以结合代理级指标与消费者组延迟跟踪来做近似实现，但这种方法缺乏 KIP 所提出的客户端粒度。
KIP-1267 解决了这一关键的可视化缺口。它引入了专门针对远程存储操作而设计的精细化 JMX 遥测功能，并将其直接与客户端 ID 相关联。这项增强功能使运维人员能够将远程读取成本准确地归因到特定的消费者，从而实现严格的成本分摊和 FinOps 治理。
构建基于遥测数据的成本分摊管道
平台团队必须将这些指标转化为具体的治理工作流。以下是利用 Prometheus 和 Grafana 实现这一目标的实用路径：
指标暴露与集中抓取
在代理节点上配置 Prometheus JMX 导出代理。定义 YAML 规则用于捕获新指标（例如 RemoteFetchBytesPerSec 和 RemoteFetchRequestsPerSec），并通过集中式抓取服务器将其对外暴露。
成本归因仪表盘（PromQL）
平台工程师可以在 Grafana 中使用 PromQL 构建仪表板，计算每位客户每小时的预计成本。使用多维成本公式，将出站字节数乘以云服务提供商的 GB 传输费率，并将请求数乘以 API 定价层级：
# 注意：下文中的指标名称遵循 JMX-to-Prometheus 命名约定，# 并应用于 KIP-1267 中提出的指标（RemoteFetchBytesPerSec、# RemoteFetchRequestsPerSec）。确切的 Prometheus 指标名称取决于你的 JMX 导出器# 映射配置。各团队在将这些查询应用于生产环境之前，应根据已采纳的 KIP 规范及其导出器# 配置核对最终的指标命名。# 出站成本组成# 将字节/秒的速率转换为 GB/小时，然后乘以服务商的出站速率(sum(rate(kafka_server_remote_fetch_bytes_total[1h])) by (client_id) * 3600 # 速率以秒为单位，扩展到以小时为单位 / 1073741824 # 将字节转换为 GB * 0.09) # 需要根据云服务商的规则，对出站流量速率进行验证+# API 请求成本组成# 将每秒请求数转换为每小时请求数，并按每 1000 次请求计价(sum(rate(kafka_server_remote_fetch_requests_total[1h])) by (client_id) * 3600 # 扩展到以小时为单位 / 1000 # 按每千次请求为单位进行标准化 * 0.0004) # 需要根据云服务商的规则，对 S3 GET 速率进行验证恶意用户检测（告警）
为了实施基于成本的回放治理，团队应该配置 Prometheus Alertmanager 规则，用于检测失控的历史扫描。例如，如果某个特定的客户端 ID 超过了预定义的阈值（如每小时 50 美元的远程获取成本），则触发告警。随后，自动化管道可以动态调用 Kafka AdminClient API 来应用严格的客户端配额，在月度账单生成之前对该违规消费者进行限流。
计算治理：弹性与新一代消费者
虽然控制持久化存储成本至关重要，但下一阶段需要关注的是计算资源的弹性管理。从以往情况来看，为了应对流量激增而扩展 Kafka 消费者组往往会造成严重的运营中断。
在旧版消费者重新平衡协议下，每当组中有新的消费者实例加入时，整个组都会被迫暂停处理。每个消费者都会撤销其分配的分区，并在组领导者重新计算分配结果期间处于空闲等待状态；这种全局性的“世界暂停”事件严重降低了管道的吞吐量。
新一代消费者重新平衡协议（ KIP-848，在 Kafka 4.0 中正式发布）从根本上解决了这一问题。它将复杂的分配逻辑从厚客户端库转移到了服务器端的组协调器。现在，重新平衡操作以增量协作的方式执行。协调器会指示消费者 A 撤销对某个分区的分配，但消费者 B 只有在撤销操作得到显式确认后才会接管该分区。关键在于，两个消费者都不会因此暂停对其他已分配分区的处理。
运营影响：安全的 Kubernetes 自动缩放
将这些协议改进转化为部署决策，从根本上改变了平台团队管理弹性扩展的方式。过去，将 Kubernetes Horizontal Pod Autoscalers (HPA) 与 Kafka 消费者部署相关联是极其危险的。动态缩放会触发连锁的“重新平衡风暴”，导致应用程序瘫痪。随着 KIP-848 的推出，基于 HPA 的消费者缩放终于变得安全可靠。不过，在生产环境中启用该功能前，团队应该验证其特定的工作负载特征和延迟指标的稳定性是否支持可靠的自动缩放。
重新平衡风暴大幅减少：服务器端协调（KIP-848）消除了此前导致 HPA 扩展存在风险的“世界暂停”。不过，对于计划性扩展事件，由代理故障或网络分区触发的重新平衡仍然需要谨慎处理。平台团队应利用类似 Kubernetes Event-Driven Autoscaling（KEDA）这样的操作符来动态地缩放消费者 Pod。通过将 KEDA ScaledObject 直接关联到消费者延迟指标（而非通用的 CPU 利用率），集群能够根据实际积压的任务量进行弹性扩展和收缩。
如果要依赖这一行为，就要严格遵守最低版本要求：消息代理必须升级至 Kafka 4.0 或更高版本，客户端应用程序必须使用兼容的库，并明确启用 group.protocol=consumer 配置。
大规模多租户架构：虚拟集群与传统隔离机制
随着企业流处理平台的规模不断扩大，集群的物理整合已经成为经济上的必然选择。为各个产品团队运行数十个彼此孤立、互不关联的 Kafka 集群，会导致大量的资源闲置浪费。目前正在社区讨论中、尚未被 Apache Kafka 采纳的 KIP-1134（虚拟集群）提案，为解决这一挑战指明了一条架构路径。
大多数组织试图通过强制执行严格的主题命名约定（如 domain.entity.event），并结合复杂的基于前缀的访问控制列表（ACL）来管理多租户环境。在企业级规模下，这种方法难以奏效：在动态变化的开发团队中管理数千条自定义的前缀规则会成为配置负担，而且前缀机制本身并不能有效防止消费者无意中劫持其他团队的消费者组 ID。
KIP-1134（虚拟集群）提出了一种替代方案，即在单个物理集群内建立专用的逻辑命名空间，取代基于弱访问控制列表（ACL）的分离方案以及“每个团队一个集群”的高成本部署模式。下文所述的设计体现的就是该 KIP 提出的架构，而不是已经具备生产环境部署能力的功能。作为内部流数据提供商的大型企业应该密切关注该提案，并在其逐步成熟时进行评估。
根据该设计方案，虚拟实体将映射到底层的物理 UUID，从而使消息代理能够在元数据和命名空间层面强制执行租户边界，这意味着主题名称、消费者组 ID 以及访问控制列表 (ACL) 范围将按虚拟集群进行隔离。请注意，当前的 KIP-1134 提案主要侧重于命名空间和元数据隔离；存储层隔离、按租户配额以及调度保证则不属于当前提案的范围，除非后续修订版本中包含这些内容。
例如，平台团队可以将八个团队专用的 Kafka 集群整合到一个物理部署中，为合规、分析和欺诈检测团队提供一个专用的虚拟命名空间，诸如 transactions 之类的通用主题名可以在这个空间中共存而不发生冲突。然而，KIP 的当前范围主要侧重于命名空间和元数据隔离；在做出整合决策之前，应参考最新的 KIP 讨论帖，确认其是否涵盖存储级隔离、按租户配额或调度保证等功能。
重新定义可扩展性：共享组与队列语义
Apache Kafka 4.2.0 正式将共享组（KIP-932）提升至生产就绪状态。传统上，Kafka 将主题的物理分区数与其最大消费者并行度紧密耦合。如果某个应用程序需要 256 个并发消费者来处理大量涌入的任务，那么架构师就不得不人为地将分区数增加到 256，这是一种众所周知的不良设计模式。
共享组（KIP-932）通过将队列式的语义原生集成到 Kafka 生态系统中解决了这一限制。并发消费者数量不再受分区数量的限制，多个消费者可以独立地处理单个分区的记录，而代理则负责跟踪处理中的记录以及基于租期的交付，它们能够同时处理来自同一物理分区的独立记录。当消费者获取一条记录时，代理会授予它一个可配置锁定时长的排他性获取锁。
实用指南：事件处理与任务分发
实施人员必须仔细评估在何种情况下应该用共享组取代传统的分区扩展策略。
任务分配（采用共享组）
对于分发促销邮件、单图片上传尺寸调整或运行后台任务队列的管道而言，精确的执行顺序并不重要。在这些场景下，共享组（Share Groups）是最佳选择。如果在零售活动期间流量激增，Kubernetes HPA 可以动态地将消费者部署扩展至数百个 Pod，从而处理积压任务，而不需要对主题底层的分区拓扑做任何物理调整。
事件处理（保留经典组）
如果财务数据管道需要按顺序计算实时账户余额，或通过变更数据捕获（CDC）重建数据库状态，那么严格的时间顺序就是绝对必要的。在处理前一笔存款之前处理账户取款，这违反了业务逻辑。显然，为了实现无上限的水平并行处理，共享组牺牲了分区级排序保证。对于高度有序的事件流，经典消费者组仍然是唯一正确的架构选择。
采用风险
共享组（KIP-932）已经在 Kafka 4.2.0 中投入生产应用，但更广泛的配套机制生态系统还在不断演进。例如，上游 Kafka 目前尚未提供完整的一等死信队列（DLQ）支持，包括自动路由无法处理的“毒丸”消息、针对 DLQ 溢出的断路器模式，以及标准化的错误处理标头。针对这些缺失的社区提案正在积极讨论中，但尚未确定具体的实现时间表。作为临时措施，目前采用共享组进行任务分发的工作负载团队应计划实现应用层 DLQ 处理，并关注 Apache Kafka 开发者邮件列表，获取与 DLQ 有关的 KIP 的最新动态。
在此期间，采用共享组的团队必须手动构建应用程序级机制，用于检索和归档失败的消息。为了弥补这一缺口，社区正在积极开展工作：KIP-1191 提议为共享组提供原生的死信队列（DLQ）路由；KIP-1316 引入了断路器机制，当超过死信队列溢出阈值时自动暂停共享组；而 KIP-1317 则强制要求使用处置标头，以便对无法处理的记录进行标准化故障追踪。各团队应密切关注这些提案，直至其成熟并获得采纳。
未来：“无盘化”的岔路口
虽然分层存储解决了存储容量限制问题，但活跃的预写日志仍然与昂贵的本地代理磁盘紧密相连，而且受制于跨可用区复制所产生的巨额网络出站成本。鉴于实现真正的云原生效率需要彻底地解耦状态，Apache Kafka 社区正式批准了 KIP-1150：无盘主题。
由 Aiven 提出的 KIP-1150 将持久性边界完全转移到了云对象存储上。本地代理磁盘不再作为权威数据源，而仅被用作临时缓存。数据将作为“共享日志分段（Shared Log Segments）”直接推送到对象存储中，并由一个全新的外部 Kafka 批处理协调器分配确定的偏移量。
其经济潜力巨大。通过消除跨可用区（AZ）复制和块存储开支，Aiven 的 OpenMessaging 基准测试（OMB）结果表明，对于高吞吐量的入站工作负载，基础设施成本降低了 94% 以上；不过，这些结果反映的是特定的基准测试配置，未必适用于所有生产环境。然而，无盘架构正进入社区评估的下一阶段，其涉及的架构权衡意味着这并非简单的升级，而是一项需要针对每项工作负载进行仔细评估的战略性设计选择。
可付诸行动的迁移信号：观望还是采用
无盘主题（Diskless topics）要求架构设计提前做好规划，技术团队必须搭建一套严谨的、基于工作负载的适配选型矩阵。
何时需要等待（延迟与数据完整性约束）
对于核心事务型应用程序，无盘主题应严格遵守仅作为实验性功能使用的原则。截至本文撰写之时，KIP-1150 仍然处于社区积极讨论状态（ KIP-1150 讨论帖），而且 Kafka 项目管理委员会尚未授予其生产就绪状态。Aiven 自身的路线图文档（KIP-1150 已被接受）确认，无盘主题被定位为一项仍在演进且存在未解决设计依赖关系的功能，而不是经过生产环境验证的特性。
延迟是有代价的：绕过本地磁盘会带来不可避免的性能开销。在 Aiven Open Messaging Benchmark (OMB) 配置下，P99 端到端延迟会激增至约 1.5 到 1.6 秒；开发团队应根据自身的工作负载特征验证这些数据，因为延迟会随分区数量、记录大小和吞吐量而变化。
垃圾回收存在风险：KIP-1150 依赖于“先上传后提交”的模式。在代理崩溃后，孤立且不可见的段会在 S3 中不断积累，这是该模式固有的设计风险，是对象存储架构中任何“上传过程发生崩溃”时可预见的故障模式，而非理论上的担忧。该故障模式在 KIP-1150 邮件列表讨论中有记录，也是 KIP-1163：无盘核心提案背后的核心动因。KIP-1163 提议通过周期性核对循环来检测并回收孤立的分段，但该提案目前仍在社区讨论当中，尚未被采纳。
这些孤立的分段会悄无声息地推高云服务费用，而 KIP-1150 本身并不具备原生的检测机制。目前正在社区讨论当中的 KIP-1163：无盘核心（Diskless Core），提议通过周期性的核对循环来安全地回收这些孤立的分段。然而，那还只是一个未解决的设计依赖项，尚未被上游 Kafka 接受或实现。缺少已经落地的垃圾回收机制是当前存在的设计风险。因此，当前评估 KIP-1150 的团队必须规划外部监控和手动核对流程，以便检测并清除孤立的分段。
数据完整性与“仅执行一次”语义（EOS）：在关于 KIP-1164 的设计讨论中，一个关键且尚未解决的问题聚焦在“仅执行一次”语义上。转向无领导者的数据平面，本质上会使事务状态机去中心化。如果无盘协调器（Diskless Coordinator）需要为大量复用的分区计算最后稳定偏移量（LSO），那么它可能成为严重的性能瓶颈——这是提案中尚未解决的设计风险。如果设计不周，该架构可能会引发脑裂（split-brain）场景或破坏 read_committed 隔离级别。
社区讨论过程中提出了一种缓解方案，建议将“_diskless-metadata”主题定义为一个不可变的事件存储。在这种模型下，协调器的嵌入式 SQLite 数据库将纯粹作为该事件流上的物化视图（投影），维护一个持续更新的活跃生产者 ID（PID）索引，从而在 O(1) 时间内动态地解析 LSO，而不需要扫描无限长的交易日志。请注意，这种基于投影的 SQLite 方案源自社区邮件列表的讨论，并非 KIP-1164 正式规范的一部分，是否会纳入最终设计仍然取决于社区共识。在这些机制正式确立之前，如果团队运行的管道对 EOS 敏感，就必须将无盘主题视为与事务性保证不兼容，并等待该提案进一步完善。
决定何时采用海量数据分析。架构师应立即针对对延迟不敏感的海量工作负载（例如应用程序遥测数据聚合、分布式追踪跨度、全面审计日志记录以及大规模批处理分析）积极试点无盘主题。在这些场景中，以 1.6 秒的延迟代价换取 94% 的基础设施成本削减，是一项极具价值的商业决策。
小结
随着已准备就绪的分层存储将数据保留与磁盘容量解耦、服务器端消费者重新平衡（KIP-848）实现了安全的 Kubernetes 自动缩放，以及共享组（KIP-932）释放了与分区无关的并行处理能力，Kafka 已经为云原生流式处理平台打下了若干基础性的支柱。与此同时，诸如 KIP-1267（成本归因）和 KIP-1134（虚拟集群）等提案，则明确表明社区致力于解决财务治理和多租户隔离方面的剩余缺口，尽管这些功能仍然在积极讨论当中，尚未投入生产环境。
因此，最恰当的理解是，“经济型操作系统”是一种正在形成的架构模式而非成品。在这种架构模式中，成本意识、弹性计算和租户隔离融合为一种统一的设计理念。在当前已经生产就绪的 KIP 的支持下，企业已经可以构建由 Prometheus 驱动的成本分摊管道，依靠 Kubernetes 自动缩放器来应对流量峰值，并针对任务分发工作负载有选择地应用队列语义。
对于严格地将运行稳定性和上游数据完整性置于首位的团队而言，经典的分层存储结合 FinOps 治理仍然是经过验证且可投入生产使用的方案。无盘方案（KIP-1150：无盘主题分区、KIP-1176：通过仅远程主题实现的无盘代理，以及 KIP-1183： 无盘复制）有望进一步重塑流处理的底层经济模式，但这些相互竞争的设计方案也凸显出，社区尚未就单一方案达成共识。通过将工作负载与正确的存储和计算范式进行精准匹配，并在采用前跟踪每个 KIP 的成熟度，架构师可以确保其事件驱动架构既能经受住首席财务官的审查，又能满足行星级基础设施不断演变的需求。
原文链接：https://www.infoq.com/articles/architecting-cloud-native-kafka/
