1. 聚能聊>
  2. 话题详情

谁丢了我的外卖订单,来聊聊如何保障O2O线上业务稳定

昨天中午我室友饥寒交迫的从外面,回到寝室就想很一口热乎的粥,然后高高兴兴的抢了一张某团粮票点了一份十块钱的粥就等着外卖小哥送来拯救自己了,然后的事情相比大家都知道了,支付成功了以后却没有反应了,然后就是迟迟等不到商家接受订单。

差不多是在中午 11 时左右,网友们纷纷发微博反应状况:

  • 美团外卖订单付款出现延迟

  • 在真实地付款之后,美团后台系统提示尚未付款成功

  • 支付完成,却没有订单出现

  • 团购页面一直处于加载中,无法正常显示

更是有不死心的小哥连续多次付款:

image

然不止美团,大众点评也如此,服务器出现大面积崩溃,App 的外卖、团购业务均受到影响。而后,据悉美团外卖的在线客服、电话客服疑似被“打爆”,系统繁忙无法接入。美团外卖的置顶微博评论区也“沦陷了”,网友纷纷吐槽付款/退款等问题。

然后各路抖机灵的段子手都开始纷纷出动了:

image

还有刚经历过碰壁的微博技术小哥的抖机灵:

image

群众的外卖问题从来都不是小问题,吃不饱怎么能更好的发挥生产力呢!就让我们来聊一聊:

1. 你是怎么看待异地多活的重要性的?

2. O2O架构究竟应该如何设计?

3. 应当如何做好极端事件的快速恢复?

4. 没外卖订了你会怎么办?吃不饱怎不办?(option)

参与话题

奖品区域 活动规则 已 结束

  • 奖品一

    虾米VIP月卡 x 2

  • 奖品二

    云栖定制鼠标垫 x 2

  • 奖品三

    定制笔记本 x 2

9个回答

2

北方的郎 已获得定制笔记本 复制链接去分享

1. 你是怎么看待异地多活的重要性的?
异地多活是重要系统的标配啊,“两地三中心”,“异地多活”你值得拥有。
不过这个具体的实现就要看系统规模及使用者的情况了。如果是大型集团的大型系统可以自建,如果是小公司和小应用可以选择具备这种能力的云服务,比如阿里云。其实即使对于大公司,把自己的私有云和阿里云等公有云组成混合云也是一个很好的尝试,用好了也可以提高系统抗击风险的能力。

2. O2O架构究竟应该如何设计?
O2O作为一个2C的平台,具有流量较大,而且随着活动会有爆发性的增长,另外还要考虑恶意的攻击和羊毛党。所以对系统的并发能力,稳定性,安全性等等要求都相对比较高,所以服务化,读写分离,分库分表,纵向拆分,横向拆分,应用缓存,限流保护,网络安全等等这些都是要考虑的。

3. 应当如何做好极端事件的快速恢复?
首先是数据,只要数据还在一切都好说,数据没了就是真的完蛋了。即使数据能恢复,解决起来也通常比其他的问题要麻烦。还有一点就是在应急起系统的时候一定要注意不要把数据的一致性搞坏了,否则过后会很麻烦。
其次就是看你事先的准备情况了,如果你以前有准备而且有经过验证的预案,那么就按照预案来执行好了。在做预案的时候要经过充分的论证,不能想当然,比如挖掘机把你主机房的对外的线缆都挖断了,你如果直接把这部分流量直接导到其他机房,它不一定能扛得住,这时候你可能就需要限流了。
如果事先没考虑,没准备,那么就只能临场发挥,自求多福了。

4. 没外卖订了你会怎么办?吃不饱怎不办?(option)
自己做呗,呵呵,给家人做一顿好吃的,他们Happy的吃的时候,你会觉得很快乐的。

可以的话,给个笔记本吧。

飘落的白雪 回复

😊😊😊😊

评论
0

aoteman675 已获得虾米VIP月卡 复制链接去分享

  1. 你是怎么看待异地多活的重要性的?
    这就是两地三中心的重要性了,本地挂了,异地迅速开启业务。如果没有做好备灾演练,异地多活存在不确定性,很可能无法恢复业务。
  2. O2O架构究竟应该如何设计?
    逐层解耦,日常监控分析,支付数据做好回滚操作,确保数据准确性,遇到问题迅速加锁数据库,使支付无法使用,可以保证业务的正常有序和安全性。
  3. 应当如何做好极端事件的快速恢复?
    做好备灾演练,同时保证异地两台服务器的活力,形成环路保护,平时做好相互保护即可。
  4. 没外卖订了你会怎么办?吃不饱怎不办?(option)
    自己煮呀!总不能吃键盘吧
洋气上神 回复

自己学会做饭

白芷甘草 回复

吃泡面

评论
1

夏之冰雪 已获得虾米VIP月卡 复制链接去分享

1. 你是怎么看待异地多活的重要性的?
平时不出事,看不出重要性,一旦出事,就非常重要了。

