【稳定性day4】美团外卖高可用的演进之路 - 日活两千万的挑战

本文介绍了美团外卖在面对日活两千万挑战时,其技术架构的演进和稳定性保障策略。从最初的快速上线到服务化拆分、引入中间件,美团外卖逐步实现了系统的高可用。在应对业务高峰、复杂业务流程和快速迭代带来的挑战时,美团外卖通过日常运行的稳定性设计、事前预警、事故处理和事后总结四个阶段来保证系统的稳定性。重点强调了服务化、依赖稳定性原则、在线压测、分层监控和业务监控的重要性,并分享了事故处理的经验和教训。
摘要由CSDN通过智能技术生成

本文来自美团曹振团老师的分享。

技术体系架构演进

简单介绍一下外卖现在的情况:我们从2013年10月份做外卖的事情,是从餐饮外卖开始的。经过两年多的发展,我们不光可以提供餐饮外卖,也可以提供水果、鲜花、蛋糕、下午茶甚至是超市和便利店一些外送的服务。我们做外卖过程中,我们发现用户对外送的体验有两个关注点:

  1. 第一个是品质,用户对品质要求非常高,送过来的饭不能凉了,不能不好看,送餐员身上脏兮兮也不行会影响食欲的;

  2. 另外一个关注点要准时,一定要按时间送到,比如我要求按12点送到就一定要按12点送到,不能早也不能晚,如果早为什么不好呢?11点40送到不行,我们正在跟老板开会,一会一个电话太烦了;12点20送来也不行,太饿了,我都饿晕了,中午也有很多的安排,吃完饭可能要睡一会,中午不睡下午崩溃呀。

我们发现如果要把用户体验做到极致的话,做得足够好能保证用户得到足够好的体验,我们就要做专送的服务。所以我们正在做的是美团外卖的平台和我们自己的配送服务。

我们从2013年10月份确立做这个事情,到11月份正式上线,到14年底11月份时突破日订单一百万单,15年的5月份大概突破了每天两百万单,然后大概15年12月份做到每天三百万单,今年5月份的时候我们做到了四百万单每天。我们希望在响应国家大的号召下,我们做供给侧改革。我们希望给大家提供更多的、优质的、可选的外送服务,希望未来的某一天做到每天1000万单。

介绍一下我们的业务,也介绍一下在做这个业务过程中技术架构的演进的历程。我们在开始做外卖的时候发现,那时候都是通过电话来点外卖的,小餐馆的老板发传单,我们用传单上的电话给老板打电话下单。我们在思考我们是不是可以把电话点餐的事情变成网络点餐,让用户只需要在网络上点点点就行了,不用打电话。

于是我们在公司周围的商家摸索这个事情,我们早上下了地铁在地铁口发传单。我们怎么能够最快地去验证这个事情是否可行?

我们提供了一个非常简单的Web版本和Android的App,对于商家那一边我们没有提供任何软件的服务,用户在我们平台里下单以后,我们再打电话给商家下单,有时候我们是发传单的,有时候我们是接线员,用户在我们平台上下单,我们再打电话给商家下单,然后再去写代码。那时候基本上没有太多架构考虑,就是怎么快怎么来,以最快的速度去把我们的功能给变上去。 

这个事情我们验证之后发现确实可行,我们发现“懒”是极大的需求。因为懒得去换台,所以发明了遥控器,懒得爬楼梯就发明了电梯,人都是很懒的,因为懒得打电话订餐,所以在网上点点点就好了。

我们发现这是极强的需求,于是我们就考虑规模化,因为只有规模化之后边际的成本才可以变低,这套软件在一个区域可以用,在一个城市可以用、在全国也可以用,我们的开发成本就是这么多,所以我们在尝试在做规模化。

这个过程爆发性产生了非常多系统,我们在用户这边提供各种APP,商家这一边我们也开始提供服务。我们给商家提供PC的版本、App版本,还给商家提供打印机。

打印机是跟我们后台是联网的,如果用户在我们平台上下单,我们会直接推送到这个打印机上,这个打印机可以直接打出单子,同时可以用林志玲或者郭德纲的声音告诉你:“你有美团外卖的订单请及时处理”,这是对商家非常好的效率提升;同时我们给自身运营的系统加了很多功能,我们有上单、审核等各种各样的系统等爆发性地产生了。

在这个阶段我们业务发展特别快导致我们堆了特别多的系统,这个时候也并没有做非常清晰的架构,就是想把这个系统尽快地提供上线。这时候所有的表都在一个数据库里,大家都对这件事情非常熟悉,我可以做订单,也可以做管理系统。

但是这个事情在规模化、用户量迅速上升之后给我们带来非常大的困扰,因为之前我们是有很多技术欠债的,在这个阶段里面我们就做了重大的架构调整,在这个调整里主要说两点:

  1. 第一点就是拆 
    我们把很多耦合在一起的服务做服务化拆分,服务与服务之间通过接口来调用和访问,服务自己保护自己的库:不能访问别人的库,否则叫出轨;你的数据库也不能被别人访问,否则叫绿帽子。

  2. 第二点是中间件 
    我们在这个阶段引进了很多中间件,包括了在开源基础上自研的KV系统,我们也引用了搜索Elasticsearch,我们通过Databus抓取数据库的变更,把数据库的实时变更刷到缓存和索引里,让这个中间件做到稳定可靠的服务。 

总结一下的话,我们的演进大概分了这样一个阶段:整体上有一个多逻辑耦合在一起的情况按服务化拆分出来,每一个服务独立专注地做一个事情,然后我们再做应用级的容错,到现在我们在做多机房的容错。

在缓存上,我们早期使用了Redis,在Redis Cluster还没发布之前我们用了他们的Alpha版本,当然也踩了很多坑。后来我们用了自研的KV系统,最早的时候我们把所有业务的KV都是共用的,这个也有很

  • 2
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值