为了保证后端服务的稳定性，无论是Java服务还是Node服务，常见的处理方式大抵上就是 3 种：降级、熔断、限流。
一, 降级
1）后端服务降级
后端降级也就是服务降级。当我们的服务器压力剧增时，为了保证核心功能的可用性 ，而选择性的降低一些功能的可用性，或者直接关闭该功能。这就是典型的丢车保帅了。
就比如贴吧类型的网站，当服务器吃不消的时候，可以选择把发帖功能关闭，注册功能关闭，改密码，改头像这些都关了，为了确保登录和浏览帖子这种核心的功能。
一般而言都会建立一个独立的降级系统，可以灵活且批量的配置服务器的降级功能。当然也有用代码自动降级的，例如接口超时降级、失败重试多次降级等。具体失败几次，超时设置多久，由你们的业务等其他因素决定。开个小会，定个值，扔线上去看看情况。根据情况再调优。
2）前端访问降级
在SSR模式下，当某一时段访问量剧增时，可通过CSR降级来减轻node服务压力。
比如拼多多的商城，百亿补贴、多多买菜等服务，当遇到节假日 or 活动高峰期时，就会启动
CSR降级预警方案。举例：正常访问百亿补贴页面时，是通过SSR直出首屏信息的。但是，当QPS超过了2000时，就会启动CSR降级方案，在客户端完成百亿补贴的页面渲染，服务端只需出一份template式的HTML文件即可，再借助Nginx服务强大的反向代理 & 静态资源缓存的能力，从而大大减轻了Node服务压力。
二, 熔断
降级一般而言指的是我们自身的系统出现了故障而降级。而熔断一般是指依赖的外部接口出现故障的情况，这时候就要断绝和外部接口的关系。
例如你的
A服务里面的一个功能依赖B服务，这时候B服务出问题了，返回的很慢。这种情况可能会因为这么一个功能而拖慢了A服务里面的所有功能，因此我们这时候就需要 熔断！即当发现A要调用这B时，就直接返回错误(或者返回其他默认值啊啥的)，总之就不去请求B了。我这还只是举了两个服务的调用，有些那真的是一环扣一环，出问题不熔断，那真的是会雪崩。
当然也有人认为：熔断不就是降级的一种的？我觉得你非要说熔断也属于一种降级我也没法反驳，但是它们本质上的突出点和想表达的意思还是有一些不同的。
那什么时候熔断合适呢？也就是到达哪个阈值进行熔断，5分钟内50%的请求都超过1秒？还是啥？参考降级。
新冠下的航班熔断：
有关熔断的概念，在这两年来的新冠疫情下，我们也经常能听到：某某航班因疫情影响而实施了熔断机制，本质上是一个意思。
举例：因疫情原因，上海浦东机场对美国夏威夷航空公司方向的航班启动熔断机制（原本A服务依赖于B服务），那就说明夏威夷航空公司那边的疫情很严重（现在B服务出问题了），如果这些航班还正常运行的话，会对上海的疫情造成较大冲击。所以，基于安全因素考虑，我们就启动熔断措施，保障上海这边的安全（直接掐掉B服务的返回）。
三, 限流
上面说的两个算是请求过来我们都受理了，这个限流就更狠了，直接跟请求说“对不起再见”！也就是系统规定了多少承受能力，只允许这么些请求能过来，其他的请求就说再见了。
一般限制的指标有：请求总量 或 某段时间内请求总量。
请求总量： 比如秒杀的，秒杀100份产品，我就放5000名进来，超过的直接拒绝请求了。
某段时间内请求总量： 比如规定了每秒请求的峰值是10000，这一秒内多的请求直接拒绝了。咱们下一秒再见。
限流可通过网关层面来处理。
