大规模分布式系统架构下调测能力构建之道 李鑫 大纲 分布式环境下开发的调测效率问题 应对之道 远程应用服务 契约测试 分布式消息服务 分布式缓存 分布式服务的“租户”隔离策略 总体调测框架实践 分布式环境下调测方法论 单体应用 服务化 微服务 小中型规模应用+小型团队 中大型规模应用+多团队协同 Cache DB NFS Load Balancer Gateway 分布式文件 分布式缓存 分布式消息 DB Cluster 连接 序列化 路由 负载均衡 … 问题示例 1. 我依赖一个远程服务，但在负责它的团队把它上线之前，我什 么也做不了 2. 我负责的功能依赖一堆的远程服务，为了本地调测，我必须从 头到尾梳理代码，再写一堆的mock语句把他们全mock掉了。 每当业务逻辑变化了，代码中要增减相应的mock语句；每当依 赖 用例的修改工作贯穿于整个开发工作之中。 3. 我和某同事通过服务框架进行调用联调，结果另一同事也把同 名服务挂了上来，不幸的是，他的服务版本和我们的不一样， 结果，一系列的灵异状况发生了… 4. 依赖的远程服务逻辑发生变化了，但负责它的团队没有通知到 我，结果上线后直接导致生产事故。 5. 我和其他团队共用一套分布式缓存服务，为了防止数据覆盖， 我只能和别人轮流排队上线调试，我等了一天，结果只能用一

.buffer(10, MILLISECONDS, 16) .flatMap(service::batchOps) 流 - 并发控制 切过 Scheduler是指： • 远程调⽤用已经异步化，所以是已经且过 Scheduler • 可以⼿手⼯工切 Scheduler (subscribeOn / observeOn) 业务顺序编写 并发⽅方式执⾏行行 • 不不同的流 ��A� 流引⽤用可被远程化 系统级的流式贯通 架构治理理能⼒力力加强： • 回压 • 三⻆角模式透传 • 业务快速截⾯面创新 • … 流的概念分层 业务编程框架（⾯面向业务） • 核⼼心概念：流 • 业务涉及的⼤大量量/强⼤大操作 • 流程编排、全异步化 规范（⾯面向系统底层） • 核⼼心：4个接⼝口 + 7个⽅方法 • 远程化、业务框架对接规范 •

缺乏统一监控、统一管理 (进程假死、运行状态未知) 缺乏容错、容灾，高可 用 缺乏分布式处理 无法合理利用机器资源 难以问题追踪 选型对比 Crontab Quartz Linux系统级的定时任务执行器 缺乏分布式运算和集中管理功能 无法做到高可用 TBSchedule Elatic-Job Java事实任务标准 关注点在定时任务而非数据， 缺少分布式并行调度的功能 阿里早期开源的分布式任务调度系 数据一种模式 当当开源的分布式任务调度系统 代码较新，使用Quartz进行调度。提供 高可用和分布式功能 功能单一，只支持Java，不支持 Shell(PHP)和消息驱动的作业调度 对任务超时、任务执行情况、监控逻辑 支持粒度功能较单一或缺乏 没有容器化选型？ 调度产品的定位 简易开发、简单维护 高可用、分片并发处理、资源调度动态平衡 支持Java、Shell以及本地模式(VIP还支持消息模式) 唯品会弹性调度系统的架构与功 能窥探 域 应用包 作业 执行节点 1 1 * 1 * * 创建 Binding 调度器 物理机 1 1 分片 1 * * 领域模型 Ready Running Stopping Stopped 启用 触发（手工, 时间或消息) 停用 执行完成 停用 执行完成 作业状态变迁 内部系统集成 ZK 执行结点 Job A Job B 作业调度器

代 码 检 出 代 码 编 译 镜 像 构 建 集 成 测 试 自 动 部 署 流水线管理 测试平台 (集成，场景测试) 单接口 用例 场景 用例 执行 集 定时 执行 接口 Mock 覆盖 率 生产镜像仓库 测试镜像 仓库 历史 管理 批量 导入 接口 监控 www.163yun.com 多样需求 持续集成 中台化 (集成，场景测试) 单接口 用例 场景 用例 执行 集 定时 执行 接口 Mock 覆盖 率 生产镜像 仓库 测试镜像 仓库 历史 管理 批量 导入 接口 监控 生产集群 镜像 同步 镜像拉取 自 动 部 署 手 动 触 发 代码到线上全流程管理 互联网化接口测试，场景测试 灵活执行集：冒烟，日常，回归 定时测试，MOCK测试

测试 答对问题有奖金 金额从2.56元到20.48元 请扫我微信以便当场转账 加微信时烦告知尊姓大名 状态 入口动作和出口动作 entry：进入时必须执行 exit：离开时必须执行 逻辑进一步内收 迁移 迁移的结构和执行顺序 1. 当前状态是否能接受事件 2. 警戒条件 如果为真 3. Exit：先子后父 4. Action和Message 5. 改变状态 6 从状态属性思考状态名称  优先用原生形容词，防止换汤不换药  有进有出  警戒条件之和必须是完备集（“其他”）且不重叠 吃饱了没？吃饱好干活 建模 打车领域 建模 实现 Rhapsody 执行 http://www.umlchina.com/training/umlchina_rhap_lab_dishwasher_81.pdf http://www.umlchina.com/training/download

必然摩擦 不就是这里改一下么，不就是流程调整一下么？ 沟通、沟通、沟通、无他 不同的对象，沟通方式不一样，灵活处理，使用不同的技巧 沟通只是第一步，形成固定机制，落实并执行才最重要 Motivation 正确的激励导向，使团队快乐 需要的素质和「心得」 需要的素质 指得了路 扛得了枪 吃得了苦 卖得了萌 受得了委屈

json数据 • 前端的计算逻辑都改到后端 前端： • 前端nvd3.js替换成echarts • 更强大易用的报表设计器 改造后的zeppelin报表设计器 字段 控制区 行列控制区 数据执行区 标记卡 控制区 图表辅助 设置区 1、图表参数设置 2、图内筛选器 3、图表辅助线 4、图表预警 4、图表坐标轴控制 5、图表图例显示控制 1、字段设置 2、添加计算字段

潜在的一致性问题 - 能管理的元数据有限 • 中心化 - 设计实现简单 - Master节点易成为瓶颈 中心化的解决方案 • Master-Slave模型 - Master是管理者 - Slave是执行者 • 解决Master节点瓶颈 - 常规操作不经过Master • 一般计算系统 • Bigtable、Tera等存储系统 - 使Master无状态 • 非最底层系统都可以设计无状态Master

58集团技术专场 机器、操作系统监控 58集团技术专场 2. 监控平台-进程/端口/JVM • 两类思路：分发/汇总 • 分发类实现Tips （1）易扩展的配置 （2）远端接口探测，命令执行 （3）可以无需agent • 汇总类实现Tips （1）agent快速部署 （2）agent从中央获取配置 （3）快速的本地检测 58集团技术专场 2. 监控平台-日志 ERROR日志监控Tips

消息状态上报 调用重试/查询接口 同步消息管理服务 全局消息id生成 消息管理（预写、删除等） 重试、查询、监控接口 sdk CRSync CRSync sdk sdk Processor 是否执行结束 获取监控接口 通知运营 或者技术， 人工介入 依赖关系优化 不跨机房 弱依赖 少依赖 主从模式 主从模式 主机房 从机房 MQ Service Cache Processor