2. O2O架构究竟应该如何设计?
水平垂直都要做,分层,业务解耦。
以及完整的日志体系,数据流转跟踪,监控等。

3. 应当如何做好极端事件的快速恢复?
轮岗制,24小时相应。
定期线上模拟,针对重要业务明确预案细节。

4. 没外卖订了你会怎么办?吃不饱怎不办?(option)
一直做饭,做饭也是一种创造,我觉得会做饭的程序员才是一个好厨子!

1

hikingx 已获得云栖定制鼠标垫 复制链接去分享

群众的外卖问题从来都不是小问题,吃不饱怎么能更好的发挥生产力呢!就让我们来聊一聊:

  1. 你是怎么看待异地多活的重要性的?
    异地双(多)活。而异地双(多)活,却是指有两个或者多个可以同时对外服务的节点,任意一个点挂了,也可以迅速切换到其他节点对外服务,节点之间的数据做到准实时同步。

跨机房的流量是花钱的。所以不是无限大的。控制跨机房消息体大小,越小越好。然而,很多时候要想保证数据同步是一件很耗费流量的事情。但跨机房流量真的是一座山。

  1. O2O架构究竟应该如何设计?
    同城灾备,异地备份。现在行业主流的两地三中心建设。
  2. 应当如何做好极端事件的快速恢复?
    如果机器资源不足,建议优先将一些体系独立的服务整体迁移,这样可以为核心服务节省出大量的机架资源。如果这样之后,机架资源仍然不足,再做异地多活部署。

谨慎挑选第二机房:尽量挑选离主机房较近(网络延时在10ms以内)且专线质量好的机房做第二中心。这样大多数的小服务依赖问题都可以简化掉,可以集中精力处理核心业务的异地多活问题。同时,专线的成本占比也比较小。
注意机房间的延时问题,延时大的可能达到100ms以上,如果业务需要多次跨机房请求应用的话,延迟的问题会彻底放大;
跨机房的专线很大概率会出问题,要做好运维或者程序层面的容错;不能依赖MySQL双写,必须有适应自身业务的跨机房消息同步方案;

  1. 没外卖订了你会怎么办?吃不饱怎不办?(option)
    这个要求充足的备货,攻城狮必备:方便面、老干妈。。。。。。。。。。。

希望一个鼠标垫!

1

水灵儿 已获得定制笔记本 复制链接去分享

哈哈,占个楼先

  1. 你是怎么看待异地多活的重要性的?
    异地多活其实是不太理解了,字面理解,分布式架构的一种吧
  2. O2O架构究竟应该如何设计?
    这个感觉问的深了,多个集群咯
  3. 应当如何做好极端事件的快速恢复?
    回滚,最先想到的反应,应该大公司都有plan b吧 ,同样一份服务替换上
  4. 没外卖订了你会怎么办?吃不饱怎不办?(option)
    公司吃呀,so easy

哈哈,求笔记本一枚

0

浮生递归 已获得云栖定制鼠标垫 复制链接去分享

鼠标垫~鼠标垫~鼠标垫~

  1. 你是怎么看待异地多活的重要性的?
    区域网络出问题还是比较常见的,只是很多企业都做了异地多活,所以我们平时并没有感觉出来。越大的企业,受众也越大,影响也越大。所以如果大企业没有做好异地多活的话,我们马上就能感觉到,比如这次的美团(此处指感觉到,不是说他们没做好异地多活)。但是这次美团事件,我觉得并不是异地多活没做好,应该是其他方面的原因。现在的技术架构下,已经很难因为一个区域的机房挂了,导致用户无法正常使用了。像段子里的这2种情况都是早年才会发生了,说明段子手并没有与时俱进。
  2. O2O架构究竟应该如何设计?
    O2O最大的特点应该是分布式,或者说跟物联网的雾计算有点相似。每个地区都有自己的计算和网络中心,信息就近处理反馈,才能有最好的体验,同时也大幅降低了网络压力。同时结合异地多活。本地挂了,马上无缝启动异地灾备。
  3. 应当如何做好极端事件的快速恢复?
    技术是一方面,公关也是一方面。出现极端事件,宣传部门要第一时间做出反应。不隐瞒,不搪塞。公众就会安心等结果,不然就会各渠道跟着一起瘫痪。
  4. 没外卖订了你会怎么办?吃不饱怎不办?(option)
    下楼走上十几米,还有几家小面馆。家里也做了灾备和异地多活。有面包、零食、泡面、米、矿泉水、大量饮料等等,真饿不到。
0

桀骜逍遥 复制链接去分享

这个事情好像就是前两天的事情吧,我们授权服务中同事还在说,美团该换服务器了,全部换成阿里云的,就不会出现这样的问题了,不过阿里确实可以做一套解决方案供美团高层参考一下了

聚小编 回复

手工点个赞

桀骜逍遥 回复

谢谢

评论
0

吕大哥 复制链接去分享

666666666666

0

kiss老王 复制链接去分享

666666666666666666666666666666666