万无一失：网站的高可用架构
1.网站可用性的度量
网站的页面能完整呈现在最终用户面前，需要经过很多个环节，任何一个环节出了 问题，都可能导致网站页面不可访问。DNS会被劫持、CDN服务可能会挂掉、网站服务 器可能会宕机、网络交换机可能会失效、硬盘会损坏、网卡会松掉、甚至机房会停电、 空调会失灵、程序会有Bug、黑客会攻击、促销会引来大量访问、第三方合作伙伴的服务 会不可用……要保证一个网站永远完全可用几乎是一件不可能完成的使命。
1.1 网站可用性度量
网站不可用也被称作网站故障，业界通常用多少个9来衡量网站的可用性，如QQ的 可用性是4个9，即QQ服务99.99%可用，这意味着QQ服务要保证其在所有运行时间中， 只有0.01 %的时间不可用，也就是一年中大约最多53分钟不可用。
网站不可用时间（故障时间）=故障修复时间点-故障发现（报告）时间点
网站年度可用性指标=(1-网站不可用时间/年度总时间）xl00%
对于大多数网站而目，2个9是基本可用，网站年度不可用时间小于88小时；3个9 是较高可用，网站年度不可用时间小于9小时；4个9是具有自动恢复能力的高可用，网 站年度不可用时间小于53分钟；5个9是极高可用性，网站年度不可用时间小于5分钟。
2.高可用的网站架构
硬件故障是常态，网站的高可用架构设计的主要目的就是保证服务器硬件故障 时服务依然可用、数据依然保存并能够被访问。 实现上述高可用架构的主要手段是数据和服务的冗余备份及失效转移，一旦某些服务器宕机，就将服务切换到其他可用的服务器上，如果磁盘损坏，则从备份的磁盘读取 数据。
网站典型的分层模型是三层，即应用层、服务层、数据层；各层之间具有相对独立性， 应用层主要负责具体业务逻辑处理；服务层负责提供可复用的服务；数据层负责数据的 存储与访问。中小型网站在具体部署时，通常将应用层和服务层部署在一起，而数据层 则另外部署，如图5.3所示（事实上，这也是网站架构演化的第一步）。
在复杂的大型网站架构中，划分的粒度会更小、更详细，结构更加复杂，服务器规 模更加庞大，但通常还是能够把这些服务器划分到这三层中。如图5.4所示。
不同的业务产品会部署在不同的服务器集群上，如某网站的文库、贴吧、百科等属 于不同的产品，部署在各自独立的服务器集群上，互不相干。这些产品又会依赖一些共 同的复用业务，如注册登录服务、Session管理服务、账户管理服务等，这些可复用的业 务服务也各自部署在独立的服务器集群上。至于数据层，数据库服务、文件服务、缓存 服务、搜索服务等数据存储与访问服务都部署在各自独立的服务器集群上。
位于应用层的服务器通常为了应对高并发的访问请求，会通过负载均衡设备将一组 服务器组成一个集群共同对外提供服务，当负载均衡设备通过心跳检测等手段监控到某 台应用服务器不可用时，就将其从集群列表中剔除，并将请求分发到集群中其他可用的 服务器上，使整个集群保持可用，从而实现应用高可用。位于服务层的服务器情况和应用层的服务器类似，也是通过集群方式实现高可用， 只是这些服务器被应用层通过分布式服务调用框架访问，分布式服务调用框架会在应用 层客户端程序中实现软件负载均衡，并通过服务注册中心对提供服务的服务器进行心跳检 测，发现有服务不可用，立即通知客户端程序修改服务访问列表，剔除不可用的服务器。位于数据层的服务器情况比较特殊，数据服务器上存储着数据，为了保证服务器宕 机时数据不丢失，数据访问服务不中断，需要在数据写入时进行数据同步复制，将数据 写入多台服务器上，实现数据冗余备份。当数据服务器宕机时，应用程序将访问切换到 有备份数据的服务器上。
3.高可用的应用
应用层主要处理网站应用的业务逻辑，因此有时也称作业务逻辑层，应用的一个显 著特点是应用的无状态性。所谓无状态的应用是指应用服务器不保存业务的上下文信息，而仅根据每次请求提 交的数据进行相应的业务逻辑处理，多个服务实例（服务器）之间完全对等，请求提交到任意服务器，处理结果都是完全一样的。
3.1通过负载均衡进行无状态服务的失效转移
不保存状态的应用给高可用的架构设计带来了巨大便利，既然服务器不保存请求的 状态，那么所有的服务器完全对等，当任意一台或多台服务器宕机，请求提交给集群中 其他任意一台可用机器处理，这样对终端用户而言，请求总是能够成功的，整个系统依 然可用。对于应用服务器集群，实现这种服务器可用状态实时监测、自动转移失败任务 的机制是负载均衡。
负载均衡，顾名思义，主要使用在业务量和数据量较高的情况下，当单台服务器不 足以承担所有的负载压力时，通过负载均衡手段，将流量和数据分摊到一个集群组成的 多台服务器上，以提高整体的负载处理能力。目前，不管是幵源免费的负载均衡软件还 是昂贵的负载均衡硬件，都提供失效转移功能。在网站应用中，当集群中的服务是无状 态对等时，负载均衡可以起到事实上高可用的作用，如图5.5所示。
当Web服务器集群中的服务器都可用时，负载均衡服务器会把用户发送的访问请求 分发到任意一台服务器上进行处理，而当服务器10.0.0.1宕机时，负载均衡服务器通过心 跳检测机制发现该服务器失去响应，就会把它从服务器列表中删除，而将请求发送到其 他服务器上，这些服务器是完全一样的，请求在任何一台服务器中处理都不会影响最终 的结果。
由于负载均衡在应用层实际上起到了系统高可用的作用，因此即使某个应用访问量 非常少，只用一台服务器提供服务就绰绰有余，但如果需要保证该服务高可用，也必须 至少部署两台服务器，使用负载均衡技术构建一个小型的集群。
3.2应用服务器集群的Session管理
应用服务器的高可用架构设计主要基于服务无状态这一特性，但是事实上，业务总 是有状态的，在交易类的电子商务网站，需要有购物车记录用户的购买信息，用户每次 购买请求都是向购物车中增加商品；在社交类的网站中，需要记录用户的当前登录状态、 最新发布的消息及好友状态等，用户每次刷新页面都需要更新这些信息。
Web应用中将这些多次请求修改使用的上下文对象称作会话（Session )，单机情况下， Session可由部署在服务器上的Web容器（如JBoss )管理。在使用负载均衡的集群环境 中，由于负载均衡服务器可能会将请求分发到集群任何一台应用服务器上，所以保证每 次请求依然能够获得正确的Session比单机时要复杂很多。
集群环境下，Session管理主要有以下几种手段。
a.Session 复制
应用 服务器开启Web容器的Session复制功能，在集群中的几台服务器之间同步Session对象， 使得每台服务器上都保存所有用户的Session信息，这样任何一台机器宕机都不会导致 Session数据的丢失，而服务器使用Session时，也只需要在本机获取即可。如网5.6。
这种方案虽然简单，从本机读取Session信息也很快速，但只能使用在集群规模比较 小的情况下。当集群规模较大时，集群服务器间需要大量的通信进行Session复制，占用 服务器和网络的大量资源，系统不堪负担。而且由于所有用户的Session信息在每台服务 器上都有备份，在大量用户访问的情况下，甚至会出现服务器内存不够Session使用的情况而大型网站的核心应用集群就是数千台服务器，同时在线用户可达千万，因此并不 适用这种方案。
b.Session 绑定
Session绑定可以利用负载均衡的源地址Hash算法实现，负载均衡服务器总是将来源 于同一 IP•的请求分发到同一台服务器上（也可以根据Cookie信息将同一个用户的请求总 是分发到同一台服务器上，当然这时负载均衡服务器必须工作在HTTP协议层上。这样在整个会话期间，用户所有的请 求都在同一台服务器上处理，即Session绑定在某台特定服务器上，保证Session总能在这台服务器上获取。这种方法又被称作会话黏滞，如图5.7所示
但是Session绑定的方案显然不符合我们对系统高可用的需求，因为一旦某台服务器 宕机，那么该机器上的Session也就不复存在了，用户请求切换到其他机器后因为没有 Session而无法完成业务处理。因此虽然大部分负载均衡服务器都提供源地址负载均衡算 法，但很少有网站利用这个算法进行Session管理。
c.利用 Cookie 记录 Session
早期的企业应用系统使用C/S (客户端/服务器）架构，一种管理Session的方式是将 Session记录在客户端，每次请求服务器的时候，将Session放在请求中发送给服务器，服 务器处理完请求后再将修改过的Session响应给客户端。
网站没有客户端，但是可以利用浏览器支持的Cookie记录Session，如图5.8所示。
利用Cookie记录Session也有一些缺点，比如受Cookie大小限制，能记录的信息有 限；每次请求响应都需要传输Cookie，影响性能；如果用户关闭Cookie，访问就会不正 常。但是由于Cookie的简单易用，可用性高，支持应用服务器的线性伸缩，而大部分应 用需要记录的Session信息又比较小。因此事实上，许多网站都或多或少地使用Cookie 记录 Session.
d.Session服务器
Session服务器利用独立部署的Session服务器(集群）统一•管理Session， 应用服务器每次读写Session时，都访问Session服务器，如图5.9所示。
这种解决方案事实上是将应用服务器的状态分离，分为无状态的应用服务器和有状 态的Session服务器，然后针对这两种服务器的不同特性分别设计其架构。对于有状态的Session服务器，一种比较简单的方法是利用分布式缓存、数据库等， 在这些产品的基础上进行包装，使其符合Session的存储和访问要求。如果业务场景对 Session管理有比较高的要求，比如利用Session服务集成单点登录（SSO )、用户服务等 功能，则需要开发专门的Session服务管理平台。
4. 高可用的服务
可复用的服务模块为业务产品提供基础公共服务，大型网站中这些服务通常都独立 分布式部署，被具体应用远程调用。可复用的服务和应用一样，也是无状态的服务，因 此可以使用类似负载均衡的失效转移策略实现高可用的服务。
除此之外，具体实践中，还有以下几点高可用的服务策略。
a.分级管理
运维上将服务器进行分级管理，核心应用和服务优先使用更好的硬件，在运维响应 速度上也格外迅速。显然，用户及时付款购物比能不能评价商品更重要，所以订单、支 付服务比评价服务有更高优先级。同时在服务部署上也进行必要的隔离，避免故障的连锁反应。低优先级的服务通过 启动不同的线程或者部署在不同的虚拟机上进行隔离，而高优先级的服务则需要部署在 不同的物理机上，核心服务和数据甚至需要部署在不同地域的数据中心。
b.超时设置
由于服务端宕机、线程死锁等原因，可能导致应用程序对服务端的调用失去响应， 进而导致用户请求长时间得不到响应，同时还占用应用程序的资源，不利于及时将访问 请求转移到正常的服务器上。
在应用程序中设置服务调用的超时时间，一旦超时，通信框架就抛出异常，应用程 序根据服务调度策略，可选择继续重试或将请求转移到提供相同服务的其他服务器上。
c.异步调用
应用对服务的调用通过消息队列等异步方式完成，避免一个服务失败导致整个应用 请求失败的情况。如提交一个新用户注册请求，应用需要调用三个服务：将用户信息写 入数据库，发送账户注册成功邮件，开通对应权限。如果采用同步服务调用，当邮件队 列阻塞不能发送邮件时，会导致其他两个服务也无法执行，最终导致用户注册失败。
如果釆用异步调用的方式，应用程序将用户注册信息发送给消息队列服务器后立即 返回用户注册成功响应。而记录用户注册信息到数据库、发送用户注册成功邮件、调用 用户服务幵通权限这三个服务作为消息的消费者任务，分别从消息队列获取用户注册信 息异步执行。即使邮件服务队列阻塞，邮件不能成功发送，也不会影响其他服务的执行， 用户注册操作可顺利完成，只是晚一点收到注册成功的邮件而已。
当然不是所有服务调用都可以异步调用，对于获取用户信息这类调用，釆用异步方 式会延长响应时间，得不偿失。对于那些必须确认服务调用成功才能继续下一步操作的 应用也不合适使用异步调用。
d.服务降级
在网站访问高峰期，服务可能因为大量的并发调用而性能下降，严重时可能会导致 服务宕机。为了保证核心应用和功能的正常运行，需要对服务进行降级。降级有两种手 段：拒绝服务及关闭服务。
拒绝服务：拒绝低优先级应用的调用，减少服务调用并发数，确保核心应用正常使 用；或者随机拒绝部分请求调用，节约资源，让另一部分请求得以成功，避免要死大家 一起死的惨剧。貌似Twitter比较喜欢使用随机拒绝请求的策略，经常有用户看到请求失 败的故障页面，但是问下身边的人，其他人都正常使用，自己再刷新页面，也好了。
关闭功能：关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约 系统开销，为重要的服务和功能让出资源。淘宝在每年的“双十一”促销中就使用这种 方法，在系统最繁忙的时段关闭“评价”、“确认收货”等非核心服务，以保证核心交易服 务的顺利完成。
e.幂等性设计
应用调用服务失败后，会将调用请求重新发送到其他服务器，但是这个失败可能是 虚假的失败。比如服务已经处理成功，但因为网络故障应用没有收到响应，这时应用重 新提交请求就导致服务重复调用，如果这个服务是一个转账操作，就会产生严重后果。服务重复调用是无法避免的，应用层也不需要关心服务是否真的失败，只要没有收 到调用成功的响应，就可以认为调用失败，并重试服务调用。因此必须在服务层保证服 务重复调用和调用一次产生的结果相同，即服务具有幂等性。有些服务天然具有幂等性，比如将用户性别设置为男性，不管设置多少次，结果都 一样。但是对于转账交易等操作，问题就会比较复杂，需要通过交易编号等信息进行服 务调用有效性校验，只有有效的操作才能继续执行。
5.高可用的数据
不同于高可用的应用和服务，由于数据存储服务器上保存的数据不同，当某台服务 器宕机的时候，数据访问请求不能任意切换到集群中其他的机器上。
保证数据存储高可用的手段主要是数据备份和失效转移机制。数据备份是保证数据 有多个副本，任意副本的失效都不会导致数据的永久丢失，从而实现数据完全的持久化。 而失效转移机制则保证当一个数据副本不可访问时，可以快速切换访问数据的其他副本， 保证系统可用。
关于缓存服务的高可用，在实践中争议很大，一种观点认为缓存已经成为网站数据 服务的重要组成部分，事实上承担了业务中绝大多数的数据读取访问服务，缓存服务失 效可能会导致数据库负载过高而宕机，进而影响整个网站的可用性，因此缓存服务需要 实现和数据存储服务同样的高可用。
另一种观点认为，缓存服务不是数据存储服务，缓存服务器宕机引起缓存数据丢失 导致服务器负载压力过高应该通过其他手段解决，而不是提高缓存服务本身的高可用。
笔者持后一种观点，对于缓存服务器集群中的单机宕机，如果缓存服务器集群规模 较大，那么单机宕机引起的缓存数据丢失比例和数据库负载压力变化都较小，对整个系 统影响也较小。扩大缓存服务器集群规模的一个简单手段就是整个网站共享同一个分布 式缓存集群，单独的应用和产品不需要部署自己的缓存服务器，只需要向共享缓存集群 申请缓存资源即可。并且通过逻辑或物理分区的方式将每个应用的缓存部署在多台服务 器上，任何一台服务器宕机引起的缓存失效都只影响应用缓存数据的一小部分，不会对 应用性能和数据库负载造成太大影响。
5.1 CAP 原理
高可用的数据有如下几个层面的含义。
数据持久性:保证数据可持久存储，在各种情况下都不会出现数据丢失的问题。为了实现数据的 持久性，不但在写入数据时需要写入持久性存储，还需要将数据备份一个或多个副本， 存放在不同的物理存储设备上，在某个存储故障或灾害发生时，数据不会丢失。
数据可访问性:在多份数据副本分别存放在不同存储设备的情况下，如果一个数据存储设备损坏， 就需要将数据访问切换到另一个数据存储设备上，如果这个过程不能很快完成（终端用 户几乎没有感知），或者在完成过程中需要停止终端用户访问数据，那么这段时间数据是 不可访问的。
数据一致性:在数据有多份副本的情况下，如果网络、服务器或者软件出现故障，会导致部分副 本写入成功，部分副本写入失败。这就会造成各个副本之间的数据不一致，数据内容冲 突。实践中，导致数据不一致的情形有很多种，表现形式也多种多样，比如数据更新返 回操作失败，事实上数据在存储服务器已经更新成功。
CAP原理认为，一个提供数据服务的存储系统无法同时满足数据一致性 (Consistency)、数据可用性（Availibility )、分区耐受性(Patition Tolerance,系统具有跨 网络分区的伸缩性）这三个条件
在大型网站应用中，数据规模总是快速扩张的，因此可伸缩性即分区耐受性必不可少，规模变大以后，机器数量也会变得庞大，这时网络和服务器故障会频繁出现，要想 保证应用可用，就必须保证分布式处理系统的高可用性。所以在大型网站中，通常会选 择强化分布式存储系统的可用性（A )和伸缩性（P )，而在某种程度上放弃一致性（C )。 一般说来，数据不一致通常出现在系统高并发写操作或者集群状态不稳（故障恢复、集 群扩容……）的情况下，应用系统需要对分布式数据处理系统的数据不一致性有所了解 并进行某种意义上的补偿和纠错，以避免出现应用系统数据不正确。
具体说来，数据一致性又可分为如下几点。
数据强一致:各个副本的数据在物理存储中总是一致的；数据更新操作结果和操作响应总是一致 的，即操作响应通知更新失败，那么数据一定没有被更新，而不是处于不确定状态。
数据用户一致:即数据在物理存储中的各个副本的数据可能是不一致的，但是终端用户访问时，通 过纠错和校验机制，可以确定一个一致的且正确的数据返回给用户。
数据最终一致:这是数据一致性中较弱的一种，即物理存储的数据可能是不一致的，终端用户访问 到的数据可能也是不一致的（同一用户连续访问，结果不同；或者不同用户同时访问， 结果不同），但系统经过一段时间（通常是一个比较短的时间段）的自我恢复和修正，数 据最终会达到一致。
因为难以满足数据强一致性，网站通常会综合成本、技术、业务场景等条件，结合 应用服务和其他的数据监控与纠错功能，使存储系统达到用户一致，保证最终用户访问 数据的正确性。
5.2数据备份
数据冷备作为一种传统的数据保护手段，依然在网站日常运维中使用，同时 在网站实时在线业务中，还需要进行数据热备，以提供更好的数据可用性。数据热备可分为两种：异步热备方式和同步热备方式。
异步方式是指多份数据副本的写入操作异步完成，应用程序收到数据服务系统的写 操作成功响应时，只写成功了一份，存储系统将会异步地写其他副本（这个过程有可能 会失败)。如图5.11。
在异步写入方式下，存储服务器分为主存储服务器（Master )和从存储服务器（Slave )， 应用程序正常情况下只连接主存储服务器，数据写入时，由主存储服务器的写操作代理模块将数据写入本机存储系统后立即返回写操作成功响应，然后通过异步线程将写操作 数据同步到从存储服务器。
同步方式是指多份数据副本的写入操作同步完成，即应用程序收到数据服务系统的 写成功响应时，多份数据都已经写操作成功。但是当应用程序收到数据写操作失败的响 应时，可能有部分副本或者全部副本都已经写成功了（因为网络或者系统故障，无法返 回操作成功的响应），如图5.12所示。
同步热备具体实现的时候，为了提高性能，在应用程序客户端并发向多个存储服务 器同时写入数据，然后等待所有存储服务器都返回操作成功的响应后，再通知应用程序 写操作成功。
这种情况下，存储服务器没有主从之分，完全对等，更便于管理和维护。存储服务 客户端在写多份数据的时候，并发操作，这意味着多份数据的总写操作延迟是响应最慢 的那台存储服务器的响应延迟，而不是多台存储服务器响应延迟之和。其性能和异步热 备方式差不多。
传统的企业级关系数据库系统几乎都提供了数据实时同步备份的机制。而一开始就 为大型网站而设计的各种NoSQL数据库（如HBase )更是将数据备份机制作为产品最主 要的功能点之一。
关系数据库热备机制就是通常所说的Master-Slave同步机制。Master-Slave机制不但 解决了数据备份问题，还改善了数据库系统的性能，实践中，通常使用读写分离的方法
访问Slave和Master数据库，写操作只访问Master数据库，读操作只访问Slave数据库。
5.3失效转移
若数据服务器集群中任何一台服务器宕机，那么应用程序针对这台服务器的所有读 写操作都需要重新路由到其他服务器，保证数据访问不会失败，这个过程叫作失效转移。
失效转移操作由三部分组成：失效确认、访问转移、数据恢复。
6.高可用网站的软件质量保证
6.1网站发布
网站发布毕竟是一次提前预知的服务器宕机，所以过程可以更柔和，对用户影 响更小。通常使用发布脚本来完成发布，其流程如图5.14所示。
发布过程中，每次关闭的服务器都是集群中的一小部分，并在发布完成后立即可以 访问，因此整个发布过程不影响用户使用。
6.2预发布验证
在网站发布时，并不是把测试通过的代码包直接发布到线上服务器，而是先发 布到预发布机器上，开发工程师和测试工程师在预发布服务器上进行预发布验证，执行 一些典型的业务流程，确认系统没有问题后才正式发布。
6.3灰度发布
大型网站的主要业务服务器集群规模非常庞大，比如某大型应用集群服务器数量超 过一万台。一旦发现故障，即使想要发布回滚也需要很长时间才能完成，只能眼睁睁看 着故障时间不断增加却干着急。为了应付这种局面，大型网站会使用灰度发布模式，将 集群服务器分成若干部分，每天只发布一部分服务器，观察运行稳定没有故障，第二天 继续发布一部分服务器，持续几天才把整个集群全部发布完毕，期间如果发现问题，只 需要回滚已发布的一部分服务器即可。如图5.18所示。
7.网站运行监控
7.1监控数据采集
广义上的网站监控涵盖所有非直接业务行为的数据釆集与管理，包括供数据分析师 和产品设计师使用的网站用户行为日志、业务运行数据，以及供运维工程师和开发工程 师使用的系统性能数据等。
a.用户行为日志收集
用户行为日志指用户在浏览器上所做的所有操作及其所在的操作环境，包括用户操 作系统与浏览器版本信息，ip地址、页面访问路径、页面停留时间等，这些数据对统计 网站PV/UV指标、分析用户行为、优化网站设计、个性化营销与推荐等非常重要。
具体用户行为日志收集手段有两种。
服务器端日志收集。这个方案比较简单，Apache等几乎所有Web服务器都具备曰志记录功能，可以记录大部分用户行为日志，开启Web服务器的日志记录功能即可。其缺 点是可能会出现信息失真，如IP ±也址是代理服务器地址而不是用户真实IP;无法识别访 问路径等。
客户端浏览器日志收集.利用页面嵌入专门的JavaScript脚本可以收集用户真实的操 作行为，因此比服务器日志收集更加精准。其缺点是比较麻烦，需要在页面嵌入特定的 JavaScript脚本来完成。此外，大型网站的用户日志数据量惊人，数据存储与计算压力很大，目前许多网站 逐步开发基于实时计算框架Storm的日志统计与分析工具。
b.服务器性能监控
收集服务器性能指标，如系统Load、内存占用、磁盘10、网络IO等对尽早做出故 障预警，及时判断应用状况，防患于未然，将故障扼杀在萌芽时期非常重要。此外根据 性能监控数据，运维工程师可以合理安排服务器集群规模，架构师及时改善系统性能及 调整系统伸缩性策略。
目前网站使用比较广泛的开源性能监控工具是Ganglia，它支持大规模服务器集群， 并支持以图形的方式在浏览器展示实时性能曲线。
c.运行数据报告
除了服务器系统性能监控，网站还需要监控一些与具体业务场景相关的技术和业务 指标，比如缓冲命中率、平均响应延迟时间、每分钟发送邮件数目、待处理的任务总数等。 •
对于服务器性能监控，网站运维人员可以在初始化系统时统一部署，应用程序开发 完全不关心服务器性能监控。而运行数据需要在具体程序中采集并报告，汇总后统一显 示，应用程序需要在代码中处理运行数据釆集的逻辑。
7.2监控管理
监控数据采集后，除了用作系统性能评估、集群规模伸缩性预测等，还可以根据实 时监控数据进行风险预警，并对服务器进行失效转移，自动负载调整，最大化利用集群 所有机器的资源。
系统报警
在服务器运行正常的情况下，其各项监控指标基本稳定在一个特定水平，如果这些 指标超过某个阈值，就意味着系统可能将要出现故障，这时就需要对相关人员报警，及 时采取措施，在故障还未真正发生时就将其扼杀在萌芽状态。
监控管理系统可以配置报警阈值和值守人员的联系方式，报警方式除了邮件，即时 通信工具，还可以配置手机短信，语音报警，系统发生报警时，工程师即使在千里之外、 夜里睡觉也能被及时通知，迅速响应。
失效转移
除了应用程序访问失败时进行失效转移，监控系统还可以在发现故障的情况下主动 通知应用，进行失效转移。
自动优雅降级
优雅降级是指网站为了应付突然爆发的访问高峰，主动关闭部分功能，释放部分系 统资源，保证网站核心功能正常访问的一个手段。淘宝每年一次的“双十一”促销活动 主动关闭“评价”、“确认收货”等非核心功能，以保证交易功能的正常进行，就可以看作 是一种优雅降级。
网站在监控管理基础之上实现自动优雅降级，是网站柔性架构的理想状态：监控系 统实时监控所有服务器的运行状况，根据监控参数判断应用访问负载情况，如果发现部 分应用负载过高，而部分应用负载过低，就会适当卸载低负载应用部分服务器，重新安 装启动部分高负载应用，使应用负载总体均衡，如果所有应用负载都很高，而且负载压 力还在继续增加，就会自动关闭部分非重要功能，保证核心功能正常运行。