0 PAIN POINTS 业务野蛮发展 交易量高速增加 并发请求增加 交易响应速度过慢 数据库单表 数据量剧增 模块耦合度高 开发效率低下 … 思考 THINKING 解耦 异步化 扩容 排队 队列 缓存 冷热数据隔离 读写分离 分库分表 容灾 限制 池化 ACK ... 变化 VARIETY adapter oltp db 银行/第三方支付 早于用户 发现问题 如何让开发人员 对自己的代码 更加有安全感 ？ 这些困惑的体现是什么呢？ 开发人员如何提高代码质量，减少频繁迭代产生的bug？ 线上环境突发事故，第一时间如何决策减少事故影响范围？ 开发人员排查问题速度过慢？ 随着业务的增长，问题越来越多，第一优先级需要解决什么？ 系统突然CPU、内存利用率暴增，如何定位代码？ 数据库连接数被耗尽，怎么办？ 各种OOM如何预防？ 实时监控（傻瓜式、开发不用查日志） 可视化运营 网络监控 主机监控 服务监控 业务监控 中间件、接口探测、日志抓取 状态类（响应码、交易状态、退款状态、商户状态） 耗时类（交易总时长、分段时长、SQL耗时、代码耗时） 统计类（订单量异常预警、非法IP预警、交易额过大） 网络异常（单通道和多通道、不同的分布场景） 撒网与实时监控 REAL-TIME MONITORING 可视化运营 VISUAL

TBSchedule Elatic-Job Java事实任务标准 关注点在定时任务而非数据， 缺少分布式并行调度的功能 阿里早期开源的分布式任务调度系 统，代码略陈旧 作业类型较单一，只能是获取/处理 数据一种模式 当当开源的分布式任务调度系统 代码较新，使用Quartz进行调度。提供 高可用和分布式功能 功能单一，只支持Java，不支持 Shell(PHP)和消息驱动的作业调度 对任务超时、任务执行情况、监控逻辑 提供多种业务开发模式，满足不同的业务需求 • 多种业务运行模式，即可分布式管理也可本地管理 • 通过异步消息实现业务编排* 多种作业类型 人工指定 运行节点 系统自动 平衡负载 资源利用 • 灵活的运维配置与部署 • 高效资源利用 • 简便的管理 人工指定 自动平衡 资源平衡调度算法 框架代码 与业务代 码隔离 集中化动 态增加与 删除作业 • 简化开发，避免冲突，业务无侵入 • 易于发布与维护 Binding 分片 1 * 镜像(程 序包) 1 * 作业实 现包 1 * 物理机 1 1 作业名 1 * 模型结合 开发／测试 生产 GIT Check-in代码 Jenkins Pull代码 Build Image Registr y QA Tag Production Saturn DC/OS 配置作 业及资 源占用 申请资源 绑定作业 Saturn

OnlineCache XPNS Broadcast PushTask API JCache JMQ DB 极光推送后台系统架构 02 01 06 03 07 05 04 08 模块化 异步化 并行化 缓存化 程序及系统优化 基础组件服务化 链接管理 系统安全 09 新技术的应用——K8S部署业务 模块化 • 模块业务逻辑All In导致相互影响，更新升级难度大 • 极光推送后台系统架构 01 Segment Conn StatCenter OnlineMsg 异步化 • 充分利用资源，减少请求等待时间，提升系统吞吐量 • 消息化请求 • MQ - RabbitMQ, RocketMQ • 模块间解耦 • IDC数据同步 • 异步RPC • ICE - 负载均衡，AMI，AMD，多线程 极光推送后台系统架构 02 并行化 • 横向扩展处理能力 横向扩展处理能力 • 数据分片存储 • 多节点+分片+多副本架构 • 数据读写动态路由 • 请求并行处理 • 模块级别并行 • 代码级别并行 极光推送后台系统架构 03 MQ Segment OnlineMsg OnlineMsg OnlineMsg Data0-0 Data0-1 Data1-0 Data1-1 Data2-0 Data2-1 Mng0 Mng2 Mng3

