8 美团即时物流的分布式系统架构设计.docxVIP

8 美团即时物流的分布式系统架构设计.docx

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
美团即时物流的分布式系统架构设计 美团外卖已经进展了五年,即时物流探究也经受了 3 年多的时间,业务从零孵化到初具规模,在整个过程中积累了一些分布式高并发系统的建设阅历。最次要的收获包括两点: 即时物流业务对毛病和高延迟的容忍度极低,在业务简单度提升的同时也要求系统具备分布式、可扩展、可容灾的力量。即时物流系统阶段性的逐渐实施分布式系统的架构升级,最终处理了系统宕机的风险。 围绕成本、效率、体验核心三要素,即时物流体系大量结合 AI 技术,从定价、ETA、调度、运力规划、运力干涉、补贴、核算、语音交互、LBS 挖掘、业务运维、目标监控等方面,业务突破结合架构升级,达到促规模、保体验、降成本的效果。 本文次要引见在美团即时物流分布式系统架构逐层演化的进展中,遇到的技术妨碍和挑战: 订单、骑手规模大,供需婚配过程的超大规模计算问题。 遇到节假日或者恶劣天气,订单聚集效应,流量高峰是平常的十几倍。 物流履约是线上连接线下的关键环节,毛病容忍度极低,不能宕机,不能丢单,可用性要求极高。 数据实时性、精确?????性要求高,对延迟、特别格外敏感。 美团即时物流架构 美团即时物流配送平台次要围绕三件事开放:一是面对用户供应履约的 SLA,包括计算送达时间 ETA、配送费定价等;二是在多目标(成本、效率、体验)优化的背景下,婚配最合适的骑手;三是供应骑手完整履约过程中的协助决策,包括智能语音、路径推举、到店提示等。 在一系列服务背后,是美团强大的技术体系的支持,并由此沉淀出的配送业务架构体系,基于架构构建的平台、算法、系统和服务。浩大的物流系统背后离不开分布式系统架构的支撑,而且这个架构更要保证高可用和高并发。 分布式架构,是相对于集中式架构而言的一种架构体系。分布式架构适用 CAP 理论(Consistency 全都性,Availability 可用性,Partition Tolerance 分区容忍性)。在分布式架构中,一个服务部署在多个对等节点中,节点之间通过网络进行通信,多个节点共同组成服务集群来供应高可用、全都性的服务。 晚期,美团依据业务领域划分成多个垂直服务架构;随着业务的进展,从可用性的角度考虑做了分层服务架构。后来,业务进展愈加简单,从运维、质量等多个角度考量后,逐渐演进到微服务架构。这里次要遵照了两个准绳:不宜过早的进入到微服务架构的设计中,好的架构是演进出来的不是提前设计出来的。 分布式系统实践 上图是比较典型的美团技术体系下的分布式系统结构:依托了美团公共组件和服务,完成了分区扩容、容灾和监控的力量。前端流量会通过 HLB 来分发和负载均衡;在分区内,服务与服务会通过 OCTO 进行通信,供应服务注册、自动发觉、负载均衡、容错、灰度发布等等服务。当然也可以通过消息队列进行通信,例如 Kafka、RabbitMQ。在存储层使用 Zebra 来访问分布式数据库进行读写操作。利用 CAT(美团开源的分布式监控系统)进行分布式业务及系统日志的采集、上报和监控。分布式缓存使用 Squirrel+Cellar 的组合。分布式任务调度则是通过 Crane。 在实践过程还要处理几个问题,比较典型的是集群的扩展性,无形态的集群可扩展性相对较差,无法快速扩容机器,无法缓解流量压力。同时,也会消灭节点热点的问题,包括资源不均匀、CPU 使用不均匀等等。 首先,配送后台技术团队通过架构升级,将无形态节点变成无形态节点,通过并行计算的力量,让小的业务节点去分担计算压力,以此实现快速扩容。 其次是要处理全都性的问题,对于既要写 DB 也要写缓存的场景,业务写缓存无法保障数据全都性,美团内部次要通过 Databus 来处理,Databus 是一个高可用、低延时、高并发、保证数据全都性的数据库变更实时传输系统。通过 Databus 上游可以监控业务 Binlog 变更,通过管道将变更信息传递给 ES 和其他 DB,或者是其他 KV 系统,利用 Databus 的高可用特性来保证数据最终是可以同步到其他系统中。 第三是我们一直在花精力处理的事情,就是保障集群高可用,次要从三个方面来入手,事前较多的是做全链路压测评,估峰值容量;周期性的集群健康性检查;随机毛病演练(服务、机器、组件)。事中做特别报警(功能、业务目标、可用性);快速的毛病定位(单机毛病、集群毛病、IDC 毛病、组件特别、服务特别);毛病前后的系统变更收集。事后重点做系统回滚;扩容、限流、熔断、降级;核武器兜底。 单 IDC 的快速部署 容灾 单 IDC 毛病之后,入口服务做到毛病识别,自动流量切换;单 IDC 的快速扩容,数据提前同步,服务提前部署,Ready 之后打开入口流量;要求全部做数据同步、流量分发的服务,都具备自动毛病检测、毛病服务自动摘除;依据 IDC 为单位扩缩容的力量。

文档评论(0)

136****7795 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档