写点什么

阿里云研发工程师刘睿:阿里云消息生态及最佳实践

作者:云布道师
  • 2022-11-16
    浙江
  • 本文字数:3131 字

    阅读完需:约 10 分钟

阿里云研发工程师刘睿:阿里云消息生态及最佳实践

2022 年 9 月 24 日,阿里云用户组(AUG)第 12 期活动在厦门举办。活动现场,阿里云消息中间件研发工程师刘睿,向参会企业代表分享了阿里云消息生态及最佳实践。本文根据演讲内容整理而成。


众所周知,消息中间件作为现代软件体系中的底层基础软件,和数据库一样广泛应用于各种场景中。比如大数据 ETL、日志处理、IoT 的一些场景以及事件分发,还有 SaaS 集成等这些各种各样的场景里面都需要用到消息中间件。

阿里云消息产品系列


消息全家桶:简单、稳定、开源

面对如此众多的消息中间件应用场景,阿里云在消息产品这一块也有非常丰富的产品矩阵。其中,有主打业务消息和订单交易场景的 Rocket MQ;有在国际上知名度也比较高、主打业务日志流式处理的数据通路消息产品 Kafka;还有其他一些面向细化场景业务的产品,例如对标开源,作为业务消息选型补充的 Rabbit MQ,面向 IoT 领域的消息队列 MQTT,以及轻量版的 Rocket MQ——消息服务 MNS。这些产品,组成了阿里云的比较完整的消息中间件产品的矩阵。


阿里云的消息中间件具备较强的技术优势和核心竞争力,体现在很高的 SLA,最高达到 4 个 9,支持异地多活/灾备、故障秒级恢复、高吞吐和低延时的能力,并且支持海量的连接、百万队列、分级存储和 Serverless 弹性能力。


这里重点分享的消息队列 Kafka,作为一款全托管的 kafka 服务包括生态相关的云产品,解决了非常多的用户痛点,是大数据生态领域中使用率非常高的产品,其主打的价值是内核更加的稳定、成本更加的低廉,同时具备更高的性能。


企业级大数据消息通道:消息系列 Kafka

消息队列 Kafka 版集成了更丰富的生态,不仅是兼容开源的生态,还对接融合了各种阿里云内部产品的生态。具体表现在:

  • 页面交互上,我们的控制台会有非常多且直观的功能,可以让用户使用一键迁移等生态功能,通过 Connector 对接其他云服务例如 RDS。研发同学也会持续维护更新 kafka 服务版本,让用户能够使用到最新的开源对标能力,同时也会持续做好内部优化版本,不断修复各种开源的问题,让用户有更好的使用体验;

  • 支持服务编排、阿里云内部 Tag 的资源管理能力,以及可观测的一些基本能力;

  • 优化模块,涉及到底层的技术优化,比如分级存储,多盘的支持等;

  • 完善的运维底座,可以做到自动化的巡检运维,支持自动化专家诊断。

技术优化


自研双引擎支持

本节将简单介绍一些消息队列 Kafka 的技术优化。消息队列 Kafka 同时支持阿里云自研的存储引擎和开源存储引擎,可以解决用户的痛点,如:开源劣势、兼容性担忧、支持 Topic 粒度使用不同的存储引擎。


开源自建 Kafka 很难解决的一些问题可以通过我们的云 Topic 引擎去支持。云 Topic 引擎的优势包括更好的可用性、弹性和更低的成本;研发同学通过优化引擎解决开源的生存 Bug,还可以全面兼容开源的不同版本,包括 0.10 版本、2.2 版本、2.6 版本等;以及支持不同引擎 Topic 混用,引擎设置粒度细化到 Topic 级别。


刷盘机制优化

其次是刷盘机制的优化,对于开源 Kafka 来说,他的 ISR 机制支持多副本的能力。但是这个能力需要在不同的 Broker 节点上去复制和拷贝数据,要占用相当的一部分网络流量。消息队列 Kafka 版内部做了一些优化,包括和底层的阿里云盘,盘古文件系统这些做了深度的整合优化,把这个多副本的能力直接做到底层,这样可以优化阿里 Kafka 的刷盘效率,降低磁盘使用和成本,并且提升了性能,同时扩容稳定性也得到了保障,数据可靠性可以达到 8 个 9。


分级存储

还有一项比较重要的技术优化是分级存储。消息队列 Kafka 通过结合底层 NAS 等存储服务,使用分级存储降低成本,同时提供海量存储容量的能力,允许用户自定义时长的消息保存能力,大大延长了消息保留时间,支持保存长达数月的时间。同时,支持冷热数据分离,保证新的消息读写性能不受到影响。


巡检组件