taker.amount, self.maker.amount) def side(self): return self.taker.side 交易系统功能-伪代码 @app.post('/limit_order') def limit_order(order: Order): # 冻结资金 lock_user_fund(order) TPS, 延迟10ms • 能睡个好觉(数据持久化，数据最终一致性，容错) • 设计简单，运维方便 交易系统架构设计-关键点 • 内存撮合服务的状态持久化和高可用 • 消息处理顺序的保证 • 异步服务之间消息传送的可靠性 • K线：实时的分组聚合操作 • 高效利用关系数据库 交易系统架构设计-架构图 撮合 资金清算 行情推送 K线计算 历史成交 订单状态 PG Redis 在同一个事务中存储处理结果和更新消费offset $ redis-cli > xread block 60 count 100000 streams b{btc_usdt}o offset … 交易系统架构设计-异步任务 def read_events(redis, key, offset=0): while True: events = redis.execute('xread', 'block'

断路路器器 降级操作 请求合并 请求缓存 实践过程中遇到的问题 • 业务改造成本⾼高，代码耦合，维护成本增⾼高 • 固化策略略，需线下修改代码，测试，发布，线上应急策略略响应不不 友好 • ⽆无法⽀支撑多系统的复合指标计算，业务降级⽀支持不不友好 • ⼤大量量应⽤用各⾃自实现降级熔断，代码散落在各应⽤用，没有统⼀一的管 理理和治理理。久⽽而久之，⽆无⼈人知道系统内有多少降级点，降级是如 指标明细（ES） 降级⽇日志（ES） ETL 指标计算（Flink） 脚本引擎 查 询 服 务 ⽇日志数据 指标（Redis） 业务异常数据快照（ES） 熔断降级通知 降级服务管理理 故障代码注⼊入 降级服务注册设计 serviceA serviceB serviceC etcd register service metadata degrade strategy center 业务数据 SDK数据 ⾃自定义数据 数据通道（⻓长链接单通道） 数据采集 Proxy • 单⼯工直连数据通道 • ⻓长链接，数据流⽅方式实时发送 • 本地多队列列轮循，数据缓冲，合并异步发送 指标如何计算处理理 数据采集 KAFKA ETL 复合指标 ⾃自定义指标 系统指标 业务指标 指标脚本计算 指标规则计算 指标脚本 规则表达式 熔断 降级 条件 计算 降级消息

⼩小步改造系统 可视化的认识遗留留系统 C4模型、⽤用户画像、⽤用户旅程 C4模型系统架构可视化 国家级 省级 道路路级 市级 C4模型系统架构可视化 系统上 下⽂文图 容器器图 代码图 组件图 已可视化 ⽤用户画像和旅程系统功能⽤用户可视化 ⽤用户画像 ⽤用户旅程 已可视化 突出⽤用户信息，诉求和价值体现 还原业务场景 可视化的划分遗留留系统 领域驱动设计、事件⻛风暴暴⼯工作坊、服务画布 划分限界上下⽂文 什什么是限界上下⽂文？ 如何探索限界上下⽂文？ 业务的扩展会产⽣生越来越多的领域模 型，任何⼤大型项⽬目都会存在很多的领 域模型。当不不同领域模型对应的软件 代码被放在⼀一起后，软件就变得庞⼤大 且复杂，代码难于理理解、且容易易出现 bug，所以需要通过限界上下⽂文来明 确定义领域模型的范围和职责。 为什什么使⽤用限界上下⽂文？ 限界上下⽂文可以分为限界和上下⽂文两个词 来理理解，限界：指⼀一个界限，具体的某⼀一 明确核⼼心模型 明确服务包含的数据表 可视化的拆解遗留留系统 微服务架构、绞杀模式、代码依赖分析、数据库依赖分析、 遗留留系统拆解评分表、降⻰龙⼋八步 庖丁解⽜牛拆解的最⾼高境界 了了解⽜牛的⽣生理理构造 避开筋腱⻣骨节交错的组织 从⻣骨节的缝隙下⼿手 ⼗十九年年⼑刀依然锋利利 再看⼀一眼微服务架构 我们要做应⽤用代码拆分 我们要做数据库拆分 绞杀者模式 ‣“绞杀者模式”在既有系统资产的

