trang chủ chủ đề library logo thư viện của tôi
thêm

vivo超大规模消息中间件实践之路

如果无法正常显示，请先停止浏览器的去广告插件。
分享至：
1. vivo超大规模消息中间件 实践之路 罗明波 | vivo互联网中间件架构师 刘润云 | vivo互联网中间件架构师
2. 01 02 03 vivo 超大规模消息中间件 实践现状 vivo 大数据侧消息中间件 最佳实践 vivo 在线业务侧消息中间件 最佳实践
3. 技术选型
4. 使用现状 组件名称 业务场景 大数据业务 在线业务 接入项目 300+ 300+ 业务规模 Topic数量10000+ 接入1000+服务 数据规模 150000亿+/天 100亿+/天 可用性 99.996% 100% 核心指标 单机日均消息处理200亿+/天 发送平均耗时 < 1ms
5. 01 02 03 vivo 超大规模消息中间件 实践现状 vivo 大数据侧消息中间件 最佳实践 vivo 在线业务侧消息中间件 最佳实践 Kafka在超大数据规模下的最佳实践 Kafka在超大数据规模下面临的新挑战 大数据侧消息中间件未来规划
6. Kafka简介 Kafka是由Apache软件基金会开发的一个开源流处理平台，是一种高吞吐量的分布式发布订阅消息系统 它可以处理消费者在网站中的所有动作流数据 具有高吞吐、低延迟、高并发、高可用、高可扩等特性 是大数据生态体系建设中不可或缺的重要组件之一 2010 2011 2012 开源 Apache孵化 Apache顶级项目
7. 超大数据规模场景下面临的挑战 如何规划资源隔离保证核心业务、 高优业务、一般业务互相之间不受 相互影响？ Q01 Q02 如何保证集群内部节点间流量均衡， 降低单节点和部分节点流量差异太 大带来的资源浪费？ Q04 集群长期运行，客户端版本多样， 如何持续保证集群的高可用性？ 超大数据规模场景下 面临的挑战 如何进行限流保障集群的稳定性并 尽可能降低对业务可用性的影响？ Q03
8. 资源隔离 资源利用率 运维成本 隔离粒度
9. 流量均衡 Kafka集群的流量均衡本质是Topic Partition 分散均衡，所以Kafka集群流量优化的本质是分区均衡算法的优化 磁盘容量 磁盘容量 CPU容量 Broker-0 CPU容量 创建topic 入出流量 Broker-1 入出流量 Topic分区扩展 分区均衡算法 分区均衡算法 Broker信息 Broker信息 分区分布计划 Broker-2 Broker-n Topic副本扩缩容 机架信息 分区分散均衡 机架信息 副本分散均衡 Leader分散均衡 磁盘均衡
10. 流量均衡 资源组内不同节点流量平均偏差从200MB/s以上 下降到 50MB/s 以内。极大提升资源利用率 Before 优化前 After 优化后 均衡前节点间流量偏差200M/s。 存在严重的资源浪费 均衡后，节点间流量差异在 50M/s以内。极大提升了集群的 资源利用率和Kafka集群稳定性
11. 流量均衡 流量均衡二期上线后，资源组内不同节点流量平均偏差从50MB/s以上 下降到 10MB/s 以内。 Before 优化前 After 优化后 均衡前节点间流量偏差50M/s， 存在一定程度的资源浪费。 均衡后，节点间流量偏差在10M/s 以内，均衡效果比较明显。
12. 智能动态限流 MQSERVER 资源组 项目1 项目1 10M/50M -30 10M/50M Topic A +30 producer 项目2 +30 资源利用率 限流粒度 consumer 项目2 Topic B 100M/110M -30 +30 100M/110M +30 Topic N 项目n 项目n 10M/50M 10M/50M -30 网卡入流量 -30 网卡出流量 broker broker broker 生产/消费流量指标采集 消费限流告警 生产限流告警 告警配置 告警检测 durid 可用性 限流阈值 限流告警回调 更新kafka配置 更新阈值 kafka platform kafka monitor MySQL
13. 智能动态限流成果 02 提升集群应对 用户流量突变能力 提升 资源利用率 智能化自动调整 限速阈值 无需人工介入 尽可能减少 限速对业务可用性 的影响
14. 集群治理 节点流量偏差治理 topic数据倾斜治理 及时发现资源组流量偏差； 自动开启负载均衡，无需人工巡检； 提升业务消费性能与应用稳定； 避免数据倾斜打挂集群服务节点； topic元数据治理 集群治理 清理集群中无效的topic及消费者； 减轻大量无效topic对集群造成压力； topic超大分区治理 避免超大分区影响集群负载均衡效率； 避免超大分区超单块磁盘的读写能力； topic消费延迟治理 提醒用户及时调整消费能力； 避免超大分区打挂单节点，造成故障；
15. 能力矩阵 业务层 产品 平台层 商城业务 AI服务平台 日志中心 VPUSH 头条资讯 浏览器业务 短视频 风控系统 应用商店 270+业务接入 工单系统 资源隔离 产品 能力层 机架感知 Topic管理 个人中心 智能动态限流 资源扩缩容 数据mock 搜索广告 权限检测 常规运维白屏化 用户限流告警 Topic流量突变告警 无效topic治理 超大分区topic治理 消费延迟告警 主机指标异常告警 数据倾斜topic治理 资源组流量均衡治理 宕机/服务重启告警 Leader实时监控告警 消费延迟治理 智能扩容评估 统一治理指标采集 Broker级智能动态限流 流量均衡 弹性伸缩 数据压缩 多平台联合故障感知告警
16. 01 02 03 vivo 超大规模消息中间件 实践现状 vivo 大数据侧消息中间件 最佳实践 vivo 在线业务侧消息中间件 最佳实践 Kafka在超大数据规模下的最佳实践 Kafka在超大数据规模下面临的新挑战 大数据侧消息中间件未来规划
17. Kafka在超大规模消息处理下面临的新挑战 kafka计算与存储强绑定，以分区为存储中心的架构导致流量无法快速转移 资源利用率低 无法快速响应业务增长 业务长期都处于流量不均衡的状态，资源利用率低， Kafka集群扩/缩容需要经历漫长的数据迁移，无法 一旦进行流量均衡则需要迁移大量数据，导致均衡 满足业务快速扩/缩容需求，扩容一般以天或周为单位， 周期长，以周为单位 且数据迁移一定程度影响到集群稳定 痛点 故障恢复慢 历史数据消费故障率高 硬件故障影响大，恢复周期长，缺副本业务风险高， 普通机械磁盘成为Kafka性能瓶颈，一旦大量消费历 频繁的硬件故障严重影响Kafka集群稳定，每周平 史数据或者数据同步时，某一个分区的数据压力集中在 均2次硬件故障，更换硬件数据恢复周期较长 单块磁盘，容易引发故障 使用高性能硬盘又存在成本问题，且无法保留太长时间 的数据
18. 01 02 03 vivo 超大规模消息中间件 实践现状 vivo 大数据侧消息中间件 最佳实践 vivo 在线业务侧消息中间件 最佳实践 Kafka在超大数据规模下的最佳实践 Kafka在超大数据规模下面临的新挑战 大数据侧消息中间件未来规划
19. Pulsar简介 Apache Pulsar 是 Apache 软件基金会顶级项目。 是集消息、存储、轻量化函数式计算为一体的下一代云原生分布式消息流组件。 采用了计算与存储分离架构设计，支持多租户、持久化存储、多机房跨区域数据复制。 具有高吞吐、低延时、高并发、高可扩，高可用等特性。 2012 2016 2018 诞生 开源 Apache顶级项目
20. Pulsar核心优势 分区数据分散存储 无状态的broker 提升资源利用率 计算与存储分离 快速响应业务增长 收益 节点对等 提升服务可用性 分层存储 以Segment为存储中心 海量数据存储 以Segment为存储中心的架构令 资源利用率提升至少>10% 扩缩容耗时从 秒级故障恢复 消费某个分区的数据可以从多台机器上 集群规模越大提升越明显 天级下降到秒级 实时流量均衡 进行拉取，降低了单块磁盘的压力 分层存储解决了较长历史数据消费问题 Pulsar相对于kafka来说，在服务可用性、资源利用率、数据冷热分层存储方面明显优于Kafka
21. 大数据篇消息中间件未来规划 未来 2024 成熟运营 2022 2021 项目启动 Pulsar调研 稳定性建设 具备万亿级消息处理能力 2023 打造具备二十万亿级消息 处理能力的Pulsar集群 能力进阶 流批一体探索 打造具备十万亿级消息 处理能力的Puslar集群
22. 01 02 03 vivo 超大规模消息中间件 实践现状 vivo 大数据侧消息中间件 最佳实践 vivo 在线业务侧消息中间件 最佳实践 vivo基于RocketMQ消息平台 高可用保障实践 vivo从RabbitMQ平滑迁移到 RocketMQ实战介绍 在线业务消息平台未来规划
23. RocketMQ简介 RocketMQ是阿里巴巴2012年开源的 低延迟、高并发、高可用、高可靠的分布式消息中间件 为万亿级消息处理而设计 具有海量消息堆积、高吞吐、可靠重试等特性 2012 2016 2017 开源 Apache孵化 Apache顶级项目
24. RocketMQ集群全球分布 印度 北京 德国 100亿+ 全球分布 新加坡 俄罗斯 2021年开源引入并完成高可靠、平台化建设 当前日均消息
25. vivo基于RocketMQ消息平台高可用保障实践 消息中间件系统高可用如何落地? 集群架构和平台 系统架构 运维能力平台化 监控大盘与告警能力
26. RocketMQ集群双机房热备架构 BrokerController 双机房部署各多个broker组，业务默认连接本机房 BrokerController 部署模式 角色变更 状态/offset上报 broker-a-master 本机房broker异常客户端将快速切换 状态监控处理 Zookeeper 角色监听 Broker主从分钟级切换 状态/offset上报 broker-b-master broker-a-slave broker-b-slave 机房A 机房B 优势 劣势 高可用部署架构：双机房热备 无跨机房消息复制流量，降低专线依赖 可降低业务发送延时，提升性能 Broker需要冗余一定的buffer
27. 基于RocketMQ消息中间件平台系统架构 rebalance模块 实现broker的自动负载均衡 monitor模块 用于监控指标采集上报 recover模块 支撑流量降级与恢复 live模块 用于集群探活 建设基于gRPC协议的 RocketMQ-SDK与集群交互
28. RocketMQ运维能力平台化 配置管理平台化 运维操作平台化 集群维护平台化 确保集群内配置统一，避免人工 通过读写权限控制可以快速进行 broker节点分配、NameSrv 到机器操作 流量摘除等操作 集群分配等在平台简便完成
29. RocketMQ平台监控告警能力 构建监控大盘信息，快速确认集群的实时运行状态，方便巡检。 丰富的监控告警指标，及时发现问题。
30. RocketMQ平台监控告警能力 构建监控大盘信息，快速确认集群的实时运行状态，方便巡检。 丰富的监控告警指标，及时发现问题。
31. 01 02 03 vivo 超大规模消息中间件 实践现状 vivo 大数据侧消息中间件 最佳实践 vivo 在线业务侧消息中间件 最佳实践 vivo基于RocketMQ消息平台 高可用保障实践 vivo从RabbitMQ平滑迁移到 RocketMQ实战介绍 在线业务消息平台未来规划
32. RabbitMQ/RocketMQ对比分析 RabbitMQ问题分析 RocketMQ技术特性分析 1. 集群无法自动负载均衡 2. 脑裂风险 3. 网络故障无法自动恢复 1. Broker采用多主多从、同步双写部署架构，Topic分布 在多个Broker中实现负载均衡 1. 集群整体性能较低，并且无法水平扩展 2.读取堆积消息性能快速下降 1. Topic多Broker分布，实现水平扩展 2.读写分离设计，从节点读取历史数据，降低对消息写入的 性能影响 容量 1.堆积到千万后集群性能下降，甚至无法读写 1.消息存储在磁盘文件中，磁盘空间容量即为集群的消息 存储容量 功能 特性 1. 不支持消费异常延时重投递 2. 无消息轨迹、事务消息、顺序消息等特性 1.支持消息轨迹、事务消息、局部有序消息等功能特性 可用性 性能
33. 在线业务平滑迁移方案对比 消息双写双消费 消息网关代理 RabbitMQ 架构 简图 Producer-Client 双写 双消费 Producer-Client Consumer-Client RocketMQ 发送 AMQP消息网关 Consumer-Client 代理生产消费 RocketMQ 消费 优势 1.平台侧开发难度较低 1. 业务流量切换无感知 2.借助消息网关可以实现更丰富功能特性 劣势 1. 所有业务需要升级客户端 2. 需要确保消息双写成功，带来额外延时和损耗 3. 需要业务控制消费逻辑，避免双消费产生问题 1. 消息网关逻辑较复杂，开发难度较大 2. RocketMQ原生特性如事务消息无法使用
34. AMQP消息网关架构 平滑迁移 构建MQ-Proxy模块解析AMQP协议请求 代理客户端的生产消费 元数据管理 Exchange/Queue绑定关系 由Meta服务维护，并可动态感知 功能特性丰富 扩展AMQP协议 支持了局部有序、批量消费等能力
35. AMQP网关之元数据概念映射 为了更好整合RabbitMQ和RocketMQ，我们对它们的元数据概念做了一一对应 RabbitMQ概念 Exchange Queue RoutingKey /BindingKey - VirtualHost 概念说明 RocketMQ概念 接收来自生产者的消息并将消息路由到 Queue 的组件 存储消息的缓冲区，供消费者消费消息 生产者在向Exchange发送消息时，需要指定一个Routing Key来设定该消息的路由规则 Topic 消息主题，消息一级分类 Group 一类Producer或Consumer，这类Producer或Consumer 通常生产或消费同一类消息，且消息发布或订阅的逻辑一致 消息头参数 消息二级分类 Tag 用作逻辑隔离，不同VirutalHost之间的 Exchange 和 Queue 逻辑隔离，互不干扰 概念说明 Namespace 基于RoutingKey消息过滤由broker和消息网关配合实现 RoutingKey含有匹配过滤，Tag仅能通过相等匹配 逻辑隔离Topic/Group 1KB 5KB 10KB 发送TPS/时延 9W+/<5ms 6W+/<5ms 3W+/<5ms 推送TPS/时延 6W+/<5ms 5W+/<5ms 3W+/<5ms 8C16G机器消息网关性能
36. 业务迁移进展 100.00% 86.31% 90.00% 99.43% 99.64% 80.00% 70.00% 60.00% 49.07% 50.00% 40.00% 21.57% 30.00% 20.00% 10.00% 2.72% 0.00% 在半年内完成1000+服务的业务流量无损迁移，迁移过程无故障，业务无感知 100%
37. 01 02 03 vivo 超大规模消息中间件 实践现状 vivo 大数据侧消息中间件 最佳实践 vivo 在线业务侧消息中间件 最佳实践 vivo基于RocketMQ消息平台 高可用保障实践 vivo从RabbitMQ平滑迁移到 RocketMQ实战介绍 在线业务消息平台未来规划
38. 在线业务消息平台未来规划 存算分离架构 容器化部署 POP消费模式 快速弹性伸缩 新特性引入 基于gRPC协议实现 统一消息网关 平台能力提升
39.

trang chủ - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.3. UTC+08:00, 2024-11-30 15:23
浙ICP备14020137号-1 $bản đồ khách truy cập$