保证一个网站永远100%可用目前几乎难以达到，而网站的可用性至关重要，高可用HA（High Availability）通常指，通过设计减少系统不能提供服务的时间，是分布式系统架构设计中必须考虑的因素之一，身为一个工程师，这方面的相关资料也看过不少，做个总结吧。
如何度量和考察
你的网站或者应用可用性达到了几个9？我经常会听到这样的提问，其中有几个9，就代表了你网站、应用的可用性。比如 QQ 的可用性就是4个9，即99.99%。这就意味着，QQ 系统的年停机时间为8.76个小时。
2个9：99% = 基本可用
3个9：99.9% = 较高可用
4个9：99.99% = 具有自动恢复能力的高可用
5个9：99.999% = 极高可用（理想状态）
那这些个9是如何计算出来的，看下面的公式：
网站不可用时间 = 故障修复时间点 - 故障发现时间点
网站年度可用性指标 =（1 - 网站不可用时间 / 年度总时间）* 100%
如何考核网站可用性？
广泛采用故障分进行计算，它是对网站故障进行分类加权计算故障责任的方法。
具体方法：一般会给每个分类的故障设置一个权重（例如事故级故障权重为100，A类为20等），其计算公式为：故障分 = 故障时间（分钟）* 故障权重。公司对技术团队的考核一般会参考故障分。
高可用架构简单原理
设计目的：保证服务器硬件故障服务依然可用，数据依然保存并能够被访问。
实施手段：数据和服务的失效转移以及冗余备份。
- 服务方面（失效转移）：一旦某个服务器宕机，就将服务切换到其他可用的服务器上。
- 数据方面（冗余备份）：如果某个磁盘损坏，就从备份的磁盘（事先就做好了数据的同步复制）读取数据。
从应用层面保障高可用
负载均衡：进行无状态服务的失效转移。（当某服务器宕机时，负载均衡服务器通过心跳检测机制发现该服务器失去响应，就把它从服务器列表中删除，而将请求发送到集群的其他服务器上，这些服务器完全一样，请求在任何一台服务器中处理都不会影响最终的结果）
应用服务器集群的 Session 管理：进行业务有状态服务的Session管理。Session 管理主要有这几种手段。
Session 复制：早期企业通用手段，应用服务器开启 Web 容器的 Session 复制功能，在集群中的几台服务器之间同步 Session 对象，使得每台服务器上都保存所有用户的 Session 信息，这样任何一台机器宕机都不会导致 Session 数据的丢失，而服务器使用 Session 时，也只需要在本机获取即可。如下示图。
评价：这种方案虽然简单，从本机读取 Session 信息也很快速，但只能使用在集群规模比较小的情况下。当集群规模较大时，集群服务器间需要大量的通信进行 Session 复制，占用服务器和网络的大量资源，系统不堪重负。而且由于所有用户的 Session 信息在每台服务器上都有备份，在大量用户访问的情况下，甚至会出现服务器内存不够 Session 使用的情况。而大型网站的核心应用集群就是数千台服务器，同时在线用户可达千万，因此并不适用这种方案。
Session 绑定：利用负载均衡的源地址 Hash 算法实现，负载均衡服务器总是将来源于同一 IP 的请求分发到同一台服务器上（也可以根据 Cookie 信息将同一个用户的请求总是分发到同一台服务器上，当然这时负载均衡服务器必须工作在 HTTP 协议层上。）这样在整个会话期间，用户所有的请求都在同一台服务器上处理，即 Session 绑定在某台特定服务器上，保证 Session 总能在这台服务器上获取。这种方法也被称作会话粘滞。如下示图。
评价：Session 绑定的方案显然不符合我们对于系统高可用的需求，因为一旦某台服务器宕机，那么该机器上的 Session 也就不复存在了，用户请求切换到其他机器后因为没有 Session 而无法完成业务处理。因此虽然大部分负载均衡服务器都提供源地址负载均衡算法，但很少有网站利用这个算法进行 Session 管理。
利用 Cookie 记录 Session：早期的企业应用系统使用 C/S（客户端/服务器）架构，一种管理 Session 的方式是将 Session 记录在客户端，每次请求服务器的时候，将 Session 放在请求中发送给服务器，服务器处理完请求后再将修改过的 Session 响应给客户端。网站没有客户端，但是可以利用浏览器支持的 Cookie 记录 Session。如下示图。
评价：受 Cookie 大小限制，能记录的信息有限。每次请求响应都需要传输 Cookie ，影响性能。如果用户关闭 Cookie ，访问就会不正常。但由于 Cookie 简单易用，可用性高，支持应用服务器的线性伸缩，而大部分应用需要记录的 Session 信息又比较小。因此事实上，许多网站都或多或少地使用 Cookie 记录 Session。
Session 服务器：一种可用性高、伸缩性好、性能不错，对信息大小又没有限制的服务器集群 Session 管理方案。利用独立部署的 Session 服务器（集群）统一管理 Session ，应用服务器每次读写 Session 时，都访问 Session 服务器。如下示图。
评价：这种解决方案事实上是将应用服务器的状态分离，分为无状态的应用服务器和有状态的 Session 服务器，然后针对这两种服务器的不同特性分别设计其架构。对于有状态的 Session 服务器，一种比较简单的方法是利用分布式缓存、数据库等，在这些产品的基础上进行包装，使其符合 Session 的存储和访问要求。如果业务场景对 Session 管理有比较高的要求，比如利用 Session 服务集成单点登录（SSO）、用户服务等功能，则需要开发专门的 Session 服务管理平台。
从服务层面保障高可用
分级管理：核心应用和服务具有更高的优先级，比如用户及时付款比能否评价商品更重要。
超时设置：设置服务调用的超时时间，一旦超时后，通信框架抛出异常，应用程序则根据服务调度策略选择重试or请求转移到其他服务器上。
异步调用：通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况。
服务降级：网站访问高峰期间，为了保证核心应用的正常运行，需要对服务降级。（降级有两种手段：一是拒绝服务，拒绝较低优先级的应用的调用，减少服务调用并发数，确保核心应用的正常运行；二是关闭功能，关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约系统开销，为核心应用服务让出资源）
幂等性设计：保证服务重复调用和调用一次产生的结果相同。
从数据层面保障高可用
数据备份：又分为冷备份和热备份，冷备份是定期复制，不能保证数据可用性。热备份又分为异步热备和同步热备，异步热备是指多份数据副本的写入操作异步完成，而同步方式则是指多份数据副本的写入操作同时完成。
关系数据库的热备机制就是通常所说的主从同步机制，实践中通常使用读写分离的方法来访问Master和Slave数据库，也就是说写操作只访问Master库，读操作均访问Slave库。如下图。
失效转移：若数据服务器集群中任何一台服务器宕机，那么应用程序针对这台服务器的所有读写操作都要重新路由到其他服务器，保证数据访问不会失败。
从发布、质量、监测层面保障高可用
部署发布：在柔性的发布过程中，每次关闭的服务都是集群中的一小部分，并在发布完成后立即可以访问。
灰度和回滚：发布新功能只让部分服务器生效，且观察几天逐渐切流，如果出现问题只影响部分客户，出现问题快速回滚，或者直接下线灰度的机器。
自动化测试：使用自动测试工具或脚本完成测试。
预发布验证：引入预发布服务器，与正式服务器几乎一致，只是没有配置在负载均衡服务器上，外部用户无法访问。
代码控制：推荐采用Git作为版本控制工具。
监控数据采集：
用户行为日志收集：服务器端的日志收集和客户端的日志收集；目前许多网站逐步开发基于实时计算框架Storm的日志统计与分析工具。
服务器性能监控：收集服务器性能指标，如系统Load、内存占用、磁盘IO等，及时判断，防患于未然。
运行数据报告：采集并报告，汇总后统一显示，应用程序需要在代码中处理运行数据采集的逻辑。
监控管理：
系统报警：配置报警阀值和值守人员联系方式，系统发生报警时，即使工程师在千里之外，也可以被及时通知。
失效转移：监控系统在发现故障时，主动通知应用进行失效转移。
自动优雅降级：为了应付网站访问高峰，主动关闭部分功能，释放部分系统资源，保证核心应用服务的正常运行。（网站柔性架构的理想状态）
高可用建议总结
减少单点：去单点首先要识别整个系统所有主链路的单点，如机房（同城异地双机房），应用服务器，DNS服务器，SFTP服务器，LBS，缓存服务器，数据库，消息服务器，代理服务器和专线等，如系统通过专线调用对方服务，需要考虑同时拉联通和电信的专线，联通或电信的专线还是有一定概率会出现问题的，但是同时出问题的概率会小非常多。优先使用软负载，使用硬负载兜底。
减少依赖：减少DNS依赖，减少远程服务依赖，DNS依赖可以尝试设置本地host，用工具给所有服务器推送最新的域名映射关系，通过本地缓存或近端服务减少RPC调用。
限制循环：避免无限死循环，导致CPU利用率百分百，可以设置for循环的最大循环次数，如最大循环1000次。
控制流量：避免异常流量对应用服务器产生影响，可以对指定服务设置流量限制，如QPS，TPS，QPH（每小时总请求量）和QPD（每天总请求量）。
精准监控：对CPU利用率，load，内存，带宽，系统调用量，应用错误量，PV，UV和业务量进行监控，避免内存泄露和异常代码对系统产生影响，配置监控一定要精准，如平时内存利用率是50%，监控可以配置成60%进行报警，这样可以提前感知内存泄露问题，避免应用无响应。
无状态：服务器不能保存用户状态数据，如在集群环境下不能用static变量保存用户数据，不能长时间把用户文件存放在服务器本地。服务器有状态会难以扩容且出现单点问题。
容量规划：定期对容量进行评估。如大促前进行压测和容量预估，根据需要进行扩容。
功能开关：打开和关闭某些功能，比如消息量过大，系统处理不了，把开关打开后直接丢弃消息不处理。上线新功能增加开关，如果有问题关闭新功能。
设置超时：设置连接超时和读超时设置，不应该太大，如果是内部调用连接超时可以设置成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，如空指针异常，循环依赖等。
自动备份：程序，系统配置和数据定期进行备份。可使用linux命令和shell脚本定时执行备份策略，自动进行本地或异地。出现问题时能快速重新部署。
线上压测：系统的对外服务需要进行压测，知道该服务能承受的QPS和TPS，从而做出相对准确的限流。