减少单点

去单点首先要识别整个系统所有主链路的单点，如机房（同城异地双机房），应用服务器，DNS服务器，SFTP服务器，LBS，缓存服务器，数据库，消息服务器，代理服务器和专线等，如系统通过专线调用对方服务，需要考虑同时拉联通和电信的专线，联通或电信的专线还是有一定概率会出现问题的，但是同时出问题的概率会小非常多。优先使用软负载，使用硬负载兜底。

减少依赖

减少DNS依赖，减少远程服务依赖，DNS依赖可以尝试设置本地host，用工具给所有服务器推送最新的域名映射关系，通过本地缓存或近端服务减少RPC调用。

限制循环

避免无限死循环，导致CPU利用率百分百，可以设置for循环的最大循环次数，如最大循环1000次。

控制流量

避免异常流量对应用服务器产生影响，可以对指定服务设置流量限制，如QPS，TPS，QPH（每小时总请求量）和QPD（每天总请求量）,可主要参考漏桶算法和令牌桶算法。

精准监控

对CPU利用率，load，内存，带宽，系统调用量，应用错误量，PV，UV和业务量进行监控，避免内存泄露和异常代码对系统产生影响，配置监控一定要精准，如平时内存利用率是50%，监控可以配置成60%进行报警，这样可以提前感知内存泄露问题，避免应用无响应。

无状态

服务器不能保存用户状态数据，如在集群环境下不能用static变量保存用户数据，不能长时间把用户文件存放在服务器本地。服务器有状态会难以扩容，且出现单点问题。

容量规划

定期对容量进行评估。如大促前进行压测和容量预估，根据需要进行扩容。

服务补偿

分布式架构中第三方服务出现异常或网络抖动影响，记录失败请求，通过定时任务或延迟队列按一定周期对失败请求进行重复幂等通知进行补偿，具体可参考支付宝支付完成通知实现方案。

幂等设计

为保证服务可重试，可补偿，需要API尽量支持幂等，脚本支持可重复执行，服务支持平滑重启。

功能开关

打开和关闭某些功能，比如消息量过大，系统处理不了，把开关打开后直接丢弃消息不处理。上线新功能增加开关，如果有问题关闭新功能，功能开关可通过配置中心实现，可以参考开源项目confd或自己通过etcd,zk等实现。

设置超时

设置连接超时和读超时设置，不应该太大，如果是内部调用连接超时可以设置成1秒，读超时3秒，外部系统调用连接超时可以设置成3秒，读超时设置成20秒。

重试策略

当调用外部服务异常时可以设置重试策略，每次重试时间递增，但是需要设置最大重试次数和重试开关，避免对下游系统产生影响。

隔离

应用隔离，模块隔离，机房隔离和线程池隔离。可以按照优先级，不变和变几个维度来隔离应用和模块，如抽象和不变的代码放在一个模块，这个模块的代码几乎不会修改，可用性高，经常变的业务逻辑放在一个模块里，这样就算有问题，也只会影响到某一个业务。不同的业务使用不同的线程池，避免低优先级任务阻塞高优先级，或高优先级任务过多时影响低优先级任务永远不会执行。

异步调用

同步调用改成异步调用，解决远程调用故障或调用超时对系统的影响。

热点缓存

对热点数据进行缓存，降低RPC调用。如B系统提供名单服务，B系统可以提供一个client SDK提供近端缓存服务，定期去服务器端取数据，减少RPC调用。

缓存容灾

当数据库不可用时可以使用缓存的数据。并设置分级缓存，如优先读本地缓存，其次读分布式缓存。

多级缓存

优先读本地缓存，其次读分布式缓存。通过推模式更新本地缓存。

系统分级

对系统进行分级，如ABC三个等级，高级别系统不依赖于低级别系统，并且高级别系统比底级别系统高可用率要高。

服务拆分

对业务按照功能模块进行服务拆分，可有效提高服务的可扩展性，可维护性，解除服务与服务之间的耦合。

服务降级

如果系统出现响应缓慢等状况，可以关闭部分功能，从而释放系统资源，保证核心服务的正常运行。需要识别哪些服务可以降级，比如突然有大量消息流入，导致服务不可用，我们会把消息直接丢弃掉。或通过设置流控，拒绝为低级别系统提供服务。

流量蓄洪

当流量陡增时，可以将请求进行蓄洪，如把请求保存在数据库中，再按照指定的QPS进行泄洪，有效的保护下游系统，也保证了服务的可用性。当调用对方系统，对方系统响应缓慢或无响应时，可采取自动蓄洪。

服务权重

在集群环境中，可自动识别高性能服务，拒绝调用性能低的服务。如在集群环境中，对调用超时的服务器进行权重降低，优先调用权重高的服务器。

依赖简化

减少系统之间的依赖，比如使用消息驱动，A和B系统通过消息服务器传递数据，A和B系统使用数据库进行读写分离，A系统负责往数据库中写数据，B系统负责读数据，因为数据存放在数据库中，当A不可用时，短时间内不影响B系统提供服务。

弹性扩容

根据资源的使用率自动或手动进行扩容。如带宽不够用时，快速增加带宽。

灰度和回滚

发布新功能只让部分服务器生效，且观察几天逐渐切流，如果出现问题只影响部分客户。出现问题快速回滚，或者直接下线灰度的机器。

减少远程调用

优先调用本地JVM内服务，其次是同机房服务，然后是同城服务，最后是跨城服务。如A调用B，B调用互联网的C系统获取数据，B系统可以把数据缓存起来，并设置数据的保鲜度，减少B对C的依赖。配置中心把注册服务的地址推送到调用服务的系统本地。参数中心把参数配置信息推送到系统的本地内存，而不是让系统去远程服务器获取参数信息。

