高可用性、负载均衡、反向代理、隔离术、限流、降级、超时与重试、回滚、压力测试、应急预案

高可用性（HA）系统是目前企业防止核心计算机系统因故障停机的最有效手段。

高可用性（HA）的功能

     1、软件故障监测与排除

     2、备份和数据保护

     3、管理站能够监视各站点的运行情况，能随时或定时报告系统运行状况，故障能及时报告和告警，并有必要的控制手段

     4、实现错误隔离以及主、备份服务器间的服务切换

HA的工作方式：HA有主从方式和双工方式两种工作模式

      高可用性方案则利用更少的冗余部件同时由软件检测故障，一旦故障发生立即隔离损坏部件，通过提供故障恢复实现最大化系统和应用的可用性。

      容错技术随着处理器速度的加快和价格的下跌而越来越多地转移到软件中。未来容错技术将完全在软件环境下完成，那时它和高可用性技术之间的差别也就随之消失了。

负载均衡 建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

软件负载均衡解决方案是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的优点是基于特定环境，配置简单，使用灵活，成本低廉，可以满足一般的负载均衡需求。

       软件解决方案缺点也较多，因为每台服务器上安装额外的软件运行会消耗系统不定量的资源，越是功能强大的模块，消耗得越多，所以当连接请求特别大的时候，软件本身会成为服务器工作成败的一个关键；软件可扩展性并不是很好，受到操作系统的限制；由于操作系统本身的Bug，往往会引起安全问题。

      硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备，这种设备通常称之为负载均衡器，由于专门的设备完成专门的任务，独立于操作系统，整体性能得到大量提高，加上多样化的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。

反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。

代理服务器有三种：

      1． 标准的代理缓冲服务器

一个标准的代理缓冲服务被用于缓存静态的网页（例如：html文件和图片文件等）到本地网络上的一台主机上（即代理服务器）。

      2． 透明代理缓冲服务器

透明代理缓冲服务和标准代理服务器的功能完全相同。但是，代理操作对客户端的浏览器是透明的（即不需指明代理服务器的IP和端口）。

      3． 反向代理缓冲服务器

反向代理是和前两种代理完全不同的一种代理服务。使用它可以降低原始WEB服务器的负载。反向代理服务器承担了对原始WEB服务器的静态页面的请求，防止原始服务器过载。

安全反向代理用途：

     可以提供从防火墙外部代理服务器到防火墙内部安全内容服务器的加密连接。

     可以允许客户机安全地连接到代理服务器，从而有利于安全地传输信息。

     安全反向代理会造成各安全连接加密数据所涉及的系统开销而变慢。 SSL 提供了高速缓存机制，连接双方重复使用先前协商的安全参数，大大降低后续连接的系统开销。

线程隔离:

         线程隔离主要是指线程池隔离，在实际使用时，我们会把请求分类，然后交给不同的线程池处理。当一种业务的请求处理发生问题时，不会将故障扩散到其他线程池，从而保证其他服务可用。

进程隔离

        由于传统的系统所有功能都集中在一个系统中，为了避免系统其中一个模块功能出现问题导致整个系统无法使用的情况发生，将其该系统拆分成多子系统实现物理隔离，故通过进程隔离使得某一个子系统出现问题时不影响到其他子系统。

集群隔离

       随着调用方的增多，当秒杀（并发量特别大功能）类似的服务被刷新会影响到其他服务的稳定性时，应该考虑为秒杀（并发量特别大功能）类似的服务提供单独的服务集群，即分服务分组，这样当某一个分组出现问题时，不会影响到其他分组，从而实现了故障隔离愿景。

机房隔离

       随着对系统可用性的要求，会进行多机房部署，每一个机房的服务都有自己的服务分组，本机房的服务应该只调用本机房的服务，不进行跨机房调用。其中，一个机房服务发生问题时，可以通过DNS/负载均衡将请求全部切到另一个机房，或者考虑服务能自动重试其他机房的服务，从而提升系统可用性。

读写隔离

        为了提高数据访问，一般采用redis主从模式将读和写进群分离，在正常情况下，当主redis集群出现问题时，从redis集群还是可以用的，从而不影响用户的访问。

动静隔离

       例如当用户访问如结算页时，如果JS/CSS等静态资源也在结算页系统中时，很可能因为访问量太大导致带宽被打满导致出现不可用。

      为了不影响结算等用户操作的功能，将其JS/CSS等静态资源静态化与用户操作功能分开部署。

资源隔离

   最常见的资源如磁盘、CPU、网络；对于宝贵的资源都会存在竞争问题。

   我们可以使用JIMDB数据同步时要dump数据，SSD盘容量用了50%以上，dump到同一块磁盘时遇到了容量不足的问题，我们通过单独挂一块SAS盘来专门同步数据。还有如使用Docker容器时，有的容器写磁盘非常频繁，因此要考虑为不同的容器挂载不同的磁盘。

