狠狠撸

饿了么异构服务平台
数据访问层的演进
饿了么徐东焱

谁讲？
徐东焱
饿了么数据访问层架构师
曾在爱立信、PayPal任开发工程师
专注于C++/Java 中间件开发
dongyan.xu@ele.me dongyanxu@live.cn

? 不是
– 新技术推介
– 产物功能介绍
? 是
– 基于Java Netty.io 高性能服务的实践和踩过的坑
– 创业公司里繁杂需求中保持KISS原则的实际案
例
谁听？

业务背景
? 纯 Python 平台
? 18000服务实列
? 330万订单/日
? 产研团队急剧扩
张
? 引入java生态圏
? 标准化服务框架
? 引入数据访问层

主库从库从库
数据房问层(DAL)
服务A
DAL
主库从库从库
负截均衡负截均衡负截均衡
服务A 服务B 服务B 服务C 服务C
DAL DAL DAL
应用层
数据库层
中间件层

读写分离端口绑定主库端口
限流
水平分表
从库
负载
均衡
主库
事务
管理
从库
负载
均衡
DAL 架构概览
通道
B
通道
C
通道
D

限流、削峰
读写分离
熔断
DB连接复用
多客户隔离
DAL主要特性
一维分表、二维分表

DAL主要性能指标
控制DB实际并发度
<60，有效阻挡异常
流量冲击
单机1万 QPS（极限
4.8万）
单条SQL经过DAL平均
多耗时0.6ms
（和直连DB对比）
DB连接数从大于1.5
万下降到小于1千

DAL功能
基于用户痛点的演进

限流削峰
读写分离
一维分表
二维分表
MySQL以外的库
DBA：阻挡异常流
量的冲击
DBA：主库流量太
大，要把
查询分散到
多个从库
开发：不会有那么
严重吧？
开发：没时间改造，
最好接入
DAL就自动处理了
DBA：订单表太
大，
必须切片
开发：基于用户和
基于商户的
查询频度是同等的
DAL功能演进路线图

皮之不存毛将焉附
演进之前的架构选型

DAL架构选型(康威定律)
? 利益相关者
– DBA : 异常流量对数据库冲击大，@#￥&……
– 应用方：新特性任务急，少给我们加条条框框
– 管理层：稳定，稳定，稳定，重要的事情说三
遍
? 解决关键的用户痛点

百万级日订单量
(2015/4 )
DAL架构选型(技术要素)
主要服务类型:
python
新增服务类型: java、
node.js、go
流量峰值显著(午高
峰/晚高峰）
主要业务数据存于
MySQL

DAL架构选型(目标规纳)
独立进程服务，
支持多语言平台
业务可回滚到
DAL接入前的状
态
从简单功能开始
，DAL团队完全
掌握实现细节

DAL架构选型(产出)
Netty NIO
Netty NIO
事件驱动
SQL状态机
限流队列
MySQL 包解
码/编码器
MySQL
Python
应用
HAProxy
Java
应用
其它
应用

需求膨胀
不忘初心，DAL只是SQL代理

保持核心模块的纯净(需求膨胀)
? SQL黑名单
? SQL白名单
? 熔断
? 基于QPS的流量控
制
? 请求链追踪
此去省略N行……
限流削峰
读写分离
二维分表
一维分表
需
求
膨
胀
MySQL以外的库

保持核心模块的纯净(解耦)
? 其实DAL是一个SQL代理
? 坚决杜绝在核心模块中直接处理各项杂务
? 在独立的模块中实现各项功能，通过简单
的接口和核心模块整合

SQL状态机
(核心模块，SQL分析、重写、路由、结果集处理)
保持核心模块的纯净（熔断解耦）
客户端通讯组件
MySQL端通讯组件
AutoCommit
处理器
Commit
处理器
熔断
处理器控制器
MySQL

保持核心模块的纯净(调用链追踪痛点)
? 很难追踪异常SQL从那里来
? 当多个SQL被锁阻塞时，不易发现最开始持
有锁的事务执行的SQL

保持核心模块的纯净(调用链追踪解耦)
应用A
MySQL SDK
DAL
从SQL注释中提取SDK信息
应用B
从应用API提取
调用信息，
生成SQL注释
MySQL SDK
DAL核心模块

走出并发的沥清坑1(加锁.加锁! 加锁？)
Client DAL DB
发送请求
发送请求
返回结果
返回结果
回滚
中断
客户端超时
中断
服务端超时
顺序
执行，
从容
释放
资源
中断
是并
发的，
如何
正确
释放
资源？

走出并发的沥清坑2（去掉并发）
? Netty 线程只负责
传送字节流
? 所有SQL状态都在
SQL状态机执行器
中执行
? 一个SQL会话上的
任务路由到相同
SQL执行器线程，
排队依次执行，从
容检查当前状态
Netty NIO
Netty NIO
事件驱动
SQL状态机
限流队列
MySQL 包解
码/编码器
SQL状态机执
行器
SQL
事
件
队
列
SQL
事
件
队
列
SQL
事
件
队
列

要容灾切换，
就把切换变成常规操作

线上交换机故障
DAL成了最大的单点(问题)
多节点集群可靠吗？
备用交换机故障

集群迁移
不间断升级单节点拉入/拉出
集群
DAL成了最大的单点(方案)
以上三者其实是
一个功能

DAL成了最大的单点（不间断升级）
节点1 节点2 节点3
通道A 通道A 通道A
DAL代理
（七层代理）
服务发现
(zookeeper)
DAL集群A
? 节点1下线指令
1. 代理转发新连接到
其它节点
2. 节点1等待当前SQL
完成
3. 节点1等待当前事
务完成
4. 代理将现有连接迁
移到其它节点
? 节点1 升级重启
? 节点1 上线
注
册

DAL成了最大的单点（容灾迁移）
节点1 节点2 节点3
通道A 通道A 通道A
服务发现
(zookeeper)
集群A
DAL代理
（七层代理）
节点2 节点3
通道A 通道A
集群B
? A集群所有节点下线
? B集群中所有节点上
线
? 上、下线以机器为
单位，不是集群
注
册

? 方案：以客户痛点为中心
? 实现：坚守KISS原则
? 容灾切换：随时切换
总结

饿了么异构服务平台数据访问层的演进

狠狠撸

饿了么异构服务平台数据访问层的演进

Recommended

More Related Content

Viewers also liked (12)

Similar to 饿了么异构服务平台数据访问层的演进 (20)

饿了么异构服务平台数据访问层的演进

Editor's Notes