数字货币交易系统架构 Python实现 黄毅 目录 CONTENTS 交易系统功能介绍 交易系统架构设计 钱包实现介绍 1 交易系统功能介绍 交易系统功能-基本概念 class Side(Enum): ‘下单方向’ BUY = 0 SELL = 1 class Order(NamedTuple): ‘订单’ id: int side: Side amount: min(self.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) save_order(order, trades) # 更新K线 update_kline(trades) # 推送用户信息变更 push_user_messages(trades) 交易系统功能-撮合 def match_buy(book, taker: Order): for price, orders in sorted(book.asks): for maker

统⼀一资源⽹网关 资源2 资源3 资源4 …… 资源4 ⼤大量量超时 统⼀一资源⽹网关 搜索引擎 API⽹网关 ⼤大量量请求超时 缺乏熔断设计 交易易故障 第三⽅方⽀支付 ⽀支付中⼼心 ⽀支付回写 消息队列列 ⽀支付通知 交易易中台 ⽀支付时限任务 出票处理理 队列列故障 已⽀支付订单被取消 ⽀支付超时 订单取消 缺乏降级设计 稳定性之路路到底有多远 如何设计⾯面向容错的系统，如何提升系统的可⽤用性 SDK 线下开发 策略略配置 测试 发布 WEB IDE 线上开发 降级⽅方法使⽤用 Git 降级代码 线下代码管理理 脚本 降级服务如何⾃自动探测恢复 ⽅方法代理理 降级 正常流程 保护期窗⼝口 （10min） 窗⼝口期 探测期窗⼝口 （5min） 探测流量量分配 窗⼝口期外 窗⼝口期外 降级⽅方法 熔断 降级流程 恢复探测 探测 开启 开启

Nginx keepalived 数据库双机 网络分发层 业务处理 渠道适配器 交易预处理 交易预检查 交易风控 交易路由 通知 响应 查询 通道 交易拆分 业务2.0痛点 BUSINESS 2.0 PAIN POINTS 业务野蛮发展 交易量高速增加 并发请求增加 交易响应速度过慢 数据库单表 数据量剧增 模块耦合度高 开发效率低下 … 思考 THINKING oltp3 RabbitMq-2 PAIN POINTS 业务3.0痛点 BUSINESS 3.0 PAIN POINTS 业务3.0远景 BUSINESS 3.0 VISION 实时交易环境 非实时交易环境 通 道 A 通 道 B 通 道 C 通 道 D … 通 道 A 通 道 B 通 道 C 通 道 D … 单 笔 代 收 单 笔 代 付 快 捷 鉴 权 短 63 61 09 04 02 03 06 34 初始 交易检查失败 路由失败 路由成功 已撤销 定时器触发批扣打包 UI触发批扣打包 正在发送 第三方 失败 成功 三方已受理 部分成功 （批量交易） 订单失败 （网关交易） 接入网关 交易检查 服务路由 批量任务 通道适配 响应处理 交易检查成功 定时器触发批付打包 UI触发批付打包 有限状态机 FINITE

场景 今年我们要落地中台架构 大中台，小前台？ 中台架构是怎么样的？ 是不是需要分层设计？ 用什么系统去承载？需要什么框 架吗？ 换个问法 今年我们要落地业务中台架构 用户基础服务 交易服务 商品服务 关系服务 广告服务 业务域A 业务域B 业务域C 业务域D 业务组件/中间件 电商业务 内容业务 直播业务 算法支撑 中间件 计算框架 平台工具 云的能力 什么是架构师的业务思维？ 业务上会有更多类似玩法 If else不能解决本质问题 多平台、多渠道是个趋势 跳出技术思维 多渠道的本质是商品交易体系的扩展性 理解清楚当前需求 具有业务前瞻性 不要过度设计 多渠道 多平台 多用户 模块化 SPI 规则引擎 流程引擎 商品平台化 交易平台化 促销平台化 渠道下单 无结构化商品 多平台玩法 多端适配和开发组件 组件池 怎么去实践 走到业务一线去 找对评判标准-比如客户价值

