PART1:李哥技术老师的参与双11年中大促作为技术负责人的一些经验复盘
将故事分为三大部分:事前、事中、事后。

  • 事前:基本上就是相关人员聚在一起商量商量么

    • 开会沟通:参加一个全局的,整体的KO会议(Kick Off Meeting,项目启动会),商量目标啦、人员咋安排,工作如果分阶段进行呀等等。我们技术需要从中获取如下信息:

      • 业务预期DAU、业务预期DAT、具体有哪些活动玩法、活动玩法的具体时间段、哪些商品参与大促,是否有第三方商品、这些商品的库存分别是多少【对于一些细节,下来我们需要与业务进行沟通,比如活动粒度是多少?宣传力度是多少?业务的预期DAU与DAT如何评估的?是否准确?
    • 流量评估:要清晰的知道,当前阶段每天的流量、DAU、DAT是多少,业务评估是多少,技术侧评估又是多少,当前阶段的性能是否能支撑即将来临的大促,如果不能,需要做出什么调整
      • 优化?怎么优化?优化哪些业务?现在优化还来得及吗?
      • 扩容?扩容哪些服务?扩容到多少?为什么要扩容到这么多机器?
      • 降级?什么业务降级?业务是否支持降级?什么时候降级?
    • 业务梳理:
      • 需要梳理出哪些业务是核心业务,哪些业务是非核心业务,哪些业务是可降级业务,这类数据大致可以从上一次大促获取
      • 再加上上次大促到本次大促期间所产生的新项目(业务项目或技术项目)进行梳理,是否影响核心链路?是否进行了压测?压测结果如何?这些项目可能存在什么技术风险?
      • 你的服务依赖哪些下游服务,这些下游服务又是如何依赖的,这是个很麻烦的事情,因为随着业务变大,依赖关系会变得非常复杂,很难判断与梳理。尽管很难,但是这个依赖关系仍然要梳理清楚,只有梳理清楚了,才有全链路。
    • 压测:有了业务梳理和业务指标,那么就在技术上要能够支撑到这个业务级别,那就是压测了。压测一定是针对生产

      • 到目前为止有两种压测方式:

        • 不扩容压测:不扩容压测一般不推荐,这种方式需要对业务指标打折作为目标来进行压测,最后在扩容的时候还是需要压测一次,因为局部压测不能完完全全代表整体压测,如果整体压测出现问题,那么所有的局部压测都是白费苦工。
        • 扩容后压测:就是指 容量扩容到大促支撑位,然后进行压测
      • 压测一定是针对生产!
        • 对开发环境、测试环境、预发环境、灰度环境、仿真环境进行压测,从而推断出生产环境的性能。这是万万不可取的,因为环境不同,服务器的性能不一样,生产环境和其他环境的DB性能也不一样,还有一些中间件性能也不一样。所以,压测一定要在生产环境压测,但是有一个缺点,就是会对线上的正常流量产生影响,这也是不可避免的,所以 压测的时候,一般都会选择流量不大的时候进行,尽量减少对正常流量的影响,一旦产生影响,请立即停止压测
      • 压测需要流量爬坡:切记不可一步到位,按照一定比例逐渐施压,每一个坡度都观察几分钟,没问题继续施压,达到目标后观察几分钟没问题直接停止压测,不可恋战!因为大促的流量趋势就是那几分钟,长久的施压对服务器的性能有一定影响,比如CPU飙高啊,频繁GC啊等,所以在在压测过程中还需要不断观察系统整体性能,还有就是也会影响到正常的用户访问。举个例子,奥运会举重,明明只需要保证举起来三秒即可,你训练的时候难道要举起来三分钟吗
    • 限流:压测完了后,我们需要输出一份压测报告,比如商详支持多少qps,下单页支持多少qps,下单支持多少tps等。这些数据说明了,我们的系统,有多少实例,哪个接口能承受的最大峰值是多少。那么我们就需要对这个接口或这些接口做限流【所以,我们需要拿着我们的压测报告,针对我们的服务做单机限流与集群限流。】

      • 单机限流与集群限流:

        • 单机限流指的是每台机器自身的限流:机限流的目的是保护服务本身,保证自身服务不被流量击垮。
        • 集群限流指的是整个服务集群的限流:集群限流的目的是保护下游服务,保证下游服务不被当前服务击垮
          • 比如A->B->C,每个服务三台实例,整个B集群最大能支持150qps,C集群最大能支持100qps,那也就是说B服务需要设置集群限流100qps用来保证C,B的三个实例需要设置单机限流50qps用来保证自身不被击垮。所以如果流量不倾斜的话,B服务每个实例会有33qps,如果倾斜的话,最大50qps。
    • 降级:限流后,我们能够保证服务本身不被击垮,保证下游不被击垮,但是,这不是我们的目标,我们的目标是要保证大促期间商详没问题,下单支付没问题呀【所以,我们要降级,一些比较耗性能的业务降级,一些边缘业务降级,给核心业务让路。】
      • 然后就需要梳理这些业务,有哪些需要降级的业务?什么时候降级?由谁来降级?什么时候恢复等。
    • 应急预案与演练
      • 咱们之前都听过一个老板让两个员工去买西瓜的故事,是一样的,事前能够考虑到的风险或者危险越多,然后做好准备,那咱们自身的损失就越少。当我们保证了核心链路的正常后,我们还需要考虑异常的情况。对于电商系统来说,要考虑到整个生命周期异常的可能性,比如:打开商详页失败、打开订单渲染页失败、下单失败、履约失败等。说的都比较概括,我们当时准备了上千个预案!淘系双11大促,为了安全起见,是不会有任何依赖外部系统的,因为第三方系统都无法承受住淘系大促期间的流量波。

        • 如果你的电商系统有依赖外部系统的,那么你还要梳理出哪些渠道哪些商品会参与本次大促,这块也需要针对渠道做压测与限流,有可能渠道由于体系较小不支持压测,这时候你可能要考虑到在履约的时候做蓄洪与泄洪,使用真实流量来冲击渠道,用于检验渠道的性能。另外在有第三方参与的情况下一定 要有每个渠道的应急预案,对应给用户展示的文案是什么都是不一样的
      • 最重要的是要与合作伙伴共同制定一份SLA(Service Level Agreement):服务级别协议,服务提供商和客户之间的协议,用于确定所需的服务和预期的服务水平,对互联网公司来说是网站服务可用性的保证。
        • 在这里SLA约定了客户对于合作伙伴的线上运维、计划运维、业务连续性以及故障处理能⼒的要求。做完预案后,要通过预案平台进行演练,或者人工演练,要当做到熟能生巧,大促出问题后才会显得临危不乱
    • 监控:大促出问题?你怎么知道这块出了问题?这时候需要监控,需要告警。大促大盘监控、全链路监控、核心链路监控、压测监控、限流监控、资源监控、网关监控、渠道履约监控
    • 规范:大促期间是需要制定很多规矩,比如发布红线、红线问责、预案执行规范、紧急扩容规范、紧急发布规范…,我们这里统称大促变更规范吧。无以规矩不成方圆,制定这些规范的目的是能让我们明确问题发生后我们应该按照什么流程去应急还有很多其他的一些杂七杂八的,比如大促前每周周会、大促值班人员排班、大促作战室、问题的上升制度等
  • 事中:事中是整个环节最简单的,跨度最短的阶段,但是简单不代表不重要。主要是关注以下几件事情最重要的就是要持续关注告警与监控一旦出现问题需要及时响应与止血,严格按照预案执行。另外就是 关注大促每个场次的峰值情况,通过自动记录或人工记录的方式进行记录峰值,方便作为下次流量评估的依据
  • 事后:事后不就跟咱们博客文章复盘一样嘛,用以前的经验和东西为以后提供参考呗。
    • 事后我们最重要的就是要做大促复盘,盘点大促期间的一些好的点和不好的点,对于好的点如何延续到下次大促甚至更好,不好的点如何进行调整

      • 业务上关注哪些商品在哪些区域更好卖一些,哪些玩法更能让用户接受一些
      • 产品侧需要关注配合业务对于现有的产品模型做出一些调整与优化
      • 技术侧重点关注性能,本次大促是否存在性能瓶颈,瓶颈在哪里,如何优化,架构上是否需要调整,下次大促如何去支撑等
    • 其次是降级恢复,在大促前做的降级,在大促后需要对其恢复。不恢复可能有的功能就用不了了或者说不好用了或者说发挥不了原本的功能了
    • 我们还需要 对于系统存在的性能问题进行持续优化改进,然后进行压测,得出结论,再优化,再压测,优化,压测,…。【每到大促,如何保障系统高峰扛得住、长期平稳是每个大促人必须面对的问题。大促期间发生的每一个问题都可能被无限放大,所以我们需要谨慎对待,这开不得玩笑。】

