美团收银灰度发布设计与实践

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
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 招聘职位信息

trang chủ - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.3. UTC+08:00, 2024-11-28 22:35
浙ICP备14020137号-1 $bản đồ khách truy cập$