World Non-Critical Digital World Non-Critical Physical World 新美大酒旅 国内发展最快的一站式综合住宿服务 平台 国内最大的在线门票交易平台 酒旅搜索推荐 2015Q3 组建推荐团队 2015Q4 周边游频道内推荐 2016Q1 搜索少/无结果推荐 2016Q2 详情页推荐 2016Q3 酒旅交叉推荐 2016Q4 点评旅游推荐 标签在POI维度的分布 用户标签偏好*标签权重*POI标签偏好*POI销量 召回策略演进过程 基于L2R的排序策略优化 机器学习流程 问题建模 推荐 推荐 访消率 •访购率为目标 •只看点击率没有反映出交易属性 •看最终收入 •消费受购买限制、退款条件等影响 •收入跟BD谈单毛利相关 •Pointwise L2R •Pairwise性能问题 •NN做rank? Model h q1 d1

热点场景频发，影响单体稳定 2pizza团队，系统单体制约 商城 核心服务 业务 网贷 保险 基金 商城 财富圈 健康财富 加密 验签 拦截 校验 安全 性能 并发 幂等 交易 缓存 基础服务 消息 监控 配置 报警 MIS OpenAPI 微信 财富圈 移动后台 商城MIS WAP … … Android/ios/h5/php/openApi

怎么返回？ option1：返回成功 option2：返回失败 option3：引入超时判断机制 ✘ ✘ ✔ 下单分布式事务 www.163yun.com 交易消息 www.163yun.com 某制造企业 • 大量遗留应用，多种语言开发 • 服务间直接调用，依赖混乱 • 调用记录无迹可寻 • 环境与接口规范缺失，维护困难 • 安全靠白名单各自为战

58集团技术专场 2. 监控平台 案例 问题 � 群内反馈 � 客服投诉 � 用户先感知 � 平台成本高 58集团技术专场 系统是否正常，我们知道么？ 58集团技术专场 误区：监控是运维的事情 58集团技术专场 2. 监控平台- 最佳实践 � 单维度正常，能说明系统正常吗？ � 什么是立体化监控？ � 怎么个多维度法？ （1）机器、操作系统 （2）进程、端口 （3）日志 （4）接口 58集团技术专场 2. 监控平台-日志 ERROR日志监控Tips （1）路径规范 （2）日志分级 （3）日志切分 （4）易扩展的配置 日志关键字监控Tips （1）异常关键字 （2）正常关键字 （3）易扩展的配置 58集团技术专场 2. 监控平台-接口 Keepalive统一监控 （1）框架统一实现 （2）中心统一调度 处理时间统一监控 （1）框架统一实现 （2）本地初步汇总

State 和 Realized State 声明式自愈系统的控制器协调循环 Observe Analyze Action u 观察当前的Realized State u 当前有2个正常运行的Pod u 比较Desired State跟Realized State的差距 u 期望3个Pod u 实际状态2个Pod u 控制器执行动作协调到Desired State u 创建1个新的Pod those languages are all describing state machines. Leslie Lamport TLA+试图用状态机而不是计算过程描述系统 更加关注系统的非正常输入 更加关注系统的稳定性可用性等特性而不是系统输出 分布式系统环境下没有单一的输入输出 TLA+是一种适合定义状态机的语言 定义一个状态机需要： 1. 定义所有可能的初始状态 2. 定义在特定状态下可能有哪些状态转换 验而且幂等，没有缓存情况下系统仍可服务 Ø 错误回复缓存，过期时间不能太长，而且有清晰的 修复建议 Ø 数据库更新与缓存失效的策略 最佳实践分享 有关配置文件 Ø 集群使用统一的配置来源 Ø 定义正常的默认配置，满足读取不到配置的正 常运行 Ø 支持可扩展的配置命令格式 Ø 尽量支持更改配置不需要重启服务 Ø 注意配置项之间的关联性 欢迎与我交流 王昕个人微信 欢迎与我交流 王昕个人微信

局部（用例）、动态 类之间的协作 状态机图 类、动态 所有的逻辑 测试 答对问题有奖金 金额从2.56元到20.48元 请扫我微信以便当场转账 加微信时烦告知尊姓大名 作用 逻辑内移 都以为自己在做正常的事情， 系统却出问题了 强制封装保护信息完整性 条件语句？泛化？不重要了 作用 帮助定义恰当的责任  专家原则、可视原则  减少get/set  接口变简单 要素 状态