熔断机制

增加熔断机制，当监控出线上数据出现大幅跌涨时，及时中断，避免对业务产生更大影响。如我们做指标计算时，指标可以计算慢，但是不能算错，如果发现某个用户的指标环比或同比增长一倍或跌零，会考虑保存所有消息，并中止该用户的指标计算。

运行时加载模块

我们会把经常变的业务代码变成一个个业务模块，使用Java的ClassLoader在运行时动态加载和卸载模块，当某个模块有问题时候，可以快速修复。

代码扫描

使用IDEA代码分析等工具进行代码扫描，识别出程序中的BUG，如空指针异常，循环依赖等。

应用举例

• 接口级故障：系统没有宕机、网络没有中断，但是业务却出现了问题：业务响应慢、大量访问超时、大量访问异常。
  • 本质：系统负载过高，导致无法快速处理业务。比如，如果系统中存在慢查询，当负载过高时，慢查询会将数据库资源耗尽，导致读写操作超时，业务读写很容易出现超时现象。即使没有慢查询当负载过高时也会出现超时情况。
  • 产生原因的内部条件：程序bug导致死循环、存在慢查询、程序逻辑不对导致耗尽内存
  • 外部条件：黑客攻击、促销、第三方系统响应缓慢

解决思路

• 解决接口级故障的核心思想是优先保障核心业务和优先保障绝大部分用户。比如登录功能很重要，当访问量过高时，停掉注册功能，为登录腾出资源。

解决策略

降级

系统将某些不重要的业务或接口的功能降低，可以只提供部分功能，也可以完全停到所有所有不重要的功能。降级的思想是丢车保帅。

• 常见降级方式

  • 系统后门降级：系统预留后门用于降级，比如提供一个降级URL，访问URL时就执行降级指令。缺点：如果服务器数量多，需要一台一台去操作，效率低。

  • 独立系统降级：将降级操作独立到一个单独的系统中，可以实现复杂的权限管理、批量操作等功能。

    image

熔断

降级是应对系统自身的故障，而熔断的目的是应对外部系统的故障。比如A服务的X功能依赖B服务的某个接口，当B服务接口响应很慢时，A服务X功能的响应也会被拖慢，进一步导致了A服务的线程都卡在了X功能上，A服务的其它功能也会卡主或拖慢。此时就需要熔断机制，即A服务不在请求B这个接口，A服务内部发现B接口就直接返回错误，从而避免整个A服务被拖慢。

• 实现思路：需要系统有一个统一的API调用层，由API来进行采样或者统计。

限流

限流：只允许系统能够承受的访问量进来，超出的会被丢弃。

• 降级从系统功能优先级角度考虑如何应对故障，而限流则从用户访问压力的角度来考虑如何应对故障。

• 常见限流方式

  • 基于请求限流：指从外部请求的角度考虑限流。常见的方式有：

    • 限制总量：限制某个指标的累积上限。比如直播间的用户总数上限为100万，超过后用户无法进入。抢购商品数量为100，限制抢购用户上限为1万个，超过或直接拒绝。
    • 限制时间量：限制一段时间内某个指标的上限。例如：一分钟内只允许1000个用户访问。每秒请求峰值为10万。
    • 都需要找到合适的阀值：需要通过性能压测来确定阀值或者逐步优化。

  • 基于资源限流：指从系统内部考虑，找到影响性能的关键资源，对其使用上限限制。常见的内部资源有：连接数、文件句柄、线程数、请求队列、CPU利用率等。例如，使用Netty实现服务器，每个请求先放到请求队列中，业务线程从请求队列中获取任务进行处理，请求队列大小为1000，那么超过该值则直接拒绝。

排队

排队方式来应对接口级故障的方式是：让用户等待一段时间，而不是像限流方式直接拒绝用户。从体验上来讲，虽然用户没有很快得到拒绝响应，但是如果等待时间过长，体验也不是很好。(但是对于一些请求，等待比直接拒绝要好，比如支付请求，排队总比直接拒绝好，因为直接拒绝用户就有可能不买了）

• 实现方式：排队需要保存未被处理的请求，所以排队需要缓存大量数据，一般单个系统无法缓存这么多数据，所有需要单独的排队系统去实现。例如使用Kafka、RocketMQ等消息队列来缓存用户的请求。

image

实现思路：蓝色区域是排队系统

【排队模块】
负责将用户的请求以FIFO的方式存入队列中，不同商品的秒杀请求放在不同的队列中，队列大小可以根据秒杀商品数量自行定义。
【调度模块】
负责动态调度排队模块中的请求到服务模块中。动态性体现在：会根据服务模块的当前处理能力控制拉取请求速度，如果服务模块的处理能力有空闲就提升拉取请求速度，否则降慢速度。
【服务模块】
负责调用真正的业务来处理请求，并获取返回结果，再调用排队模块的接口写回业务处理结果。

案例

如果你来设计一个整点限量秒杀系统，包括登录、抢购、支付（依赖支付宝）等核心功能，你会如何设计接口级的故障应对手段？

• 思路：
  丢车保帅：在秒杀时，通过服务降级把注册、修改个人信息等非核心功能关闭掉。（是否为核心此时的判断标准为：秒杀时间段这些功能影响人数少）
  熔断：支付依赖第三方服务，要设置熔断策略，熔断后要给出友好提示，比如10分钟后再来支付。
  排队+限流：抢购下单接口采用排队+限流方式，如抢购1000件商品，则设置2000大小的队列，请求超过2000后直接拒绝掉，前2000请求加入队列中，然后可以开启多线程对队列进行处理。

作者：zlcook
链接：https://www.jianshu.com/p/33f394c0ee2d
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。