PART2:JavaGuide老师的一个朋友分享自己在飞猪和美团基础架构组实习的经历【在飞猪的时候做业务,在美团的时候接触的是基础架构】

  • 组 > 项目 > 部门 > 公司

    • 团队氛围还是相当和谐的组?有没有传说中的 PUA 和阿里味?
  • 难处理的线上 BUG:
    • 慢 SQL
    • 本地缓存太大导致频繁 GC
  • 例子来自Java基基老师的一次生产环境P0级事故解决过程与原因分析:某地区信息化系统,周末升级系统以后,后面连续一周,持续出现系统不稳定、宕机、服务假死、数据库锁表等事件。甚至星期五下午,出现三个多小时无法恢复系统,造成恶劣影响【你这出现的问题有可能把客户都吓跑了,还得一级一级的人去给你擦屁股,那你作为开发者你扣点啥能行?再搞不好被投诉要是出现啥欺骗行为…我的天呐】,问题逐条分析如下:

    • 事件一之服务假死无法访问:系统出现大面积服务假死,访问长时间没有响应。服务器网络延迟也非常严重

      • 分析过程:一步一步排除之后,再查看数据库监控,发现数据库CPU和IO异常,通过DBA查询数据库挂起的脚本,发现有个update请求把数据库资源全部占用了,导致其他数据库请求无法进来或者响应非常慢,从而导致服务都假死了
      • 解决措施:系统优化,原来实例表是单表,数据量后续也会越来越大,就对程序做了改造,针对这张表做了分表功能(按照时间点建立分表,程序自动处理数据,自动建立分表,相应的查询统计等都做了调整)。增加了权限控制,更新实例功能只允许管理员角色操作;强化现场实施人员培训,哪些操作是决不允许在上线期限操作的

