百度外卖从2014年后,业务每天、每时都在经历高速的发展。技术架构在业务的发展中逐步锤炼升华,逐步从单应用的架构体系演化为复杂的服务化架构体系进行演进,此次演讲重点分享两点:1.外卖如何在业务高速发展的进程中进行服务化演进;2.大规模服务化系统治理的一种方法。
陈霖,10年7月入职百度,先后在百度知道、百度旅游、百度糯米、百度外卖工作;14年6月,加入百度外卖负责外卖交易架构;16年2月开始负责百度外卖基础服务架构团队。
外卖行业有明显的早晚高峰以及流量激增的情况出现,随着业务的超高速发展,交易流程日渐复杂,基于用户体验考量,百度外卖要求整个订单流程尽量控制在一小时内,这对服务化提出了不小的挑战。
百度外卖的服务划分基本是按照这三条线路进行,X方向是指可以通过加机器的方式提供服务能力,也就是副本。当简单的加机器已经解决不了问题的时候,Y方向的功能划分就派上用场了,将整体外卖业务细化为各个小服务。随着子功能的不断复杂,就需要进行分片了。
从最初的单一应用到服务切分,业务不断增大,无限制的服务划分会带来什么后果呢?服务之间又是如何关联的呢?如果服务划分不好,很容易出现网状结构,服务之间错综复杂,难以管理。好的服务切分应该可以清晰展现服务调用关系,允许跨层,可以多调用。清晰分层的基础上,引进异步消息队列,解决服务网状关系问题。
陈霖表示,百度外卖其实就是随着业务规模的扩大,数据库读写量的增大,不断进行螺旋式修改,循环拆分。在服务的拆分过程中,如何最大化为用户服务?依赖变多、调用链条变长的情况下,如何保证稳定性,尽量减少损失?服务统一管理,数据一致性等问题都亟待解决。百度外卖的整体RPC client可以协议打包管理,重点在负载反馈,可以自动检测异常,同时引入探活机制。多次动态重试保证数据一致性,服务之间调用RPC统一化,整体封装到统一框架。非重要服务提供柔性自动容错,通过分布式追踪系统更好地发现服务链调用关系。
理想很丰满,现实很骨感。理想中服务在流量增长到一定程度之后,仍然可以具备平稳的服务能力。而现实的服务往往在达到顶峰之后,基本处于不可用状态。百度外卖将服务分级,最高级别强依赖有分钟级别故障预案,次之依赖可以OP后台操作降级,最次之服务自动容错,优先拒绝次要服务,过滤无效流量,拒绝过载流量。
分布式追踪系统想必各大服务化中都会用到,百度外卖通过华佗系统进行分布式追踪,可以实时展现抽样请求调用链关系,快速查看线上请求情况;计算分析可能存在的架构风险,例如空连接、跨机房访问;通过日志分析架构全景,接口依赖关系,辅助线上业务梳理;监控服务访问变化,预判上线项目风险。
通过不断的改进与细化,百度外卖逐渐步入正轨。通过与不同领域的微服务技术的交流与碰撞,希望未来的O2O行业可以有更大的发展。
浏览7433次
浏览5253次
浏览4216次
浏览7657次
浏览9599次
浏览1401次
2025-01-08 昆明
2025-06-20 深圳
2025-04-19 南京
2025-08-15 上海
打开微信扫一扫,分享到朋友圈