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