提到自动化运维,必然少不了巡检组件。巡检组件保证了整个服务的稳定性。巡检系统会及时地检查所有集群有没有潜在的问题和故障,然后快速进行自我恢复。自我恢复一般是个秒级响应切换的过程,能够保证整个集群在运行中保持稳定,对用户来说,是保障高 SLA 的基础。


容灭方案

消息队列 Kafka 也具备完善的容灾方案,包括如果用户购买了专业版,部署的时候可以选择不同的可用区,对应不同的机房。当其中的一个机房出现故障,容灭方案会自动将这个服务熔断并摘除,将服务的流量切换到其他可用区,这样就可以达到全集群的自动切换,且切换时间很短,同时保证消息不会丢失。解决了开源可用性和可靠性的矛盾问题。

生态支持


Connector 组件:支持配置化转储到大数据相关产品

本节介绍消息队列 Kafka 的生态支持,说到生态,就不得不提到 Kafka Connector 组件。消息队列 Kafka Connector 支持配置化地设置转储任务将 Kafka 数据连通到其他大数据相关云产品。


用户只需要简单地配置后,就可以将上游的数据,比如说从 MySQL、Logstash 进来的数据,经过 Kafka 然后通过 Kafka 的 Connector 组件运维调度 Connector 运行时任务,自动地对接到下游,比如 OSS、FunctionComputer、Flink 、Hbase 等这些下游的计算,或者是存储分析的服务,可以自动地做到免运维的全托管的数据对接。还支持包括像 ETL 轻量化数据清洗转储,都有非常成熟的行业解决方案。


ETL 组件:轻量化消息流处理

关于 ETL 服务组件,它是轻量级消息流处理系统,可以通过接收上游采集的客户业务数据,例如生产数据、数据库的数据、物联网设备的 IoT 时序数据,进入到 Kafka,通过 Kafka 的 ETL 功能,用户可以自定义数据处理的函数,通过配置化的方式填写到 ETL 页面中。函数会自动的对某一些 Topic 的数据进行清洗和数据的流转,将这些数据通过这个加工模板/算子传到下游的目标数据源,例如 RDS、OSS、Maxcompute 这些下游的服务,自动实现数据的清理、清洗、流转的功能。

最佳实践 & 场景案列


发送最佳实践

本节介绍 Kafka 客户端的一些最佳实践。首先关于 Producer 这里,有经验上的比较普适的一些建议,如配置的参数优化、配置的计算选取。建议非业务需要不要使用 Key,因为如果使用 Key 的话,有可能因为 Key 的分布不均导致一些分区写入热点问题,因为 Key 决定了消息写入到哪一个分区,为了减少碎片化写入,更好地负载均衡,建议可以使用粘性的分区策略,以及分区数使用控制台创建 Topic 时推荐的值。


消费最佳实践

关于消费者的最佳实践,通过文档建议的参数调优方法,可以尽量减少发生 Rebalance 的可能,提高消费能力。具体的典型应用场景,像消息中间件发布订阅消息,这是它的基础能力。在跟踪网站的应用场景中,可以做到发布到特定的 Topic 和订阅 Topic,做到数据实时的处理和监控。像数据监控、日志转储、聚合日志提交,这些都可以基于现有的开源组件来实现,例如使用 File beat 开源组件,都可以直接做到基于 Kafka、开源组件这一套的能力去快速地实现日志采集分析。


典型场景


Kafka 也可以应用到反作弊的实时分析场景中,可以通过 Kafka 作为消息的中间流转组件,由上游的 FileBeat 和 LogStash 采集游戏服务的日志。把消息路由到 Flink 实时去做计算,然后把这个计算后的数据存储到 ES 或者 Click house。把 Kafka 的数据流转到一些下游的风控服务,最后反过来形成闭环,对游戏服务的反作弊分析进行处理。

MQTT 和 Kafka 一起构建的车联网,也是有一套比较成熟的体系,可以通过 Kafka 作为消息中转的总线,把不同的 IoT 数据流转到下游的各种服务。


从上述应用场景中我们可以看到,在 Serverless 趋势下的现代化软件架构体系中,消息队列 Kafka,包括其他的消息产品,在云服务 Serverless 化的过程中成为了非常重要的一环。也希望大家在将来的 Serverless 实践中多体验和使用消息中间件 Kafka 云产品,为我们提出宝贵建议。(正文完)


阿里云研发工程师刘睿:阿里云消息生态及最佳实践

发布于: 刚刚阅读数: 3
用户头像

云布道师

关注

大道至简、教学相长、知行合一 2022-11-07 加入

聚焦“云&科技”领域,每日收获前沿技术与科技洞见。

评论

发布
暂无评论
阿里云研发工程师刘睿:阿里云消息生态及最佳实践_阿里云_云布道师_InfoQ写作社区