货拉拉消息中间件之Kafka架构演进

　　随着货拉拉业务的快速增长，全自动液体软包装机电气原理图Kafka集群流量和负载也呈现出明显的增长趋势。作为货拉拉业务核心的消息中间件，Kafka架构也做了相应架构演进。本篇文章将会重点介绍过去、现在kafka架构的演进历程。

　　02 Kafka架构演进

　　2.1、kafka架构1.0 - 存算一体　　

　　在2020年之前，货拉拉kafka部分集群仍是计算和存储一体架构，经常出现因本地磁盘异常导致整个集群抖动的问题

　　2.2、 kafka架构2.0 - 存算分离　　

　　当前Kafka集群已全部采用计算和存储分离架构。

　　为充分利用计算存储分离架构特性，Kafka集群架构做了相应的架构改造，从而kafka集群在稳定性、资源效率和运维效率得到了进一步提升。

　　2.2.1、 多租户架构

　　当前kafka集群已大规模多租户架构部署，即针对不同流量场景配置不同实例规格，从而使kafka资源利用率极大提升，同时kafka集群具备了一定故障隔离能力，避免因为单个Topic异常读写进而影响整个集群稳定，将故障爆炸半径有效控制在单租户内；

　　一句话总结：Kafka集群多租户架构部署 即提高集群资源利用率，又提高kafka集群稳定性。　　

　　2.2.2、 容量瓶颈自动感知

　　当前Kafka集群有数百个节点，在大规模多租户架构部署下，必然使用不同的实例规格。每个实例规格支持的网络带宽，云盘吞吐也有所不同。

　　据统计，当前货拉拉kafka集群节点所使用的ECS实例规格，有60+不同的实例类型和规格。部分实例如表格：　　

　　云盘带宽换算：n Gbit/s = n * 1000/8 MB/s

　　ECS实例，重点关注2个指标：

　　1网络带宽流量上限，即NetIN，NetOUT；

　　1kafka海量数据需要落盘，ECS实例能支持的读写云盘的最大上限；

　　挑战 1：

　　面对众多的实例类型和规格，电加热器电气原理图如何判断当前的流量是否有容量风险？

　　1.当前网络流量即NetIn/NetOut 是高还是低，该实例网络带宽上限是多少？

　　2.当前云盘即磁盘读写流量是高还是低？该实例支持的上限又是多少？　　

　　挑战 2：

　　kafka集群因为多租户的存在，同一集群具有不同的实例规格，如何配置不同告警，也是DBA面临的棘手问题？

　　当前DMS告警系统是按照集群纬度配置的告警；如何配置节点纬度告警，将是无比的繁琐且不可持续。

　　解决方案：

　　1. 首先确定ECS实例支持的网络带宽和云盘吞吐上限？　　

　　DMS平台收集不同ECS实例规格并确认网络带宽，由DBA维护元数据信息；如图：　　

　　2. DMS监控系统实时计算；

　　DMS监控系统通过API实时获取每个ECS实例信息和云盘信息（云盘大小，等级，挂载方式等）；结合DBA维护的元数据信息，实时计算出该ECS实例能支持的网络带宽和云盘吞吐上限。

　　因为ECS实例规格和云盘等级，大小都会随时变化的，必须实时计算其容量上限；

　　3. DMS告警系统改造支持；

　　DMS监控通过改造，支持集群上限百分比告警配置。　　

　　

　　DMS监控系统已完成对自建组件数百台ECS流量百分比告警支持；

　　2.3、kafka架构3.0 - 基于云原生的弹性架构

　　2.3.1、背景

　　当前部分Kafka集群如安全，大数据等海量数据写入的集群，所使用的云盘往往是整个集群的性能短板。　　

　　挑战 1：

　　当前Kafka集群全部使用云盘，有PL0，PL1，PL2不同等级，不同等级云盘有不同的吞吐上限；

　　Kafka一个核心的作用就是“削峰填谷”，经常面对突发的高流量冲击，而所使用PL1，PL2云盘有严格的吞吐上限；这样就会存在云盘被写满的风险，进而影响到集群的稳定性。

　　挑战 2：

　　kafka集群其中一个节点当前使用云盘PL1（吞吐上限350MB/s），云盘读写高峰期流量峰值是：285MB/s；云盘吞吐使用率达到81%（DBA设置的安全水位为70%，需要预留30%buf）。为保证集群稳定，必须将云盘等级从PL1 升级到PL2，但是云盘费用增幅100%+，大促期间峰值使用率38%，平日使用率不到20%，资源能效不好。

　　如何在保证集群稳定性的同时，有效降低成本，让集群更具备弹性能力，也是DBA需要思考的问题？

　　2.3.2、解决方案

　　基于云原生的弹性架构

　　AutoPL云盘可以理解PL1--N 无数个等级的云盘，通过预配置性能，设置常态化云盘能够支持的吞吐上限。

　　AutoPL云盘性能 = 基准性能（即PL1为基准） + 预配置性能（即增加的云盘吞吐） + 性能突发 （即支持偶发的大流量）　　

　　2.3.3、弹性架构收益

　　1. 稳定性增强

　　AutoPL 具备一定的“性能突发”能力，大大保证集群的稳定性，突破PL1，PL2云盘吞吐上限，保证集群安全稳定；

　　2. 资源能效提升

　　AutoPL 云盘有效解决了PL1，PL2，PL3只有3个等级的问题，通过配置不同的“预配置性能”，个性化设置不同的云盘吞吐上限，大大提高云盘的使用率，大幅度降低了云盘使用成本。

　　如：5T云盘从PL2 改成AutoPL，费用从3556元/月 --> 1830元/月，减少1726元/月，降幅50%；

　　3. 运维效率提升

　　DBA可以根据Kafka的实际需求快速调整云盘性能，无需进行复杂硬件升级或替换操作，提高了管理效率。

　　在后期Kafka集群运维规划中，可以根据业务流量预测未来的性能需求，并自动调整AutoPL云盘性能，确保Kafka集群能够持续满足业务需求的同时，有效降低成本。

　　03 总结

　　通过从存算一体到存算分离，再到基于云原生的弹性架构的演进，Kafka集群不仅提升了资源利用率和稳定性，还增强了故障隔离能力和弹性扩展能力。

　　未来还会随着业务发展和新技术更新迭代，对kafka集群架构做不断的演进，以保证集群的稳定和高效。