扩张阶段 业务和团队规模增长迅速，多元化发展，对效率和质量提出更高要求 没有一种� 架构能� 包打天下 DB Server PC WEB 容错性、稳定性差 技术债迅速积累 代码安全带来挑战 初始，� 效率优先 成长,移动后台旁路追赶 DB主 Server PC WEB AND/IOS/H5/Open 静态站 网贷服务 借款流程 Cache集群 安全加密 幂等、接口可重入 接口规范化(命名、类型、长度等) 分布式事务，补偿、撤销机制 接口缓存，热数据尽可能前置 DB跟随服务 代码、逻辑、结构等都要适时重构 最终架构[简版] 移动后台打散，界限趋于不明显 极大消除冗余，三级两层划分 底层服务有序汇总直面前端 流量统一出口 积分系统 优惠券 基金服务 hystrix..(service) 热点削峰 流量 系统容量水位线 不限流 限流 时间 削峰策略[知容量,明底线] 限流 降级 熔断 拒绝服务 异步延迟 多节点参与 开关控制 过载保护 丢车保帅 容量水位线 底线 多节点有序参与 智能DNS，DNS负载均衡 限流(limit,lua)，openresty，4层/7层LB

静态资源 动态资源静态化 应用本地缓存 分布式缓存 数据库为中心 缓存为中心 www.163yun.com 设计要点七：消息队列与异步化 www.163yun.com 设计要点八：熔断，限流，降级 www.163yun.com 设计要点九：配置中心 www.163yun.com 设计要点十：日志中心 www 流水线管理 代码 检出 代码 编译 镜像 构建 集成 测试 部署 测试平台 (集成，场景测试) 单接口 用例 场景 用例 执行 集 定时 执行 接口 Mock 覆盖 率 生产镜像 仓库 测试镜像 仓库 历史 管理 批量 导入 接口 监控 生产集群 镜像 同步 镜像拉取 自 动 部 署 手 动 触 发 代码到线上全流程管理

Flink Ganglia Sqoop zeppelin Saiku Caravel CBoard Nagios 实时数据采集技术选型要求 • 完整 • 低延时 • 不影响业务系统性能 代码埋点： • 优点：采集能力强 • 缺点：时间、人力成本大 实时数据采集－数据如何获取？ 可视化埋点： • 优点：成本低，速度快 • 缺点：行为记录信息少，支持的分析方式少 • Flume RocketMQ • RabbitMQ • ActiveMQ • Apollo 消息队列使用场景及选型 事务可靠性场景（ActiveMQ/RabbitMQ/RocketMQ）： • 重要业务数据的异步处理 吞吐量优先场景（Kafka/RocketMQ）： • 大规模数据的传输和收集 Kafka web管理界面： •Kafka Web Console •Kafka Manager •KafkaOffsetMonitor

微服务化让问题更更凸 显 • RT 累积
 
 RT 与 ⽤用户增⻓长 RT 累积带来成本 • 过早引⼊入 cache • 每个服务都在设置超 时 维护成本、业务实现复 杂化 天⽣生异步的架构 流 Stream / Flow / Flux 什什么是流 • ⼀一个流是顺序串串⾏行行执⾏行行的 • 多个流之间才可能是并⾏行行的 Your Mouse is a Database buffer(10, MILLISECONDS, 16) .flatMap(service::batchOps) 流 - 并发控制 切过 Scheduler是指： • 远程调⽤用已经异步化，所以是已经且过 Scheduler • 可以⼿手⼯工切 Scheduler (subscribeOn / observeOn) 业务顺序编写 并发⽅方式执⾏行行 • 不不同的流 • ⽆无依赖 map(Result::getData) .reduce(0, (acc, data) -> acc + data); 流 - 性能 全异步、流式 CPU数个业务线程 更更少的上下⽂文切换、更更少(⽆无)的竞争、更更低的LOAD 业务等效依赖的异步并发 更更⾼高效的资源利利⽤用率 Universal Scalability Law 系统流⽔水线并⾏行行处理理 流 - 分布式 