美团收银灰度发布设计与实践
如果无法正常显示,请先停止浏览器的去广告插件。
1. 美团收银灰度发布设计与实践
美团餐饮⽣态事业部
2. 我的经历
美团收银-技术专家
7年互联⽹⼯作经验,2017年加⼊美团,主导了美
团收银灰度系统的建设。原⾼德资深开发⼯程
师,⻅证了⾼德开放平台⼗亿级到百亿级流量的
过程。
2
3. ⽬录
1 灰度发布介绍
2 灰度发布设计思路
3 灰度发布衍⽣问题
4 灰度发布未来规划
3
4. 灰度发布是什么?
在⿊与⽩之间,能够平滑过渡的⼀种发布⽅式。
Load Balancer
V1
V1
V1
⾦丝雀发布是灰度发布的⼀种实现形式。
4
5. 灰度发布的业务价值
发布影响
可控
$
5
线上验证
6. 灰度发布的应⽤场景
微服务的灰度上线
移动端的灰度发版
6
7. ⽬录
1 灰度发布介绍
2 灰度发布设计思路
3 灰度发布衍⽣问题
4 灰度发布未来规划
7
8. 美团收银灰度实施挑战
线上引流
团购
排队
平台服务灰度上线隔离业务影响
预定
外卖
⼈⽓值
线上
业务复杂,架构复杂
⽀持业务服务灵活灰度
买单
前厅
后厨
点菜
KDS
后台
⽀付
⾦算盘
线下体验
8
PC后台
打印机
全渠道⽤户消费⾏为数据中⼼
9. 为什么需要灵活灰度?解决⽅案是什么?
微
服
务
间
⾃
底
向
上
发
布
⾃底向上逐⼀灰度,上线
时间变⻓影响交付。
⽀持链路灰度、⽀
持单独灰度
微服务内部采⽤滚动发布
9
10. 灰度实施关键
分流&染⾊
服务分组
分流:逻辑分流(程序内部分流,如AB测试)、物理分流(机器维度分流)
染⾊:请求染⾊(灰度请求、⾮灰度请求)后依赖分布式调⽤链传递
(Zipkin、MTrace、Sleuth)
服务分组:灰度分组、⾮灰度分组
10
11. 分流实施关键
1)分流正交性
2)分流稳定性
分流正交性
11
分流稳定性
12. 微服务基础设施决定分流⽅式
基础设施薄弱、运维⽔平低,可采⽤逻辑分流。
基础设施健壮、运维⽔平⾼,可采⽤物理分流。
12
13. 逻辑分流实现灰度(程序内部分流)
上游对流量染⾊并传递
⼀个A/B
单独灰度
上下游服务共⽤⼀个A/B
逻辑链路灰度
13
14. 逻辑分流计算⽅式
AB元数据下发⼀致性 ⽹络耗时可接受
全部成功 超时后降级到本地缓存
ABServer
客户端计算模式
服务端计算模式
14
15. 物理分流实现灰度-常⻅服务发现模式回顾
集中式代理 嵌⼊式代理
DNS Dubbo
15
SideCar
ServiceMes
h
16. 物理分流-服务分组粒度
多个服务⼀组,组成
灰度链路,适⽤于业
务迭代。
单个服务⼀组,单独
灰度,适⽤于重构、
性能优化。
16
17. 物理分流-服务分组边界
灰度分组建⽴后,不能随意增减服务
如出现右图,要建新的分组,分组2要包分
组1的代码,且分组2不能先于分组1全量。
17
18. 物理分流-组内、组间分流规则
组内分流:直接复⽤服务发现的原⽣能⼒,优先组内分流,组内不可⽤时考虑
fallback的场景。
组间分流:统⼀⽹关计算好⼀个调⽤要经过哪些分组,并向下传递。
18
19. 平台服务灰度问题
智能版收银 ⻘春版收银 智能版收银 ⻘春版收银
⽀付平台 ⽀付平台 ⽀付平台 ⽀付平台
1)⽀付平台同时⽀持智能版收银、⻘春 2)⽀付平台灰度完成不能直接全量,可
版收银
能会影响⻘春版收银
20. 平台服务灰度解决⽅案
智能版收银 ⻘春版收银 智能版收银 ⻘春版收银
⽀付平台 ⽀付平台 ⽀付平台 ⽀付平台
3)按业务线切流,将⻘春版收银的流量 4)按业务线灰度后,再全量部署
切⼀部分到灰度环境
20
21. 收银灰度架构示意图
21
22. 灰度发布设计思路总结
逻辑链路(AB测试)
优点1)实现简单;2)微服务部署⽆顺序之分;3)运维简单;4)快速回滚
不⾜1)侵⼊代码;2)灰度场景覆盖不全(jar包升级)
物理链路(服务分组)
优点1)不侵⼊代码;2)灰度场景覆盖全;
不⾜1)实现复杂;2)对基础设施、运维能⼒要求⾼;
22
23. ⽬录
1 灰度发布介绍
2 灰度发布设计思路
3 灰度发布衍⽣问题
4 灰度发布未来规划
23
24. 前后端协同灰度解决⽅案
移动端灰度发版
解决⽅案:基于version灰度
微服务灰度上线
24
25. 消息Kafka灰度⽅案
MQ存在分发到特定分组的场景
即消息发送⽅、消费⽅在同⼀个分组内
灰度⽅案
新增topic,即不同分组间⽤不同的topic
分组A 微服务
A TopicA 微服务
B
分组B 微服务
A TopicB 微服务
B
26. 分布式配置&分布式任务灰度⽅案
分组A
分布式配置:按分组下发
分布式
配置
下发
分组B
任务
分发
分布式任务:逻辑分流
27. DB&KV存储灰度⽅案-考虑兼容性
DB:处理⽅式,不修改旧列,只新增列,
新增列要双写,后续再下掉双写逻辑。
KV:同DB处理⽅式⼀样,KV数据⼀般都
是结构化的数据,以json为例,不修改旧
字段只新增字段,过期key定期清理。
28. ⽬录
1 灰度发布介绍
2 灰度发布设计思路
3 灰度发布衍⽣问题
4 灰度未来规划
28
29. ⾦丝雀发布灰度问题
物理链路灰度后,全量
部署期间有什么问题?
1、全量期间服务部署顺序
智能版收银 智能版收银 智能版收银
⽀付平台 ⽀付平台 ⽀付平台
有依赖,需要⼈去梳理,效
率低
全量期间,微服务内部采⽤滚动发布
2、存在旧服务调⽤新服
务,旧调新的兼容性测试实
智能版收银 智能版收银 智能版收银
⽀付平台 ⽀付平台 ⽀付平台
际未测试、未灰度过,有⻛
险
旧调新,未验证过、未灰度过
29
微
服
务
间
⾃
底
向
上
发
布
30. 解决⽅案-蓝绿发布
收益:
提升上线效率
降低测试成本
⽆兼容性⻛险
30
31. 总结
项⽬特点决定发布选型
架构简单,规模庞⼤,优选⾦丝雀发布。
架构复杂,规模不⼤,优选蓝绿发布。
31
32. Q&A
32
33. 投递邮箱:wangying49@meituan.com
招聘职位信息