在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。缓存的目的是提升系统访问速度和增大系统能处理的容量，可谓是抗高并发流量的银弹；而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉，待高峰或者问题解决后再打开；而有些场景并不能用缓存和降级来解决，比如稀缺资源（秒杀、抢购）、写服务（如评论、下单）、频繁的复杂查询（评论的最后几页），因此需有一种手段来限制这些场景的并发/请求量，即限流。

      限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务（定向到错误页或告知资源没有了）、排队或等待（比如秒杀、评论、下单）、降级（返回兜底数据或默认数据，如商品详情页库存默认有货）。

       一般开发高并发系统常见的限流有：限制总并发数（比如数据库连接池、线程池）、限制瞬时并发数（如nginx的limit_conn模块，用来限制瞬时并发连接数）、限制时间窗口内的平均速率（如Guava的RateLimiter、nginx的limit_req模块，限制每秒的平均速率）；其他还有如限制远程接口调用速率、限制MQ的消费速率。另外还可以根据网络连接数、网络流量、CPU或内存负载等来限流。

     降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

    降级预案

    在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

    一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；

    警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；

    错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系   统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；

     严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

     降级按照是否自动化可分为：自动开关降级和人工开关降级。

     降级按照功能可分为：读服务降级、写服务降级。

     降级按照处于的系统层次可分为：多级降级。

     降级的功能点主要从服务端链路考虑，即根据用户访问的服务调用链路来梳理哪里需要降级：

     页面降级、页面片段降级、页面异步请求降级、服务功能降级、读降级、写降级

     自动开关降级：超时降级、统计失败次数降级、故障降级、限流降级

     人工开关降级：读服务降级、写服务降级

在实际开发过程中，我们见过太多故障时因为没有设置超时或者设置得不对而造成的，而这些故障都是因为没有意识到超时设置的重要性而造成的。如果应用不设置超时，则可能会导致请求响应慢，慢请求积累导致连锁反应，甚至造成应用雪塌。而有些中间件或者框架在超时后进行重试（例如dubbo默认重试两次），读服务天然适合重试，但写服务大多不能重试（如写订单、支付等），重试次数太多会导致多倍请求流量。

     例如模拟了Ddos攻击（分布式拒绝服务(DDoS:Distributed Denial of Service)攻击指借助于客户/服务器技术，将多个计算机联合起来作为攻击平台，对一个或多个目标发动DDoS，通常，攻击者使用一个偷窃帐号将DDoS主控程序安装在一个计算机上，在一个设定的时间主控程序将与大量代理程序通讯，代理程序已经被安装在网络上的许多计算机上。代理程序收到指令时就发动攻击。利用客户/服务器技术，主控程序能在几秒钟内激活成百上千次代理程序的运行。），后果可能是灾难，因此，务必设置合理的重试机制，并且应该和熔断、快速失败机制配合。所以在进行代码Review时，一定记得Review超时与重试机制。

事务回滚

        在执行数据库SQL时，如果我们检测到哦事务提交冲突，那么事务中所有执行的SQL要进行回滚，目的是防止数据库出现数据不一致。

代码库回滚

        在开发项目时一定要将代码维护到代码仓库，从而进行版本管理。有了版本控制系统后可记录代码的历史版本，在出现问题时候可以方便回滚。

部署版本回滚

        代码测试完成后，接下来要进行系统部署，在部署时要考虑当代码逻辑出现错误后如何快速恢复

数据版本回滚

        在设计消息队列时，重要业务会对消息队列进行副本处理，以便万一业务逻辑出现问题能进行历史数据回滚，从而修复问题。

静态资源版本回滚

        静态化页面资源后，每次内容变更时我们都会生成一个全量新版本放到项目的文件目录中，从而保证版本可追溯，出现问题时能及时回滚。

线下压力测试

        通过如Jmeter，Apac，he ab 压力测试系统的某一个接口等（如登录、查询订单）或者某一个组件（例如数据库连接池），然后进行调优（如调优JVM参数，优化代码等），实现单个接口或者组件的性能最优。

线上压力测试

        线上压力测试份方式非常多，按读分为读压、写压测和混合压测，按照数据仿真度分为仿真压力测试和引流压力测试，按照给用户提供服务分为隔离集群压力测试和线上集群压力测试。

系统优化和容灾

        拿到全面的压力测试报告后，接下来就是分析报告，然后进行一些有这对性的优化，如硬件升级、系统扩容、参数调优、代码优化（代码同步改异步）、架构优化（如加缓存、读写分离、历史数据归档）等。在扩容时也需要考虑容灾，比如分组部署、跨机房部署。容灾是通过部署多组（单机房或多机房）相同系统，当其中一组出现问题时，可以切换到另一个分组，保证系统可用

在系统压力测试之后发现一些系统瓶颈，在系统优化之后会提升系统吐吞量并降低响应时间，容灾之后的系统可用性得以保障，但还是会存在一些风险，如网络抖动、某台机器负载过高、某个服务变慢、数据库Load值过高，为了防止因为这些问题而出现系统雪崩，需要针对这些情况制定应急预案，从而在出现突发情况时，有响应的措施来解决掉这些问题。

     应急预案可按照如下几步进行：首先进行系统分级，然后进行全链路分析、配置监控，最后制定应急预案。