《高速发展的饿了么订单系统架构演进》.pdf

高速发展的饿了么订单系统架构演进 ArchSummit全球架构师峰会深圳站2016 石佳宁 今天要讲的内容 • 高速增长和愈加复杂的交易场景下，支撑饿订单的海量服务架构 是如何演进的? • 关于 design for failure 我们做了哪些努力? 快速增长 业务场景 服务架构演进 订单架构 - 早期 服务架构演进 • 明确的定义 • 松耦合 • 基于领域认知 • 单一职责 关注分离 • 可被验证的结果 服务架构演进 订单服务拆分后架构 ? 服务架构演进 • 订单是支撑整个交易链路的核心服务,周边围绕了一些相关服务, 比如: 金额计算服务、催单服务、售中异常服务等等 • 订单实时处理是整个链路的中心,我们将这个过程定义的尽量简洁 • 考虑到交易的时效性和交易的异常场景会越来越复杂,我们将交 易线分为正向交易流程和逆向交易流程 • 能够在功能或者业务上独立的部分,我们尽可能抽象为单独的模 块或服务 服务架构演进 缓存服务演进 早期缓存逻辑架构 缓存服务演进 当前缓存逻辑架构 数据库服务演进 DAL - 数据库中间件 数据库服务演进 监控告警演进 • 订单”吞吐量”是最需要重点关注的指标 • 通常我们重视系统指标,容易忽略业务指标的关注,而其实业务指标更能反映出隐晦 的问题 • 目前我们致力于基于监控和数据学习的过载保护和业务自动降级 饿订单完整架构 design for failure • 消息广播补偿 • 主流程补偿 • 灾备 • 随机故障测试系统 消息广播补偿 • 对于订单而言MQ是非常核心的基础组件,当它发生抖动或者异常的时候,订单的实时 处理链路也会受影响 • 当紧急情况发生MQ无法立刻恢复的时候,其他关联服务可以先通过补偿服务 主流程补偿 • 由来: 对于主要链路的保护,针对链路本身出问题的情况,最大程 度的保证交易 • 原则: 对于订单的各个状态进行推进或拉取,相对而言保证最终 一致性,链路和介质独立于原流程 • 部署: 提供补偿功能的服务应该和主服务分开部署，依赖的服务 也需要使用独立实例，以保证高可用 • 效果: 用户支付成功前所有信息应该尽量入库,可以对待支付、 支付、待接单、接单一系列环节进行补偿 主流程补偿 灾备 随机故障测试系统 Kennel Kennel • 帮助我们发现链路上中隐蔽的缺陷,将小概率事件放大 • 重大的功能可以在发布之前通过其进行测试,迫使你更深入的设 计和编码 • 通过随机的故障攻击,可以验证你的监控和告警系统以及故障响 应机制是否如预期般工作 • 验证你FailOver的设计,只有验证过才可以作为依靠