这是一趟满载知识与启发的列车，由逆行老司机张飞扬老师负责开车，胆大的同学可以一探究竟，如遇身体不适，请及时下车。
接下来我们开车啦~~
问题一：一个初级的电商平台，如果下周要上秒杀抢购业务了，哪几个方面要赶紧准备起来？
A同学率先回答:应该优先考虑SQL优化，代码检查，压测，弹性服务器带宽。
B同学担心别人抢答，于是飞快的敲了两关键词：限流，削峰 （机械键盘，好带劲）。
C同学也打算回答限流，削峰，但刚要回车，看到B同学已经回答了，于是补充说：缓存也的考虑，并且主要是考虑大量请求的冲击，考虑请求量。
张飞扬老师一看这3位同学起码都回答到点子上了，很欣慰，于是表扬到：不错不错，都在点子上了。
当然这些考虑还不够完整，因此为了鼓励大家继续讨论，张飞扬老师提示说：限流、消峰是正解之一，不过题目是只有一周时间改造，所以有一部分基本功，比如分布式缓存改造、容器化弹性部署、可能来不及上线，所以我们要从立竿见影的方法中选则，大家还有没有更好的方案？
B同学飞快的回复：降级
张飞扬老师继续鼓励说：很好，B同学基本功挺扎实的嘛。
D同学见大家都在踊跃发言，插话道：服务容错，缓存双写一致性
张飞扬老师见大家回答的差不多了，心想自己再不讲，都没什么可说的啦，于是说道：一般分布式的主要保护方式有缓存、降级、限流，这些都是要成为优秀工程师或架构师的基本功，其中缓存一般初级网站都在用，不过短期升级比较难，降级和限流的改造方法有很多，有的像西药，是速成的。比如：专门应对秒杀的西药就是添加前置等待队列。
E同学好奇的问：是等待消费的意思吗 ？我这几年都是在传统企业里面做项目， 根本不用考虑这些。
张飞扬老师肯定的说：是的，不过速成方法对用户体验都有影响。比如：等待队列就影响转化率。
E同学听完还是困惑不解，说道：这块太专业了，不懂，老师能举例说明下吗？
张飞扬老师反手就是一个栗子丢了过去：“在用户登录或者点购买时出现的“您是第xxx用户，请耐心等待。”就是这类应用啊，不要说你没剁过手啊~”（我们做程序员的，哪有时间剁手，赚着2万的工资，过着2000的生活好吧。）
E同学恍然大悟：哦，原来如此， 好坑爹呀~
张飞扬老师表示同感：是的，比交易失败好些，但是用户体验是牺牲了不少，所以实际使用的时候也是需要谨慎对待，多维度权衡评估才好。大家现在不明白也没关系，等咱们课程到了第五阶段，我会带大家从容器的角度再悠一遍，让大家更深刻的理解这块的内容啦。
问题二：就是上面说的几种方案，哪些是可以结合容器技术来实施的？
张老师的车要逆行啦~ 这个问题涉及到容器化技术，如果没接触过容器化技术的同学，抓紧时间跳车啦。胆大的可以继续留下~
直接公布答案：各种技术都可以放在容器上，不过最和容器相关的是降级，一般秒杀都会提到容器化弹性扩缩容，但是有没有想过扩容的资源从哪里来？如果机房资源充足，或者公有云上米多就直接扩容，提前准备了，当然公有云还好些，可以容器化临时增长，但自建的环境就只能通过降级一部分业务，腾资源给热点业务了。
E同学果然是艺高人胆大，不仅没跳车，还提出了自己的见解：如果是购买的云服务器 ，只要购买弹性扩容就好了 ，如果是自己操控服务器的话 ，我应该只会提前准备，而不会在运行过程中加服务器 ，然后增加nginx 负载配置。
张飞扬老师赞同说：实际一般也是这样做的，根据之前的秒杀情况，提前调整资源。
E得到了张老师的肯定，很开心，然后继续追问到：刚才说的降级一部分服务是指通过配置不能让用户访问 ，还是直接停掉服务？
张飞扬老师说：降级的一个常见实现是停掉服务。
F同学默默的暗中观察，一直在等待一个机会，现在机会来了，于是飞快的敲了4个字：拉闸降级（果然高大上）
但在张飞扬老师眼里这个方案是再平常不过的了，于是他平淡的说道：是的，像亚马逊等公司就在很多模块里设置了这种降级，一旦触发后，前端界面里的相应组件会不再显示，如果后台没有弹性伸缩技术，降级可以通过应用层处理，但是就没有给其他业务腾资源的能力了。
张老师的一番讲解让G同学回想起自己15年的时候参加一个开源会的时候 ， 阿里云工程师当时说只能升容 （硬盘） 不能降 ，不解的问：难道现在可以了？
张飞扬老师追问道：你是说ecs虚拟机的硬盘容量调整？
G同学不好意思的回答说：，好久不用了， 现在不知道了。
张飞扬回答道：阿里这个功能我没用过，不过google的我用下来也都是这样，这个是与系统级别的磁盘虚拟化有关，技术上供给的硬盘可以动态回收，但是云的hyperwiser一般不会做这个，一般降级腾的资源主要在cpu和内存，比如要降级搜索，可以将数据连锁能力降级到只返回前20条，如果业务是容器化部署，就可以把搜索引擎实例数降低，这样就腾出cpu、内存了。
E同学质疑道：这种不是涉及到代码层了么 ？
张飞扬老师是谁啊，哪能被这种问题难住，从容的回答道：哈哈，应用是会涉及的，不过不是只停止部分功能，而是从系统层腾出空间，比如：如果决策是停止搜寻，就会停止整个搜索集群，腾出计算资源。
E同学继续追问道：那项目需要拆分到很细才行呢，还是通过路由不开放的情况控制呢？
张飞扬继续回答道：好问题，降级经常需要前后端互动，如果搜索功能全部降级，界面需要把搜索框隐藏。
E同学接着又抛出一连串自己早已准备好的问题：这样发布不会影响使用么？容器化能够处理只给某些地区限制多个用户访问系统指定功能么 ？
张飞扬老师不慌不忙回答道：这个不是临时发布的，是在秒杀触发、人工触发而已，但是平时就预埋的，亚马逊的大部分模块都预埋了这个降级功能，作为每个模块开发的基本要求。
H边检索记忆边回答道：我记得有一次双十一的时候，淘宝把评论相关功能给关了，把空出的物理资源投入到了需要的地方。
张飞扬回答道：是的，容器化的好处是帮助完成这些决策的执行。
问题三：当你看完前面几周的课程后，尝试思考：如果要让你满足秒杀抢购，你感觉什么模块更适合进行降级，降级到什么程度合适？
I同学手头上的活刚忙完，就打开了Java架构师课程QQ群，边扫楼边放松（这已经是他从购买这门课程到现在半个月以来新养成的习惯）。正好看到了张老师问的第三个问题，于是回答道：对于秒杀项目来说我认为需要降级的是下单模块 ，力度控制到秒杀的商品没了 ，就可以进行降级处理了。
张飞扬老师原以为抛出第三个问题后，可能就孤家寡人开启尬聊模式了，没想到I同学给出了他的回答，于是他又来了兴致，继续说道：你说的这是一个思路，但是如果这次目的是iphone11抢购，等热卖1小时后卖空，这个时候再降级就有些晚了，还有没有其他思路呢，大家可以继续探讨下。
J同学也刚扫完楼，接着老师的话头回答道：扣减库存应该需要降级吧。
张飞扬老师回答道：如果这个降级，有可能会产生超卖问题。
E同学刚才一连串问了不少多问题，有点累，正休息呢，看到张老师抛出了第三个问题，立马放下手中的水杯，抖擞了下精神，飞快的问道：搜索和退款是不是可以先降级？这个是在前几天看到双十一淘宝京东不能退款想到的。
张飞扬老师很有耐心的回答道：能从生活中学习留心观察，非常赞，你说的搜索和退款可以先降级的，思路其实差不多。我们一般降级业务可以从两个方向去选的。其中一个思路就是和我们这次抢购业务无关的模块。但是你要清楚到底哪些业务模块最没关系呢？其实所有卖家类型的业务是最适合降级的，比如履约，上架、卖家支付（给卖家打款），另外社交类功能也是通常会降级的，比如评论模块等。那第二个思路是降级相关的高流量，用其他方法替代。（高流量业务比如搜索业务）
E同学问的所有问题都得到了张老师的耐心解答，满意的说道：Ok ，面试谈到这块基本都能搭上了。
张飞扬担心还有不明白的同学，于是继续解释道：之前我做过一家电信互联网平台的抢购，就是把这次抢购的产品放入滚动广告条，然后把搜索临时降级了，前一个思路的好处是对用户的影响小。现在因为有了微服务和容器化，前一种思路的降级效果有所下降。微服务后，你的数据库等资源分开了，不存在争抢和互相干扰，容器化编排，通常又会选择自动伸缩，所以向卖家上架之类的业务其实在那个热卖的时间点的负载并不大，所以后台对于下单业务不会造成特别严重的争抢和干扰，伸缩可以基于方式的业务压力监控或者容器内的cpu内存监控来实现。
K同学听的一头雾水，但没中途跳车，勇气可嘉，虽然很多时候都听不懂，但他依然觉得很涨知识 ，感觉每天来群里看看都能学到不少东西。
E同学也再次受到启发，激动的说道：这个广告代替搜索 ，我怎么就没想出来呢， 好点子。
– 其实很多时候高手的几句话就能让你豁然开朗，醍醐灌顶，解开你琢磨了好久都不得解的难题，让你少走好多弯路。所以平时要多和老师同学交流，比纯看视频高效很多，正所谓独学而无友，则孤陋而寡闻。与大家共勉。
我们现在精神食粮吃好啦（也许有不少同学会消化不良），也到饭点啦，该去照顾肚子君啦，我们下次再聊。
·······················
更多精彩内容，欢迎关注课程：《Java架构师成长直通车》
随时随地看视频
