腾讯云日志服务通往云原生时代的破局之道

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1. 腾讯云日志服务通往云 原生时代的破局之道 腾讯云 王国梁
2.
3. 自我介绍 王国梁 · 腾讯云CLS • • • 腾讯云CLS研发负责人,腾讯 OpenTelemetry Oteam PMC, OpenTelemetry社区贡 献者、前开源Kubernetes 社区成员( kube-scheduler维护者和Reviewer之一)。 目前负责腾讯云日志服务平台(CLS)核心系统设计及研发。关注日志、监控、链路追 踪等可观测性领域。 曾负责美团虚拟化、容器化调度系统和云原生化的技术改造,主导Kubernetes和云原生 应用管理在美团的从0到1的大规模落地。
4. 大纲 • • • • 企业视角云原生技术改造和应用现代化的意义 传统应用架构案例:腾讯云日志服务老旧系统问题分析 云原生化过程遇到的典型挑战和应对策略 如何给一架高速运行的“飞机”更换引擎?
5. 腾讯云日志服务介绍
6. 日志服务云原生化的业务背景 • • • • • 规模大且性能要求高:十万亿级日志量/天、百毫秒级写入延迟、百亿 条日志秒级检索 峰值大且流量突发频繁:高峰GB/秒突发流量写入 延迟和稳定性要求高:秒级(99.9% 3s以内)日志可见、写入可靠性 要求高 功能需求迭代要求高:来自客户需求、产品升级、竞品压力几乎每周 都有发布上线,对迭代效率要求高 质量问题突出:大小故障频发,技术团队不仅要迭代新功能还要一直 救火,团队压力大
7. 企业视角来看云原生技术改造的意义 云原生技术的“三个代表” 最先进技术生产力的 发展方向 企业产品竞争力的 发展要求 云原生技术(容器、K8S等)代表了最 先进技术生产力,技术成熟并采用广泛 快速扩张是目前新产品的典型特点,爆 款产品都有着突发性,如果不能抓住机 会很快会被淘汰 基础设施和技术理念的陈旧会导致无法 满足如今的业务需求,并最终成为产品 发展的障碍 产品的研发、测试、运维、交付效率直 接决定了产品的迭代周期,研效的提升 决定了是否能够在同质化竞争激烈的场 景下“快人一步” 企业降本增效的 技术保障 企业内部独立的资源池、资源buffer导 致经常出现严重的“贫富差距”,弹性 能力差,不能高效的利用资源,企业运 营成本居高不下 企业不同产品之间存在较大的技术栈、 架构、重复的“轮子”导致研效和研发 成本高 云原生技术改造,几乎成为企业发展的必然选择
8. 传统应用和现代应用 传统应用 业务特征 技术架构 现代应用 关注 可靠性、稳定性 上市速度、快速增长 复杂度 业务类型独立单一,多部门协调少 业务复杂,跨团队、跨部门联合项目多 开发模式 瀑布式迭代,开发构建周期长 DevOps自动化、流程化、快速迭代,周期短 流量压力 用户访问可控,逻辑简单,压力小 流量突发成为常态,逻辑复杂且压力大 基础设施 服务器为中心,应用程序和底层操作系统之间依 赖关系紧密 容器驱动,屏蔽操作系统和硬件,可移植基础设施感 知,环境高度统一 架构设计 紧耦合、单体或中心化架构,本地部署,扩展升 级复杂 松耦合,无状态、微服务架构,本地+云化部署,组件可 以独立迭代,API调用 可伸缩性 垂直扩展和按峰值需求常备资源 水平扩张和按需分配,弹性伸缩 部署运维 服务部署、升级管理依赖人工操作,启动恢复慢 声明式和自动化运维,业务自适应,快速恢复 开发语言 C/C++、Shell Java、Go、Python等
9. 传统架构的特点和挑战: 腾讯云日志服务老旧系统问题分析 功能更 复杂 规模增 长迅速 基础设施 混乱 架构 业务 流量冲 击大 资源浪费 成本高 业务迭 代频繁 应突发能 力差 服务治理 难 性能和稳 定性差
10. 基础设施混乱 应用实例 应用实例 实例存活性、负载、进程数等 二进制程序 二进制程序 系统/运维组件 系统/运维组件 配套运维组件、监控、告警、程 序版本等 类库、系统配置 用户操作系统 类库、系统配置 宿主操作系统 类库版本、默认系统参数 内核版本、系统性能/安全 虚拟机 物理机 本地IDC、云上(多云)、硬件配 置(CPU/MEM等)、硬件型号
11. 应用的基础设施依赖如何选择? 1号进程(system/init) 业务进程1 业务进程 1 业务进程 N 1号进程(system/init) 1号进程(system/init) 业务进程2 业务进程1 业务子进程 业务进程2 1号进程(system/init) 1号进程(system/init) 业务进程3 服务器:基础设 施为物理机、虚 拟机 - 2013 业务进程4 富容器:类服务 器模式,基础设 施为容器 Sidecar:轻量级 容器,基础设施 为容器 2013 - 2019 2019 – 至今
12. 有状态应用 vs 无状态应用 有状态服务 应用本身需要保存状 态或会话 服务A 网关服务 DB 应用不需要存储信息 一个请求只能被某个 实例处理 任何请求可以在任何 请求处理 应用设计复杂,扩展 复杂 应用设计简单,扩展 容易 故障容忍度低,需要 迁移或同步数据 有状态服务 分区 无状态服务 数据 复制 服务A 无状态应用 SQL数据库或 NoSQL 数据库 故障容忍度高,直接 剔除即可 DB 集中 存储 DB
13. 适应新基础设施,如何改造应用的配置管理? • • • • • 为所有配置保留单一可信来源 使用自动化的方式来执行配置 分发和变更 集中化配置管理和版本控制 老服务适应新配置 兼容不同环境的配置管理和使 用
14. 如何平滑完成架构升级? • • • 金丝雀模式:从小地域、部分客户开始切 换,逐步灰度完成全部流量的切换 过程:老服务保持不变,新服务切换完成 后仍旧保留2周,后续再下线 风险:风险极小,出现问题可以随时切回
15. 弹性伸缩——我们为什么需要它? 图表标题 9 流量下降资源缩容滞后, 资源浪费严重 8 7 周期性流量变化资源按最 大预备,资源浪费严重 6 突发流量增长 资源扩容不及 时,服务故障 5 4 3 2 1 0 类别 1 类别 2 类别 3 类别 4 类别 5 类别 6 资源使用 资源需求 业务流量
16. 弹性伸缩最佳实践:三步走策略+两个原则 应突发 降成本 快扩容+慢缩容 保稳定
17. 为什么需要流量防护和容错? 场景: • 疫情期间,某地突发疫情封控/学校改为线上教学/上班改为远程,会议日志量瞬间突增百倍; • 618/双十一大促,电商客户业务量猛增,日志量突10倍以上; • 广东连续大雨,下班高峰,某出行客户打车量剧增; • 下游服务异常引自身服务也异常,且影响时间和范围不可控 应用C 应用A 应用D 应用B 应用E 应用F • • • 突增流量导致系统CPU负载过 高,无法正常处理请求或导致 实例OOM 流量异常导致消息投递过快, 消息队列积压 请求过多导致缓存失效,数据 库连接数增加 应用G 应用H 应用I • • • 依赖消息队列异常,消息写入 耗时增加或超时 慢SQL导致数据库负载高,请 求导致进一步雪崩 存储系统异常写入耗时增加, 吞吐量下降,日志大量堆积
18. D N S 。。。 客户端 • • • 本地缓存 退避重试 异常上报 业务接入 • • • 流量调度 鉴权准入 隔离拉黑 全链路流量接入和治理 服务与依赖 服务内部 • • • • 限流限频 计量计费 降级兜底 弹性伸缩 • • • • 削峰填谷 数据迁移 回溯恢复 故障降级
19. 建设应用可观测性:不是只是监控告警 业务埋点 性能 。。。 执行耗时 健康状态 日志上报 崩溃捕获 接口调用 。。。 慢查询 缓存访问 实例状态 使用率 访问耗时 带宽占用 系统日志 。。。 网络带宽 集群状态 实例数量 CPU/MEM/NET使用率 资源水位 系统日志 容灾巡检 。。。 中 间 件 行为 事件 基 实体 础 设 施 建 设 业 务 可 观 测 性 码 回 返 接口 势 趋 流量 监控告警 数据聚合 监 控 大 业 盘 务 全面可 观测性 统一监控 打破数据孤岛 全面掌控应用 语法 错误 检测 分 查询 热点 析 SQL耗时 日志 量 问 访 用户 行为 聚合 查询 上卷 语句 下钻 特征 分析 调用链 应 用 调用链 功率 成 接口 来源 求 请 用户画像 停留时长 从 代 码 到 用 户 行为追踪 崩溃异常 超时失败 用 户 视 角 指标 用户点击 页面加载 请求耗时 智能运维 资源 实例 数据库 页面 用户 智能运维 业务分析 异常检测 告警升级 根因分析 MQ 任务 弹性伸缩 业务运营 建设业务大盘、用 户视角应用质量和 健康情况 效能提升 告警收敛 趋势预测 告警升级、收敛、 异常检测、根因分 析、智能定位 赋能数字化效率提 升
20. DevOps实践
21. 腾讯云日志服务的云原生化架构实践 架构目标:围绕云原生技术(容器、K8S、声明式API、弹性伸缩等),建设符合现代应用和数字化业务的发展需求 基于公司一站式的应用部 署和管理平台,复用统一 资源池、应用生命周期管 理以及服务的统一治理和 容灾管控、可观测性建设 业务统一入口,支持业务高性能、安全可靠的服务和生态扩展 研效 代码仓库 服务总线 协议代理 API 路由分发 安全管控 应用管理 CI/CD 从“需求-开发-测试-发 布-运维”的一站式 DevOps平台,支持业务 快速敏捷迭代 自动化测试 微服务应用 tRPC 应用管理 TKEx 容器集群 测试集群 应用扩容 应用编排 应用配置 升级发布 IDC兼容 部署应用 停止应用 高性能的弹性伸缩容器集 群,为应用的生命周期管 理提供保障 生产集群 配置管理 删除应用 服务发现与 注册 缓存服务 Redis 提供高性能的读写能力, 提升业务应对高并发请求 的能力 消息队列 MQ 服务异构解耦,削峰填 谷,提升业务吞吐能力 分布式事务 ZK 提供分布式的协调能力, 提升业务的任务管理和事 务管理 分布式锁 ETCD 提供分布式的锁管理和任 务管理能力 消息发布 ETCD 提供广播式的消息发布和 订阅能力,协调多个上下 游业务 3AZ 创建应用 启动应用 数据库 DB 为应用提供关系型的数据 存储能力,应用重要核心 数据和业务资产 服务治理 弹性伸缩 应用生命周期管理 核心依赖 容灾降级 可观测 任务调度与 管理
22. 腾讯云日志服务云原生架构收益 图表标题 30 100% 95% 90% 第一阶段:云原生化上量 第二阶段:业务改造攻坚 89% 26 85% 80% 70% 第三阶段:弹性伸缩 25 24 79% 27 21 69% 20 20 60% 18 57% 57% 16 50% 14 14 13 12 11 10 31% 49% 14 40% 30% 50% 15 30% 28% 27% 7.3 6.9 6 20% 6.1 6.1 0% 1月 3 5 VM核心数 6 容器核心数 9.7 10 5 3.2 4 10.1 5.2 2.9 1.9 1.2 0.6 4% 2 15 7.1 6.9 2.3 0.1 1% 11.2 10.6 15% 10% 48% 45% 44% 41% 38% 38% 10 49% 52% 7 云原生渗透率 8 利用率 业务规模 9 10 0.5 11 12月 0 **数据已脱敏**
23. 腾讯云日志服务云原生架构收益 成本优化 效率提升 运营成本降低 人力成本减少 核心数减少 发布/扩缩容耗时 弹性伸缩应突发 资源利用率 2千万/年 2HC 10万核/月 90% 0介入 40% 客户价值 服务稳定性99.99%以上,适应客户场景PB级突发流量的弹性接入能力 作为平台级云服务,自身的云原生化助力客户数字化升级的需求快速迭代和交付 **数据已脱敏**
24. 如何给一架高速运行的“飞机”更新引擎? • • • • • • • 底线:不能因为升级导致故障 预期:希望升级过程业务无感知 挑战: 1.业务快速增长,规模季度增长 50%以上 2.需求压力大,大客户和产品需求 迭代几乎消耗了80%的人力 3.故障不断,几乎每月都有大小故 障发生,复盘都没时间复盘 4.并没有资源(人力、时间)专门 来做重构和升级
25. 架构演进的道与术 不为优化而优化 正确的妥协 转变模式 技术 业务 尽快见效 + 风险 + 智慧 目标制定 技术选型 向上管理 向下推进 人力投入 方案设计 里程碑 短期的业务价值 压力 勇气 = 成功的转变 反对+质疑 长期的团队收益
26.

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