其他
降本增效：Grab 如何在亚马逊云科技上将 Kafka 消费者流量成本降到零
Kafka 2.3 引入了将 Apache Kafka 消费者连接到相同可用区域（AZ）代理节点的能力，Grab 利用这一能力重新配置了消费者，将亚马逊云科技上的流量成本降低为零。这一更改大大降低了在亚马逊云科技上运行 Apache Kafka 的基础设施总成本。
Grab 以 Apache Kafka 为中心创建了一个流数据平台，支撑公司所有的产品。遵循 Kafka 最佳实践，他们的初始配置为每个 Kafka 分区三个副本，横跨亚马逊云科技区域中三个不同的可用区。负责该平台的团队观察到，跨 AZ 流量占了他们 Kafka 平台一半的成本，因为亚马逊云科技对跨 AZ 数据传输收费。
对于初始设置的成本，Fabrice Harbulot 和 Quang Minh Tran 的看法如下：
这种设计的问题在于，它会产生惊人的跨 AZ 网络流量。这是因为，在默认情况下，Kafka 客户端只与分区 leader 通信，而分区 leader 有 67% 的概率驻留在不同的 AZ 中。
跨 AZ 流量包括新发布的消息、代理之间的数据复制和消费者获取的消息。
默认消费者配置，消费者从分区 leader 获取数据（图片来源：Grab 工程博客）
从 Apache Kafka 2.3 开始，可以将消费者配置为从分区副本中获取数据了。这样，如果消费者只从同一 AZ 中的代理获取消息，就不会产生数据传输成本了。
这个特性要求 Kafka 代理和消费者都知道其所在的 AZ。对于 Kafka 代理，团队会使用 AZ ID（az1、az2、az3 等）配置 broker.rack 。AZ ID 与 AZ 名称（1a、1b、1c 等）不同，因为 AZ 名称在亚马逊云科技账户间不一致。他们还将参数 replica.selector.class 的值设置为 org.apache.kafka.common.replica.RackAwareReplicaSelector。
在消费者端，团队更新了内部 Kafka SDK，基于 EC2 主机元数据用 AZ ID 配置 client.rack 参数，为的是应用程序团队可以通过导出环境变量来启用该功能。
自定义消费者配置，消费者从最近的副本获取数据（图片来源：Grab 工程博客）
在某些服务上应用新设置后，团队观察发现，跨 AZ 流量成本下降，并且有一些值得注意的副作用。首先，端到端延迟最多增加了 500 毫秒。考虑到大多数消费者从副本获取消息，这也是意料之中的。延迟增加是由复制时间导致的。理论上，任何对延迟敏感的数据流都应该始终从分区 leader 获取数据，即使那样会产生额外的成本。
其次，在代理维护（停机）时，直接从副本获取消息的消费者可能会遇到代理不可用的情况，因此，它们应该等待 / 重试，直到同一 AZ 中的代理恢复在线。最后，团队观察到，代理的负载与跨 AZ 的消费者数量有关。这意味着，消费者的均匀分布对于确保代理的负载平衡至关重要。
原文链接：
https://www.infoq.com/news/2023/07/grab-apache-kafka-aws-cost/
大模型的出现从根本上改变了数字化转型的赛道，在 InfoQ《超级连麦. 数智大脑》直播中，富滇银行数字金融中心副主任李涛深入探讨了自身对于 AIGC 在金融领域创新方面的思考，分享了银行数字化发展的历程及背后的架构演进。识别下方二维码或关注「InfoQ 数字化经纬」公众号，即可阅读全文。