前言
不知道你有没有这样的阅历，线上的体系突然来了很大的流量，有可能是黑客的进犯，也有可能是事务量远远大于你的预估，如果你的体系没有做任何的防护办法，这时分体系负载过高，体系资源渐渐耗尽，接口呼应越来越慢，直至不可用，这又导致了调用你接口的上游体系产生资源耗尽的状况，终究导致体系雪崩。想想就知道，这是一个灾难性的后果，那么有什么办法呢？
面对这种突发流量的场景，中心思路便是要优先确保优中心事务和优先确保绝大部分用户。常见的应对手法有四种，降级、熔断、限流和排队，下面我会逐个解说。
1. 降级
降级指体系将某些事务或许接口的功用下降，可所以只提供部分功用，也可所以完全停掉一切功用，优先确保中心功用。
比方淘宝双11零点抢购的时分你会发现产品的退货功用不能够使用了。又比方论坛能够降级为只能看帖子，不能发帖子；也能够降级为只能看帖子和评论，不能发评论；
常见的完成降级的方法有两种：
- 体系后门降级
简略来说，便是体系预留了后门用于降级操作。例如，体系提供一个降级URL，当拜访这个URL时，就相当于履行降级指令，具体的降级指令经过URL的参数传入即可。这种计划有必定的安全隐患，所以也会在URL中加入暗码这类安全办法。
体系后门降级的方法完成成本低，但首要缺陷是如果服务器数量多，需求一台一台去操作，效率比较低，这在毛病处理分秒必争的场景下是比较浪费时间的。
- 独立降级体系
为了处理体系后门降级方法的缺陷，咱们能够将降级操作独立到一个单独的体系中，完成杂乱的权限管理、批量操作等功用。
基本架构如下：
2. 熔断
熔断是指按照必定的规矩，比方1分钟内60%的恳求呼应过错就停掉对外部接口的拜访，防止某些外部接口毛病导致自己的体系处理才能急剧下降或许出毛病。
熔断和降级是两个比较容易混杂的概念，因为单纯从名字上看，好像都有禁止某个功用的意思。但它们的内在是不同的，因为降级的目的是应对体系本身的毛病，而熔断的目的是应对依靠的外部体系毛病的状况。
关于服务熔断的完成，比较干流的有两种计划，Spring Cloud Netflix Hystrix和阿里的Sentinel,咱们公司的项目用的是Sentinel。
- Hystrix是一个用于处理分布式体系的延迟和容错的一个开源库，在分布式体系里，许多依靠不可防止的会调用失败，比方超时、异常等，Hystrix能确保在一个依靠呈现问题的状况下，不会导致全体服务失败，防止级联毛病，以进步分布式体系的稳定性。
- Sentinel 是阿里中间件团队开源的，面向分布式服务架构的轻量级高可用流量控制组件，首要以流量为切入点，从流量控制、熔断降级、体系负载维护等多个维度来协助用户维护服务的稳定性。
3. 限流
每个体系都有服务的上线，所以当流量超过服务极限才能时，体系可能会呈现卡死、崩溃的状况，所以就有了降级和限流。限流其实便是：当高并发或许瞬时高并发时，为了确保体系的稳定性、可用性，体系以牺牲部分恳求为代价或许延迟处理恳求为代价，确保体系全体服务可用。
限流一般都是体系内完成的，常见的限流方法能够分为两类：依据恳求限流和依据资源限流。
- 依据恳求限流
依据恳求限流指从外部拜访的恳求角度考虑限流，常见的方法有两种。
第一种是约束总量，也便是约束某个目标的累积上限，常见的是约束当时体系服务的用户总量，例如：某个直播间约束总用户数上限为100万，超过100万后新的用户无法进入；某个抢购活动产品数量只要100个，约束参加抢购的用户上限为1万个，1万以后的用户直接回绝。
第二种是约束时间量，也便是约束一段时间内某个目标的上限，例如1分钟内只允许10000个用户拜访；每秒恳求峰值最高为10万。
无论是约束总量仍是约束时间量，一起的特色都是完成简略，但在实践中面对的首要问题是比较难以找到适宜的阈值。例如体系设定了1分钟10000个用户，但实践上6000个用户的时分体系就扛不住了；或许到达1分钟10000用户后，其实体系压力还不大，但此时已经开端丢掉用户拜访了。
即便找到了适宜的阈值，依据恳求限流还面对硬件相关的问题。例如一台32核的机器和64核的机器处理才能不同很大，阈值是不同的，可能有的技术人员以为简略依据硬件目标进行数学运算就能够得出来，实践上这样是不可行的，64核的机器比32核的机器，事务处理功能并不是2倍的联系，可能是1.5倍，甚至可能是1.1倍。
为了找到合理的阈值，通常状况下能够选用功能压测来确认阈值，但功能压测也存在掩盖场景有限的问题，可能呈现某个功能压测没有掩盖的功用导致体系压力很大；另外一种方法是逐步优化：先设定一个阈值然后上线调查运行状况，发现不合理就调整阈值。
依据上述的分析，依据阈值来约束拜访量的方法更多的适应于事务功用比较简略的体系，例如负载均衡体系、网关体系、抢购体系等。
- 依据资源限流
依据恳求限流是从体系外部考虑的，而依据资源限流是从体系内部考虑的，也便是找到体系内部影响功能的要害资源，对其使用上限进行约束。常见的内部资源包括连接数、文件句柄、线程数和恳求行列等。
例如，选用Netty来完成服务器，每个进来的恳求都先放入一个行列，事务线程再从行列读取恳求进行处理，行列长度最大值为10000，行列满了就回绝后边的恳求；也能够依据CPU的负载或许占用率进行限流，当CPU的占用率超过80%的时分就开端回绝新的恳求。
依据资源限流比较依据恳求限流能够更加有效地反映当时体系的压力，但实践设计时也面对两个首要的难点：怎么确认要害资源，以及怎么确认要害资源的阈值。
通常状况下，这也是一个逐步骤优的进程：设计的时分先依据推断挑选某个要害资源和阈值，然后测验验证，再上线调查，如果发现不合理，再进行优化。
4. 排队
排队这种方法，想必大家在熟悉不过了。大家在12306买火车票的时分，是不是会告诉你在排队中，等候一段时间后才会锁定车票，付款。年底时，全中国那么多人买票，12306便是经过排队机制来搞定的。可是也有缺陷，那便是用户体验没那么好。
由于排队需求临时缓存大量的事务恳求，单个体系内部无法缓存这么多数据，一般状况下，排队需求用独立的体系去完成，例如使用Kafka这类消息行列来缓存用户恳求。
- 排队模块
担任接收用户的抢购恳求，将恳求以先入先出的方法保存下来。每一个参加秒杀活动的产品保存一个行列，行列的大小能够依据参加秒杀的产品数量（或加点余量）自行界说。
- 调度模块
担任排队模块到服务模块的动态调度，不断查看服务模块，一旦处理才能有闲暇，就从排队行列头上把用户拜访恳求调入服务模块，并担任向服务模块分发恳求。这里调度模块扮演一个中介的人物，但不仅仅传递恳求而已，它还担负着调理体系处理才能的重任。咱们能够依据服务模块的实践处理才能，动态调理向排队体系拉取恳求的速度。
- 服务模块
担任调用真实事务来处理服务，并回来处理结果，调用排队模块的接口回写事务处理结果。
总结
最终咱们经过一个表格在总结以下上面4种确保服务高可用的手法。
https://freegeektime.com/100006601/10312/
欢迎重视个人公众号【JAVA旭阳】沟通沟通
