美团即时物流架构落地实践

本次分享内容

1. 项目背景
2. 分布式系统实践(单IDC、多IDC、SET化)
3. 智能物流核心技术沉淀
4. 未来的挑战

背景

美团外卖已经发展了多年，即时物流探索也经历了3年多的时间，业务从零孵化到初具规模，在整个过程中积累了一些分布式高并发系统的建设经验。最主要的收获包括两点：

1. 即时物流业务对故障和高延迟的容忍度极低，在业务复杂度提升的同时也要求系统具备分布式、可扩展、可容灾的能力。即时物流系统阶段性的逐步实施分布式系统的架构升级，最终解决了系统宕机的风险。
2. 围绕成本、效率、体验核心三要素，即时物流体系大量结合AI技术，从定价、ETA、调度、运力规划、运力干预、补贴、核算、语音交互、LBS挖掘、业务运维、指标监控等方面，业务突破结合架构升级，达到促规模、保体验、降成本的效果。

注：ETA（Estimated Time of Arrival，表示预计送达时间）

主要介绍在美团即时物流分布式系统架构逐层演变的进展中，遇到的技术障碍和挑战：

• 本次订单、骑手规模大，供需匹配过程的超大规模计算问题。
• 遇到节假日或者恶劣天气，订单聚集效应，流量高峰是平常的十几倍。
• 物流履约是线上连接线下的关键环节，故障容忍度极低，不能宕机，不能丢单，可用性要求极高。
• 数据实时性、准确性要求高，对延迟、异常非常敏感。

美团即时物流架构

美团即时物流配送平台主要围绕三件事展开：

一是面向用户提供履约的SLA，包括计算送达时间ETA、配送费定价等；

二是在多目标（成本、效率、体验）优化的背景下，匹配最合适的骑手；

三是提供骑手完整履约过程中的辅助决策，包括智能语音、路径推荐、到店提醒等。

在一系列服务背后，是美团强大的技术体系的支持，并由此沉淀出的配送业务架构体系，基于架构构建的平台、算法、系统和服务。庞大的物流系统背后离不开分布式系统架构的支撑，而且这个架构更要保证高可用和高并发。

分布式架构，是相对于集中式架构而言的一种架构体系。分布式架构适用CAP理论（Consistency 一致性，Availability 可用性，Partition Tolerance 分区容忍性）。在分布式架构中，一个服务部署在多个对等节点中，节点之间通过网络进行通信，多个节点共同组成服务集群来提供高可用、一致性的服务。

早期，美团按照业务领域划分成多个垂直服务架构；随着业务的发展，从可用性的角度考虑做了分层服务架构。后来，业务发展越发复杂，从运维、质量等多个角度考量后，逐步演进到微服务架构。这里主要遵循了两个原则：不宜过早的进入到微服务架构的设计中，好的架构是演进出来的不是提前设计出来的。

分布式系统实践

上图是比较典型的美团技术体系下的分布式系统结构：依托了美团公共组件和服务，完成了分区扩容、容灾和监控的能力。前端流量会通过HLB来分发和负载均衡；在分区内，服务与服务会通过OCTO进行通信，提供服务注册、自动发现、负载均衡、容错、灰度发布等等服务。当然也可以通过消息队列进行通信，例如Kafka、RabbitMQ。在存储层使用Zebra来访问分布式数据库进行读写操作。利用CAT（美团开源的分布式监控系统）进行分布式业务及系统日志的采集、上报和监控。分布式缓存使用Squirrel+Cellar的组合。分布式任务调度则是通过Crane。

名词解释：

OCTO*是 octopus(章鱼) 的缩写。是美团公司级基础设施，为公司所有业务提供统一的高性能服务通信框架，使业务具备良好的服务运营能力，轻松实现服务注册、服务自动发现、负载均衡、容错、灰度发布、数据可视化、监控告警等功能，提升服务开放效率、可用性及服务运维效率。*

HLB*是 Hardware Load Balance 的缩写。 所有HTTP请求/应答流量都会穿过这个系统，类似amazon elb。*

Zebra*（斑马）是美团基础架构团队开发的一个Java数据库访问中间件，是在c3p0基础上包装的美团内部使用的动态数据源，包括读写分离、分库分表、SQL流控等非常强的功能。它和MHA配合，成为了MySQL数据库高可用的重要一环。*

Squirrel+Celler*:美团在Redis Cluster和阿里的开源项目Tair基础上，分别自研开发了Squirrel和Celler两款KV存储系统。Squirrel全内存、高吞吐和低延迟，适合业务的数据量小，对延迟敏感，建议用 Squirrel ；Celler持久化、大容量、数据高可靠，适合数据量大，对延迟不是特别敏感，成本更低的Cellar 。*