其实系统考虑能支持高并发的同时，还需要权衡系统的高可用，并不是一味的接收请求过来，万一服务器雪崩，内存撑爆，数据库卡死等会带来全方面的影响。所以以下有一些方法来促进系统的高可用。
高可用同样存在三大杀手锏，分别是限流、降级和隔离。高可用最直观的目的就是怎么防止系统雪崩！！！
限流是第一道门，限流模式也是预防模式，这种模式不能解决服务依赖的问题，只能解决系统整体资源分配问题，因为没有被限流的请求依然有可能造成雪崩效应。
隔离是第二道门，隔离有好多种隔离，现在以线程池隔离为例子，首先，当大多数人在使用Tomcat时，多个HTTP服务会共享一个线程池，假设其中一个HTTP服务访问的数据库响应非常慢，这将造成服务响应时间延迟增加，大多数线程阻塞等待数据响应返回，导致整个Tomcat线程池都被该服务占用，甚至拖垮整个Tomcat。因此，如果我们能把不同HTTP服务隔离到不同的线程池，则某个HTTP服务的线程池满了也不会对其他服务造成灾难性故障。
降级（包含熔断）是最后一道大坝，我们的系统中，如果某个目标服务调用慢或者有大量超时，此时，熔断该服务的调用，，对于后续调用请求，不在继续调用目标服务，调用getFallback方法进行降级，直接返回，快速释放资源。
我的理解：线程池隔离是多个链路之间互不影响，达到整体高可用，熔断则是对一条链路下的某个节点做降级，从而不影响该条链路的执行，最后达到整体高可用，这两点需要结合使用，因为限流现在一般都在waf层和NG上下功夫，所以服务端应用层能做的高可用方案大多要在隔离和降级这两点上下功夫，正好Hystrix既能做线程池隔离，又能做熔断，是首选的技术栈。
限流
限流的目的是防止恶意请求流量、恶意攻击，或者防止流量超过系统峰值。一般可分为waf层---Nginx层---应用层---线程池
1、waf（Web Application FireWall）拦截恶意、非正常流量 （黄牛党）
2、Nginx的limit模块限制瞬时并发数、限制时间窗口的平均速率
3、恶意Ip直接使用Nginx deny进行屏蔽
4、最大原则限制流量穿透到后端薄弱的应用层，如果一旦穿透，应用层也会有一些办法，比如电商的秒杀系统，
可以采用令牌桶算法（Guava RateLimiter）、漏桶算法来做限流
降级
1.通过配置中心切换开关，比如商城支付分两套，万一Native支付不稳定，可以直接开关切成H5支付
2.业务代码逻辑判断，当推荐商品使用算法团队提供的算法推荐，当算法推荐接口不稳定时，采用读取预备的托底数据做展示
3.开关前置化，如果架构是Nginx---Tomcat，将开关前置到Nginx接入层，请求流量回源后端应用或切一小部分流量进来
4.业务降级，当高并发流量来袭，电商系统大促时优先保证用户能下单、能支付的核心要求，保证数据最终一致性即可。把一些同步调用切成异步调用，优先处理高优先级数据。比如下发积分、下发优惠等接口
5.业务降级，当高并发流量来袭，电商系统大促时优先保证用户能下单、能支付的核心要求，对下单使用优惠、使用积分等前置优惠的接口可适当做熔断处理
隔离
隔离是指将系统或资源分割开，系统隔离是为了在系统发生故障时，能限定传播范围和影响范围，即发生故障后不会出现滚雪球效应，从而保证只有出问题的服务不可用，其他服务还是可用的。
线程隔离、进程隔离（dubbo服务隔离）、集群隔离、机房隔离、读写隔离(Redis主从)、动静隔离（静态资源CDN）、爬虫隔离、Hystrix实现隔离
负载均衡和反向代理
DNS+LVS/F5+Nginx+Tomcat
超时处理
超时策略：常见的策略有重试（几秒后重试、尝试其他分组服务、尝试其他机房服务、指数退避算法重试）、托底（返回历史数据/静态数据/缓存数据）、等待页或错误页
超时重试必然导致请求响应时间增加，最坏情况下的响应时间=重试次数×单次超时时间，这很可能严重影响用户体验，导致用户不断刷新页面来重复请求，最后导致服务接收的请求太多而挂掉，因此除了控制单次超时时间，也要控制好用户能忍受的最长超时时间。
超时时间设置：超时时间太短会导致服务调用成功率降低，
超时时间太长有可能会造成服务端线程池会有排队积压现象，
另外前一个请求因为网络等各方面原因导致长时间未响应，那后续的正常请求也会因为前面的状态处理错误，
比如商品详情页的库存状态服务，可以设置较短的超时时间，当超时时降级，直接返回有货，
而结算页服务就需要设置稍微长一些的超时时间保证确实有货。很有道理啊！！！
可回滚
版本化的目的是实现可审计可追溯，并且可回滚。当程序或数据出错时，如果有版本化机制，那么就可以通过回滚恢复到最近一个正确的版本，比如事务回滚、代码库回滚、部署版本回滚、数据版本回滚、静态资源版本回滚等。通过回滚机制可保证系统某些场景下的高可用。
压测和预案
对现有系统进行梳理，发现系统的瓶颈和问题，然后进行系统调优来提升系统的健壮性和处理能力。一般可通过系统压测来发现系统瓶颈，然后进行系统优化和容灾（系统参数调优、同城双活、异地双活）
压测之前要有
压测方案〔如压测接口、并发量、压测策略（突发、逐步加压、并发量）、
压测指标（机器负载、QPS/TPS、响应时间）〕，
之后要产出压测报告〔压测方案、机器负载、QPS/TPS、响应时间（平均、最小、最大）、成功率、相关参数（JVM
参数、压缩参数）等〕，最后根据压测报告分析的结果进行系统优化和容灾。
读压测是压测系统的读流量，比如，压测商品价格服务。写压测是压测系统的写流量，比如下单。只进行读或写压测有时是不能发现系统瓶颈的，因为有时读和写是会相互影响的，因此，这种情况下要进行混合压测。另外，在实际压测时应该进行全链路压测，因为可能存在一个非核心系统服务调用问题造成整个交易链路出现问题，或者链路中的各个系统存在竞争资源的情况，因此为了保证压测的真实性，应该进行全链路压测，通过全链路压测来发现问题。
拿到压测报告后，接下来会分析报告，然后进行一些有针对性的优化，
如硬件升级---系统扩容---参数调优（发现不合理的参数配置，如超时时间、降级策略、缓存时间等）--代码优化、代码走查（如代码同步改异步、慢查询排查）--架构优化（如加缓存、读写分离、历史数据归档）等。其实我们能做的主要是参数调优、代码走查和架构优化。
总结：
通过负载均衡和反向代理实现分流，通过限流保护服务免受雪崩之灾，通过降级实现部分可用、有损服务，通过隔离实现故障隔离，通过设置合理的超时与重试机制避免请求堆积造成雪崩，通过回滚机制快速修复错误版本。上述原则用来保护系统，往往能实现系统高可用。
