电商消息系统架构演进&mdash0 码力 | 22 页 | 12.22 MB | 1 年前3
微服务和Service Mesh 在多个行业落地实践接入层 静态资源 动态资源静态化 应用本地缓存 分布式缓存 数据库为中心 缓存为中心 www.163yun.com 设计要点七:消息队列与异步化 www.163yun.com 设计要点八:熔断,限流,降级 www.163yun.com 设计要点九:配置中心 www.163yun.com 设计要点十:日志中心 率 生产镜像仓库 测试镜像 仓库 历史 管理 批量 导入 接口 监控 www.163yun.com 多样需求 持续集成 中台化 PaaS托管 容器化 分布式事务 服务治理 全链路压测 性能监控 注册发现 服务管理 www.163yun.com ZIP源码包 持续集成 重新开发 迭代修改 个性开发 统一模版 接口统一 Confirm 无操作 + Cancel 补偿 • 事务消息——中间件 TMC 网易分布式事务的实现机制 www.163yun.com 事务发起者、事务参与方 分支事务用事务id做幂等 生成对应分支事务记录 并行调用 定时任务兜底 红色为异常流程 Q:回滚的时候,如果分支事务记录不存在,该 怎么返回? option1:返回成功0 码力 | 39 页 | 3.06 MB | 1 年前3
海尔实时计算平台技术选型与实践• 事务一致性的输出 • 容错 上图摘自confluent官网 Flume适合: • 日志收集 • 日志传输 • 拦截数据 消息队列适合: • 消息持久化 • 解耦 推荐:Flume+ 消息队列 为何要引入消息队列 消息队列可选方案 • Kafka • Jafka • RocketMQ • RabbitMQ • ActiveMQ • Apollo 消息队列使用场景及选型 消息队列使用场景及选型 事务可靠性场景(ActiveMQ/RabbitMQ/RocketMQ): • 重要业务数据的异步处理 吞吐量优先场景(Kafka/RocketMQ): • 大规模数据的传输和收集 Kafka web管理界面: •Kafka Web Console •Kafka Manager •KafkaOffsetMonitor •Uber开源Kafka监控工具--Chaperone0 码力 | 41 页 | 3.21 MB | 1 年前3
数字货币交易系统架构 Python实现 黄毅TPS, 延迟10ms • 能睡个好觉(数据持久化,数据最终一致性,容错) • 设计简单,运维方便 交易系统架构设计-关键点 • 内存撮合服务的状态持久化和高可用 • 消息处理顺序的保证 • 异步服务之间消息传送的可靠性 • K线:实时的分组聚合操作 • 高效利用关系数据库 交易系统架构设计-架构图 撮合 资金清算 行情推送 K线计算 历史成交 订单状态 PG Redis 交易系统架构设计-撮合服务 • C++实现的Redis Module • 复用Redis本身的aof持久化和replication • 撮合结果直接输出到本地的redis stream(无需主动发送消息给其他服务) • 下游任务订阅redis stream $ redis-cli > ob.limit b{btc_usdt} * 10000 buy 1 10000 88181047656742912 “[9000,9000,9000,9000,1]” 交易系统架构设计-redis stream • Kafka-like • 一个订阅者的情况,消息有序 • Consumer group负载均衡(不保证消息顺序) • 可以批量处理消息 • 在同一个事务中存储处理结果和更新消费offset $ redis-cli > xread block 60 count 100000 streams b{btc_usdt}o0 码力 | 24 页 | 799.65 KB | 1 年前3
领域驱动设计&中台/架构分层模型适配03 分层模型适配实例例 DDD分层参考架构 DDD分层参考架构 给⽤用户提供界⾯面,关注⽤用户交互和体验 前端应⽤用 API服务 业务领域 基础设施 为前端应⽤用提供API服务,关注事务和分布式等技术性问题 领域模型和领域逻辑,关注业务概念。 访问外界系统(调⽤用外界系统)的技术相关实现。 后台服务 前端应⽤用 分层依据: ⼲干系⼈人和技术点 DDD分层参考架构 - 前端应⽤用 为前端和第三⽅方应⽤用提供API服务,关注服务编排,事务和 分布式等 前端应⽤用 应⽤用服务 业务领域 基础设施 ⼲干系⼈人: 应⽤用开发⼈人员 诉求: 灵活易易使⽤用的API 技术点: 性能,事务,分布式,安全等⾮非功能性需求 API服务 ⼯工作内容: • 接收外部请求并响应: 如HTTP请求, 消息处理理 • 事务管理理 • 认证 • 缓存 • ⽇日志 • 异常处理理0 码力 | 39 页 | 2.54 MB | 1 年前3
QCon北京2018-业务高速发展下的互联网金融系统架构演变-张现双+2pizza团队,系统单体制约 商城 核心服务 业务 网贷 保险 基金 商城 财富圈 健康财富 加密 验签 拦截 校验 安全 性能 并发 幂等 交易 缓存 基础服务 消息 监控 配置 报警 MIS OpenAPI 微信 财富圈 移动后台 商城MIS WAP … … Android/ios/h5/php/openApi 积分系统 基础服务 优惠券 移动服务C 接入层 服务A 服务B 1 2 移动服务 接入层 v2 v3 v1 重要原则 幂等、接口可重入 接口规范化(命名、类型、长度等) 分布式事务,补偿、撤销机制 接口缓存,热数据尽可能前置 DB跟随服务 代码、逻辑、结构等都要适时重构 最终架构[简版] 移动后台打散,界限趋于不明显 极大消除冗余,三级两层划分 流量统一出口 积分系统 优惠券 基金服务 保险服务 理财服务 支付中心 电子签章 第三方系统 营销支持 基础服务 数据支持 批处理 … 网关(略) 移动基础服务 消息 监控 配置 报警 金融产品 Yiri 财富圈 首页 feed 活动中心 微信 WAP 4G 积分商城 ... ... 账户中心 迅速响应业务变化 before after 第三部分0 码力 | 42 页 | 19.96 MB | 1 年前3
唯品会调度系统的前世今生高可用和分布式功能 功能单一,只支持Java,不支持 Shell(PHP)和消息驱动的作业调度 对任务超时、任务执行情况、监控逻辑 支持粒度功能较单一或缺乏 没有容器化选型? 调度产品的定位 简易开发、简单维护 高可用、分片并发处理、资源调度动态平衡 支持Java、Shell以及本地模式(VIP还支持消息模式) 统一配置、统一监控、统一管理 VIP弹性调度系统 -- Saturn Saturn 开源地址: Github.com/vipshop/Saturn 体系中的定位 服务化框OSP 开发框架Venus 唯品会基础架构体系 消息队列 VMS 全链路监控 Mercury 统一日志平台 dragonfly 任务调度平台 Saturn 统一配置中心 CfgCenter 统一鉴权中心 AuthCenter 服务网关 Janus 安全管理平台 Salus Running Stopping Stopped 启用 触发(手工, 时间或消息) 停用 执行完成 停用 执行完成 作业状态变迁 内部系统集成 ZK 执行结点 Job A Job B 作业调度器 控制台UI 消息系统 控制、调度结果下发 作业控制 结点监听 作业调度 执行日志 监控日志 日志查询 消息订阅 告警信息 执行结果 统一认证 架构体系 部署模型(跨机房)0 码力 | 58 页 | 5.40 MB | 1 年前3
大规模分布式系统架构下调测能力构建之道大规模分布式系统架构下调测能力构建之道 李鑫 大纲 分布式环境下开发的调测效率问题 应对之道 远程应用服务 契约测试 分布式消息服务 分布式缓存 分布式服务的“租户”隔离策略 总体调测框架实践 分布式环境下调测方法论 单体应用 服务化 微服务 小中型规模应用+小型团队 中大型规模应用+多团队协同 Cache DB NFS Load Balancer 行功能/接口 调测存在如下困难: 开发依赖重 联调成本高 变动把控困难 拆 应用拆分 数据拆分 团队拆分 分布式服务 API Gateway 分布式文件 分布式缓存 分布式消息 DB Cluster 连接 序列化 路由 负载均衡 … 问题示例 1. 我依赖一个远程服务,但在负责它的团队把它上线之前,我什 么也做不了 2. 我负责的功能依赖一堆的远程服务,为了本地调测,我必须从 我和其他团队共用一套分布式缓存服务,为了防止数据覆盖, 我只能和别人轮流排队上线调试,我等了一天,结果只能用一 个小时。 6. 我写了个消息Consumer,布到线上准备测测,结果,别人的消 息先到了,一下把我的预置数据全搞乱了… 7. 我的开发机性能还行,我想自己装一套依赖环境提高开发调测 效率,结果消息服务、缓存服务、服务框架装完一启动,80% 的系统资源就没有了,想想还有一堆的应用服务还没装,直接 泪崩… 80 码力 | 19 页 | 2.74 MB | 1 年前3
分布式异地多活架构实践之路Push无状态数据 CRSync异步同步 Service实时同步 北京IDC 合肥IDC 广州IDC 最终一致性 MQ 消息接口 消息状态库 定时补偿 MQ 监控 sdk Service 消息状态上报 调用重试/查询接口 同步消息管理服务 全局消息id生成 消息管理(预写、删除等) 重试、查询、监控接口 sdk CRSync CRSync sdk sdk Processor0 码力 | 36 页 | 1.66 MB | 1 年前3
海量用户推送后台系统架构实践-曾振波关于极光 • 消息推送系统面临的挑战 • 极光推送相关架构 • 极光推送后台系统架构 • 后台系统架构基本原则 • 链接管理 • 系统安全 • 新技术的应用 目录 关于极光 36.9 万 开发者 107.6 万 APP 198 亿 移动终端 10.4 亿 月独立 活跃设备 90 % 覆盖率 亿级长连接用户 SDK多版本并存 消息实时性 触达率要求 触达率要求 移动网络环境复杂性 海量用户数据存储 消息推送系统面临的挑战 极光推送服务架构 系统通道 API 用户筛选 用户分发 推送通道 极光通道 共享通道 短信通道 极光推送后台系统架构 iOS SDK Android SDK WPhone SDK Portal Conn GW SIS Register StatCenter TagAlias Segment OnlineCache 模块间通过MQ/RPC交互 极光推送后台系统架构 01 Segment Conn StatCenter OnlineMsg 异步化 • 充分利用资源,减少请求等待时间,提升系统吞吐量 • 消息化请求 • MQ - RabbitMQ, RocketMQ • 模块间解耦 • IDC数据同步 • 异步RPC • ICE - 负载均衡,AMI,AMD,多线程 极光推送后台系统架构 020 码力 | 23 页 | 1.26 MB | 1 年前3
共 22 条
- 1
- 2
- 3