巨人的肩膀:
macrozheng老师的文章
极客时间中的各位老师
bilibili中的各位老师
https://mp.weixin.qq.com/s/6KWdncFMKZL3-JiwHKpe6w
李哥技术老师
芋道源码老师关于订单系统的主体框架和主要业务模块的讲述
JavaGuide老师以及老师的朋友
https://juejin.cn/post/7154563048689106952
why 技术
K8S中文社区的阿里云云原生的十眠老师
程序猿DD老师关于千万级高并发秒杀系统设计思路,很详细,遇到相关需求时值得反复学习

java基础巩固-宇宙第一AiYWM:为了维持生计,虽然咱没机会经历双11、美团、飞猪基础架构组这种型号的技术阅兵场,但是看看人家写的阅兵场日记,先xiao习xiao习一下嘛~整起相关推荐

  1. java基础巩固-宇宙第一AiYWM:为了维持生计,架构知识+分+微序幕就此拉开之Docker(Docker概念:容器、镜像、仓库)、操作命令、Docker网络、分层、K8S<->Docker~整起

    架构知识+分+微序幕就此拉开之Docker 一.为什么要搞这个Docker,咱们为啥要学,盖房子? 二.Docker的镜像与容器 1.预备知识:虚拟(机).容器(化) 2.Docker.镜像.容器 3 ...

  2. java基础巩固-宇宙第一AiYWM:为了维持生计,四大基础之OS_Part_2整起~IO们那些事【包括五种IO模型:(BIO、NIO、IO多路复用、信号驱动、AIO);零拷贝、事件处理及并发等模型】

    PART0.前情提要: 通常用户进程的一个完整的IO分为两个阶段(IO有内存IO.网络IO和磁盘IO三种,通常我们说的IO指的是后两者!):[操作系统和驱动程序运行在内核空间,应用程序运行在用户空间, ...

  3. java基础巩固-宇宙第一AiYWM:为了维持生计,Redis基础Part7(Redis常见使用(部署)方式:单机模式、主从模式、哨兵模式、集群模式)~整起

    Redis持久化:RDB.AOF是针对存储在一台服务器上的数据由于存储过程被打断而发生丢失的情况的.此时,咱们肯定要考虑到,所有鸡蛋都放在一个篮子里是会出问题的. 如果服务器发生了宕机,由于数据恢复是 ...

  4. java基础巩固-宇宙第一AiYWM:为了维持生计,四大基础之计网_Part_2(在浏览器中输入www.baidu.com后执行的全部过程、DNS的域名<->IP地址、OS协议栈的样子、CDN)整起

    可以说计算机网络,就是玩那几层中的那些协议们,本层玩,本层玩完了跨层玩,跨层玩,跨层玩完了本层玩- PART1:在浏览器中输入网站网址后执行的全部过程? 0.服务器在 80 端口等待客户的请求. se ...

  5. java基础巩固-宇宙第一AiYWM:为了维持生计,Spring全家桶_Part1-1(Spring左膀右臂中的左膀IOC第一篇~全是概念,Spring为啥辣么6)~整起

    我Java学的好好的,为什么要学spring框架呀[一般说 Spring 框架指的都是 Spring Framework,它是很多模块的集合]?或者说,成天喊简化开发,spring是如何简化开发的?或 ...

  6. java基础巩固-宇宙第一AiYWM:为了维持生计,架构知识+分布式微服务+高并发高可用高性能知识序幕就此拉开(一:总览篇)~整起

    PART1:项目情景发展历程:很久很久以后,敏小言和老胡开的小超市,突然发生了一些变故: 超市中除了柜台格子业务之外,还有用户.视频.签到.评论.数据处理等业务[之前,咱们项目中的用户.视频.签到.评 ...

  7. java基础巩固-宇宙第一AiYWM:为了维持生计,多高(多线程与高并发)_Part9~整起(单双列集合们、ArrayList 的扩容机制、HashMap、ConcurrentHashMap )

    再进入正文之前,先看看集合相关操作的时间复杂度: 本故事源自于~ 开唠: PART0: 为什么突然蹦出集合这个玩意,就是因为咱们基础那里学的"数组"不够用~: 数组一般用来保存一组 ...

  8. java基础巩固-宇宙第一AiYWM:为了维持生计,手写RPC~Version07(RPC原理、序列化框架们、网络协议框架们 、RPC 能帮助我们做什么呢、RPC异常排查:ctrl+F搜超时)整起

    上次Version06说到了咱们手写迷你版RPC的大体流程, 对咱们的迷你版RPC的大体流程再做几点补充: 为什么要封装网络协议,别人说封装好咱们就要封装?Java有这个特性那咱就要用?好像是这样.看 ...

  9. java基础巩固-宇宙第一AiYWM:为了维持生计,Redis基础Part2(Redis的数据结构)~整起

    PART1:Redis的数据结构:5+3数据类型<----------------->数据结构[未来随着 Redis 新版本的发布,可能会有新的数据结构出现,通过查阅 Redis 官网[[ ...

最新文章

  1. 一文详解ORB-SLAM3
  2. Windows开启SNMP服务----Win7
  3. 动态规划——编辑距离
  4. 失业状态,整理一下近期的面试问题 -- 直面自我
  5. linux添加了一条静态路由,为Linux新增静态路由的方法
  6. [转]linux用户管理
  7. JS控制图片滚动的效果
  8. oracle用户被锁
  9. JavaWeb——Mybatis进阶mapper代理
  10. 怎样才能恢复误删的数据-免费版本
  11. 如何运用接口中的变量?接口可以扩展吗?
  12. 苹果电脑mac系统空间不足怎么清理内存优化?最详细的教程分享
  13. win10下OpenJtag驱动安装
  14. 微软认知服务应用秘籍 – 支持跨平台客户端的视觉服务中间层
  15. PE新物种:从投基金到投管理机构,详解GP Stake-投资占股模式
  16. mac 上 csv导入Excel 出现 “此文本文件包含的数据无法放置在一个工作表” 错误
  17. PostGIS 笔记
  18. 如何使用python编程、字典中的get是什么_详细解析python字典get()实例教程
  19. 步进电机基础(8.1)-步进电机的问题解决方案-增加动态转矩的解决方法
  20. 利用浏览器的油猴插件下载网页视频

热门文章

  1. GitHub高赞!ASP.NET Core SignalR聊天室开源了!
  2. [百度]2014百度校园招聘之最长回文串
  3. 使用UltraISO制作U盘启动
  4. HTML5+CSS3+JS小实例:始终飞向鼠标的纸飞机
  5. 一年融资三轮,一文读懂亿格云这家公司
  6. 2019最好用的谷歌扩展工具
  7. 最美应用APP?最萌应用吧?
  8. 【每日早报】2019/11/29
  9. linux卸载先驱的命令是,【单选题】在Linux中,若要在同一行书写多条命令,命令之间应使用符号()分隔A. 转义字符\\ B. 分号; C. , D. 空格...
  10. 1.浏览器使用技巧,教你如何高效的使用搜索引擎(包含google和bd)