架构实战案例解析
王庆友
前1号店首席架构师
立即订阅
2041 人已学习
课程目录
已更新 15 讲 / 共 22 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 想吃透架构?你得看看真实、接地气的架构案例
免费
概述篇 (1讲)
01 | 架构的本质:如何打造一个有序的系统?
业务架构篇 (9讲)
02 | 业务架构:作为开发,你真的了解业务吗?
03 | 可扩展架构:如何打造一个善变的柔性系统?
04 | 可扩展架构案例(一):电商平台架构是如何演变的?
05 | 可扩展架构案例(二):App服务端架构是如何升级的?
06 | 可扩展架构案例(三):你真的需要一个中台吗?
07 | 可复用架构:如何实现高层次的复用?
08 | 可复用架构案例(一):如何设计一个基础服务?
09 | 可复用架构案例(二):如何对现有系统做微服务改造?
10 | 可复用架构案例(三):中台是如何炼成的?
技术架构篇 (4讲)
11 | 技术架构:作为开发,你真的了解系统吗?
12 | 高可用架构:如何让你的系统不掉链子?
13 | 高可用架构案例(一):如何实现O2O平台日订单500万?
14 | 高可用架构案例(二):如何第一时间知道系统哪里有问题?
架构实战案例解析
登录|注册

13 | 高可用架构案例(一):如何实现O2O平台日订单500万?

王庆友 2020-03-20
你好,我是王庆友。在上一讲中,我和你介绍了高可用系统的设计原则和常见手段。今天呢,我会通过一个实际的案例,告诉你具体如何落地一个高可用的架构,让你能够深入理解和运用这些高可用手段。

项目背景介绍

先说下项目的背景。这是一个小程序点餐平台,用户在小程序上点餐并支付完成后,订单会先落到订单库,然后进一步推送到门店的收银系统;收银系统接单后,推送给后厨系统进行生产;同时返回小程序取餐码,用户可以凭取餐码去门店取餐或收取外卖。
这个项目服务于一家大型的餐饮公司,公司在全国有大量的门店,他们准备搞一个长期的大型线上促销活动,促销的力度很大:用户可以在小程序上先领取优惠券,然后凭券再支付 1 元,就可以购买价值数十元的套餐。
结合以往的经验,以及这次的促销力度,我们预计在高峰时,前端小程序请求将会达到每秒 10 万 QPS,并且预计首日的订单数量会超过 500 万。在这种高并发的情况下,我们为了保证用户的体验,系统整体的可用性要达到 99.99%
你可以先了解一下这个点餐平台的具体架构:
这里呢,我具体说下系统主要的调用过程,以便于你更好地理解它:
小程序前端通过 Nginx 网关,访问小程序服务端;
小程序服务端会调用一系列的基础服务,完成相应的请求处理,包括门店服务、会员服务、商品服务、订单服务、支付服务等,每个服务都有自己独立的数据库和 Redis 缓存;
订单服务接收到新订单后,先在本地数据库落地订单,然后通过 MQ 同步订单给 OMS 履单中心;
门店的收银系统通过 HTTP 远程访问云端的 OMS 履单中心,拉取新订单,并返回取餐码给 OMS,OMS 再调用小程序订单服务同步取餐码;
小程序前端刷新页面,访问服务端获得取餐码,然后用户可以根据取餐码到门店取餐或等待外卖。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《架构实战案例解析》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(13)

  • 每天晒白牙
    很期待老师说的监控提前预警的方案
    老师我请教个和监控报警相关的问题,就是我们自己通过 prometheus+grafana 搭建了一套简单的业务监控报警,主要通过在代码中埋点,现在报警短信有点多,但里面有些报警也并不是很严重,所以就忽略了,但有时又会错过严重的报警短信,从而影响线上问题,所以后面把报警的阈值提高了,但感觉这样又有风险。
    想听听老师对监控报警这的最佳实战,比如怎么实现监控报警的生命周期管理?怎么通过程序化的方式来分析报警,减少人力消耗等

    作者回复: 监控数据一般有收集,分析和告警的过程,你这里缺乏后端的监控数据的分析系统,需要结合各种规则做综合判断后才告警。

    2020-03-20
    2
  • lyshrine
    请问老师,CAT的全程是什么?

    作者回复: Central Application Tracking,一个开源的应用监控组件,国内用的比较广泛。

    2020-03-21
    1
  • Jeff.Smile
    这讲最大的价值就是让普通公司的工程师见识到了大流量的应对架构设计,有了一个总体的轮廓和方向。
    2020-03-20
    1
  • 正在减肥的胖籽。
    下单后,订单放到redis中,如果redis数据写入失败?有做补偿吗?需要请教老师你们redis和数据库之间的数据怎么保证一致性?如果不保持一致性那其他系统是否就拉取不到订单?

    作者回复: 一种是把redis作为前置数据库,如果下单时,缓存写入失败,等于业务失败。当缓存写入后,如果缓存崩溃,这个问题不大,可以通过持久化缓存数据,重启后恢复。

    如果只是把redis当做缓存来用,我比较推荐写db的时候立即更新缓存或删除缓存,保证缓存和db数据的一致性。

    2020-03-20
    1
    1
  • 每天晒白牙
    感谢老师的实战经验分享,很干
    2020-03-20
    1
  • 夜空中最亮的星(华仔)
    这里讲,很棒,都是硬核
    2020-03-20
    1
  • 刘楠
    规模没这么大,只能想想,学习下
    2020-03-20
    1
  • 深山小书童
    非常棒!一早起来读到干货满满的文章,心情美美哒
    2020-03-20
    1
  • 天天向善
    每秒10万,能不能再给一些数字,改造后没有用云lb,自建nginx集群,这个云上也是有vip是吗,这个流量是每台机器设多少固定带宽?还有小程序服务端与基础服务共100个实例,还是仅小程序服务端,基础服务当时用了多少实例,另外一个容器大约cpu与内存什么配置
    2020-03-23
  • 川杰
    老师好,消息推送中心通过长连接的方式保持,但是每个长连接都有一定的资源消耗;如果上游的请求过多,这个资源消耗过大的问题怎么处理?

    作者回复: 这个只是简单连接,实际数据还是通过服务接口获取,几万个连接问题不大,也可以加机器增强处理能力。

    2020-03-22
  • zeor
    老师您好 请问下单时怎么保证超卖 请指教具体方案和实现

    作者回复: 办法很多,这里举两个例子:
    悲观锁,
        select for update 提前锁定库存
    乐观锁
         库存记录有个字段标识它的版本,读库存的时候,获取版本信息,比如1。后面更新的时候,检查记录的版本是不是还是1,如果不是,则写失败,如果是,则写成功,同时更新版本为2。

    2020-03-21
    1
  • image
    请教一下,生产环境使用redis做缓存,一般的部署模式是什么?sentinel,cluster, m/s?

    作者回复: 我们部署在公有云,之前是自搭的三节点cluster,现在直接买云的缓存服务,背后是m/s。

    2020-03-21
  • Alex
    限流、负载、分流、缓存、异步、仿真、监控都上了满满的干货
    2020-03-20
收起评论
13
返回
顶部