降级预案在同程艺龙的工程实践-王俊翔
应⽤用数据采集 应⽤用数据 ⽅方法数据 执⾏行行结果 执⾏行行耗时 异常数据 … JVM内存 JVM线程 GC数据 业务数据 SDK数据 ⾃自定义数据 系统数据采集 容器器数据 CPU数据 内存数据 磁盘数据 … ⽹网络数据 采集 Agen t ⽇日志中⼼心 KAFKA 数据处理理 通过本地⽇日志⽂文件,实时采集降级服务质量量数据 ⽇日志 ⽂文件 系统数据采集 容器器数据 CPU数据 应⽤用数据采集 应⽤用数据 ⽅方法数据 执⾏行行结果 执⾏行行耗时 异常数据 … JVM内存 JVM线程 GC数据 业务数据 SDK数据 ⾃自定义数据 数据通道(⻓长链接单通道) 数据采集 Proxy • 单⼯工直连数据通道 • ⻓长链接,数据流⽅方式实时发送 • 本地多队列列轮循,数据缓冲,合并异步发送 指标如何计算处理理 数据采集 KAFKA ETL 复合指标 ⾃自定义指标 多种策略略⽅方案:失效备援、服务熔断、资源隔 离、延迟处理理 • 策略略灵活调整,实时监控策略略运⾏行行状态 应⽤用 / 服务 降级代码管理理 • 线上代码开发、测试、发布 • 降级代码统⼀一管理理 • 脚本代码动态编译,对象管理理 业务保障平台应 SDK 线下开发 策略略配置 测试 发布 WEB IDE 线上开发 降级⽅方法使⽤用 Git 降级代码 线下代码管理理 脚本 降级服务如何⾃自动探测恢复0 码力 | 26 页 | 18.67 MB | 1 年前3唯品会调度系统的前世今生
对任务超时、任务执行情况、监控逻辑 支持粒度功能较单一或缺乏 没有容器化选型? 调度产品的定位 简易开发、简单维护 高可用、分片并发处理、资源调度动态平衡 支持Java、Shell以及本地模式(VIP还支持消息模式) 统一配置、统一监控、统一管理 VIP弹性调度系统 -- Saturn 开源地址: Github.com/vipshop/Saturn 体系中的定位 服务化框OSP Shell作业 消息作业* JAVA作业 分布式与本 地作业模式 • 完美兼容现有PHP的作业,可无缝迁移,成本最低 • 提供多种业务开发模式,满足不同的业务需求 • 多种业务运行模式,即可分布式管理也可本地管理 • 通过异步消息实现业务编排* 多种作业类型 人工指定 运行节点 系统自动 平衡负载 资源利用 • 灵活的运维配置与部署 • 高效资源利用 • 简便的管理 人工指定 自动平衡 资源平衡调度算法 操作继续执行 解决办法: 断线重连后要判断连接sessionid是否己发生改变,如果发生改变 ,则不再继续之前的操作 坑3-Quartz反复销毁重建导致OOM 解决办法: 自实现定时调度线程,一个作业一个线程调度器。 坑4-Treecache导致zk watch大量增长 TreeCache 300+watch! ZK FULL GC 解决办法: 避免在大量子结点的PATH使用treecache,0 码力 | 58 页 | 5.40 MB | 1 年前3QCon北京2018-业务高速发展下的互联网金融系统架构演变-张现双+
限流: max_connections(db) max_request+max_threads(middleware) 数据竞争� [NoSql方案示例] 内存操作 单线程原子操作 高可用保障 兜底策略 限流、熔断: maxclients(redis) max_request+max_threads(middleware) hystrix 弹性扩容,限流(token),熔断,防刷 降级,熔断,弹性扩容 多IDC,区域容灾,多ISP 集群,高可用,分片 本地缓存,防刷,流控 终端 域名 机房 LB / NG.. 网关 Cache 服务 抓大不能放小[细节决定成败] 线程阻塞>300 中间件内存管理、线程状态,连接状况 db的io,慢sql,索引,join等 代码review,数据结构,日志 GC TCP连接0 码力 | 42 页 | 19.96 MB | 1 年前3声明式自愈系统——高可用分布式系统的设计之道-王昕
有一个统一的状 态持久化接口, 所有有状态模块 通过统一的接口 对应统一的对象 模型 配置模块对象只 需要包括 Desired State 每个领域的控 制器模块的逻 辑保证自己领 域独立自愈的 能力 改变状态的操作 必须是幂等的声 明式操作,没有 新声明时各模块 按照之前的声明 继续工作 控制器模块对象 包括Desired State 和 Realized State 尽量避免复杂状态机,逻辑不要依赖无法监控的内部状 态 每个模块都可以在必要时优雅地降级服务 每个模块都可以在出错后自动恢复 假设任何命令都可能被任何调用对象拒绝,甚至返回错 误结果 声明式自愈系统的现有框架——Kubernetes 声明式自愈系统设计理念的回顾 统一接口 和对象模 型 自愈 能力 幂等操 作和状 态机 DS 和 RS Desired State 可重用部分 已完全实现 要在领域内 Middleware OS Virtualization Storage Networking Data 启动异常 进程被杀 服务器假死 断电 启动异常 超卖 进程死锁 负载均衡失效 业务线程池满 监控错误 流控不合理 心跳异常 缓存热点 缓存限流 数据库热点 数据库宕机 数据库延迟 CPU 抢占 内存抢占 内存错乱 上下文切换 磁盘满 磁盘坏 网络抖动 网卡慢 断网 DNS0 码力 | 44 页 | 2.47 MB | 1 年前3大规模分布式系统架构下调测能力构建之道
DB Cluster 连接 序列化 路由 负载均衡 … 问题示例 1. 我依赖一个远程服务,但在负责它的团队把它上线之前,我什 么也做不了 2. 我负责的功能依赖一堆的远程服务,为了本地调测,我必须从 头到尾梳理代码,再写一堆的mock语句把他们全mock掉了。 每当业务逻辑变化了,代码中要增减相应的mock语句;每当依 赖服务上线后,要把测试用例中对应的mock语句去掉。对测试 用例的修改工作贯穿于整个开发工作之中。 不需要服务消费者注册,直接通过本地配置文件指定的IP地址来绕过“服务路由”及“负载均衡”机制。 服务提供者不能采用token验证模式 基于包名过滤服务 团队往往开发某类业务服务,这类服务一般都具有相同的包名,因此,可以通过配置包名和服务IP的映射关系, 让服务框架自动将一批服务和特定的IP关联到一起。 直连调测机制 提供者B 服务容器 提供者B 服务容器 本地配置文件 com.company company.modelB.* 192.168.1.33 com.company.modelC.* 192.168.1.44 应用服务契约测试 契约测试 通过mock手段可以解决外部不可控因素对本地调测的影响,如果真实的外 部服务改变了,我们的mock数据也要随之改变,但 问题是: 我们如何及时感知到服务接口/逻辑发生变化了? 解决方法:契约测试 通过将契约测试集成到CI流程中,在构建的过程中完成接口的联调测试,和0 码力 | 19 页 | 2.74 MB | 1 年前3海量用户推送后台系统架构实践-曾振波
充分利用资源,减少请求等待时间,提升系统吞吐量 • 消息化请求 • MQ - RabbitMQ, RocketMQ • 模块间解耦 • IDC数据同步 • 异步RPC • ICE - 负载均衡,AMI,AMD,多线程 极光推送后台系统架构 02 并行化 • 横向扩展处理能力 • 数据分片存储 • 多节点+分片+多副本架构 • 数据读写动态路由 • 请求并行处理 • 模块级别并行 • 代码级别并行 Data0-1 Data1-0 Data1-1 Data2-0 Data2-1 Mng0 Mng2 Mng3 缓存化 • 热点数据全部缓存 • 加快数据访问,减少请求处理时间 • 多级缓存 • 本地缓存 • Redis, Couchbase, LevelDB(PIKA), 定制化 极光推送后台系统架构 04 程序及系统优化 • 内存 • 静态分配 • 内存池 • 内存对齐 •0 码力 | 23 页 | 1.26 MB | 1 年前3微服务和Service Mesh 在多个行业落地实践
设计要点亓:数据库横向扩展 www.163yun.com 设计要点六:缓存的设计 APP缓存 CDN 接入层 静态资源 动态资源静态化 应用本地缓存 分布式缓存 数据库为中心 缓存为中心 www.163yun.com 设计要点七:消息队列与异步化 www.163yun.com 设计要点八:熔断,限流,降级 概览 知识 库 服务 告警 监控 大屏 账户 审计 粒度更细:可指定服务版本,类,方法级别 配置灵活:可配置检测粒度为每M毫秒N个请求P%的错误率 指标多样:RT值,错误率,线程池参数 熔断 粒度更细:可指定调用者和被调用者服务版本,支持failover、failfast、failback容 错机制。 配置灵活:支持自定义超时时间和重试次数。 可自行定制:通过暴0 码力 | 39 页 | 3.06 MB | 1 年前3高性能高可用机票实时搜索系统
• 空间换时间 • 缩短对象驻留留内存时间,减少gc次数,优化单机吞吐 • 数据交换采⽤用protobuf + gzip处理理 • jit、预热 回顾 • ⽔水平分层,纵向分渠道,良好的扩展性 • 实时计算 + 阶梯式缓存,成本与报价新鲜度的权衡 • 闭环系统 • 索引库数据同步 • 本地缓存的设计,更更新策略略 • 缩减对象内存 • ⼀一致性哈希负载均衡0 码力 | 26 页 | 1.94 MB | 1 年前3领域驱动设计&中台/淘宝应用架构升级——反应式架构的探索与实践
能达到这种效果? CONTENTS 01 架构升级的效果 02 架构升级的思考 03 架构升级的实践 架构升级的思考 现有架构的问题? 现有架构的问题 同步等待 • 现有同步模型,线程 多 load ⾼高 • 资源利利⽤用率 应⽤用本身的解决⽅方案? 并⾏行行度有限 • ⽆无法纯业务依赖并发 • 微服务化让问题更更凸 显 • RT 累积 RT 与 ⽤用户增⻓长 .map(Result::getData) .reduce(0, (acc, data) -> acc + data); 流 - 性能 全异步、流式 CPU数个业务线程 更更少的上下⽂文切换、更更少(⽆无)的竞争、更更低的LOAD 业务等效依赖的异步并发 更更⾼高效的资源利利⽤用率 Universal Scalability Law 系统流⽔水线并⾏行行处理理 缓存(Cache) 4. 消息(Queue) * 天然异步 * 已有集成,或集成成本低 5. DB(JDBC)(Block) * ⽤用 Ali JVM协程 异步集成 * 或⽤用线程池异步集成 6. 限流组件 7. 分布式跟踪系统 解决业务异步/回调 引⼊入的 上下⽂文传递 问题 8. iOS Objective-C 的 Rx 框架 实现 AliRxObjC0 码力 | 27 页 | 1.13 MB | 1 年前3分布式 KV 存储系统 Cellar 演进之路
req9 req8 reply Cellar—快慢队列 网络 线程 工作队列 工作 线程 问题: 共用队列&线程 线上慢请求:超时请求 1: 20 Cellar—快慢队列 网络 线程 读快队列 读快 线程 TP999延迟降低86% 读慢队列 写快队列 写慢队列 读慢 线程 写快 线程 写慢 线程 慢请求判断: • 耗时接口(range···) • value过大 •0 码力 | 34 页 | 1.66 MB | 1 年前3
共 22 条
- 1
- 2
- 3