目录
站可用性
可用性度量
一般要求网站7 x 24小时正常运行，但是实际上非常难，所以会有一部分故障时间。
可用性 = （期望运行时间 - 故障时间）/ 期望运行时间 * 100%
一些知名的大型网站，要求的可用性是99.99%。
如何计算可用性？
假设可用性是99.99%，如果是按1年来算的话，那么故障时间就是
(365 - X）/ 365 = 0.9999，则X = 0.0365天 = 52.56分钟，即365天里有52.56分钟是不可用的。
如何实现高可用？
数据冗余、服务集群
高可用的网站架构
典型的网站都是三层架构，应用层、服务层和数据层；
大型网站同样也是三层架构，也可能包含了分布式架构。
高可用的应用层
应用层主要处理应用业务逻辑，也称为业务逻辑层。
应用层的无状态性，是指应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例之间完全对等，请求提交到任意服务实例，其处理结果都是一样的。
通过负载均衡进行无状态应用的失效转移
大型网站多以负载均衡 + 集群方式运转，负载均衡（软件/硬件）都提供了失效转移功能。
比如10.0.0.1宕机，则负载均衡设备会通过心跳检测机制发现该服务失去响应，就会把它从服务器列表中剔除，并将请求发送到其它可用服务器上。
注意：想要高可用服务，则至少需要两个服务实例，这样才能组成一个最小的集群。
有状态应用集群的Session管理
事实上，很多单体应用在集群化后，依然是有状态的。代码是前后端不分离的，每次登录后都会创建一个Session信息。
在单个服务实例情况下，Session可以由Web容器（比如Tomcat）管理。而在使用负载均衡的集群环境下，因为负载均衡会把请求分发到集群中任意一台服务实例上，所以需要保障每次请求能够获得正确的Session。
集群环境下，Session管理的主要手段：
- Session复制：不同的应用服务器之间相互复制Session。如果集群很大，则复制量太大，不适合大集群。比如Tomcat的Session复制。
- Session绑定（会话粘滞）：使用基于IP的Hash算法实现，即对请求IP地址做Hash算法，得出应该访问哪一个服务，后面每次都会固定访问这个服务。如果这台服务宕机，那么Session信息就会丢失。比如Nginx的IP Hash负载均衡策略。
- 使用Cookie记录Session：在Cookie中记录要访问的服务实例信息。这样每次分发时，负载均衡设备会读取Cookie，然后根据Cookie中的特定数据来决定访问哪一个服务。
- Session服务器：独立部署Session服务器集群，统一管理Session，应用每次读写Session时，都访问Session服务器。比如使用Redis集群存储Session信息。
高可用的服务层
服务层提供可复用的服务，通常都是分布式部署，被具体应用远程调用。
高可用的服务策略：
- 通过负载均衡进行无状态服务的失效转移
- 分级管理：高优先级的服务使用更好的硬件，并对服务进行隔离，避免故障的连锁反应
- 超时设置：设置超时时间，一旦超时，则抛出异常，可选择继续重试或将请求转移到其它服务实例上
- 异步调用：通过消息队列实现异步化，一个业务，划分成多个步骤进消息队列，然后读取消费完成
- 服务降级：在访问高峰期，服务可能因为高并发导致性能下降，为了保证核心功能正常运行，需要对服务进行降级。有两种手段：
- 拒绝服务：拒绝低优先级应用的调用，减少服务调用并发数，确保核心应用正常使用；或者随机拒绝部分请求调用，节约资源，让另外一部分请求得以成功，避免大家都失败的情况。比如Twitter偶尔页面请求报错，但是刷新一下页面又好了
- 关闭服务：关闭不重要的服务，胡总恶化服务内部关闭部分不重要的功能，以节省系统开销，为重要的服务和功能让出资源。比如双十一关闭评价功能
- 幂等性设计：服务调用失败后，当然这个不一定是真的失败，也许是超时导致的失败，实际是成功的。这样就需要幂等性设计，再次调用时，依然可以进入一个正确状态。
高可用的数据层
主要手段：
- 数据备份：保证数据有多个副本，任意副本的失效都不会导致数据的永久丢失
- 失效转移机制：当一个数据副本不可用时，可以快速切换到其它数据副本，保证系统可用
CAP原理
在保证数据的高可用时，网站通常会牺牲另外一个很重要的指标：数据一致性。
高可用的数据有如下几个层面的含义：
- 数据持久性：保证数据可持久存储，无论任何情况下都不会出现数据丢失问题。为了数据持久性，需要将数据备份一个到多个副本，存储在不同的存储设备上。
- 数据可访问性：多个副本数据分别存储于不同的存储设备上的情况下，如果一个数据存储损坏，就需要将数据访问切换到其它的数据存储上。如果这个切换过程很长或需要用户停止访问，则这段时间数据就是不可访问的。
- 数据一致性：在数据有多个副本的情况下，如果网络、服务器或软件出现故障，会导致部分副本写入成功，部分写入失败，就会出现各个副本之间的数据不一致性。其可细分为如下三种：
-
- 数据强一致：各个副本的数据在物理存储上总是一致的
- 数据用户一致：数据在各个副本中可能是不一致的，但是终端用户访问时，通过纠错和校验机制，可以确定一个一致的且正确的数据返回给用户
-
- 数据最终一致：这是数据一致性中较弱的一种，即存储的数据可能是不一致的，终端用户访问的数据可能也是不一致的，但是系统经过一段时间的自我恢复和修正，数据最终会达到一致
CAP原理认为一个提供数据服务的存储系统无法同时满足数据一致性（Consistency）、数据可用性（Availability）、分区容错性（Partition Tolerance，系统具有跨网络分区的伸缩性）这三个条件。分布式系统要么满足CA、要么CP、要么AP，无法同时满足CAP。
举个例子，现在有数据节点d1和d2，需要将数据data复制过去：
- CP：为了保证数据一致性C，则需要将d1复制到d2，这就需要网络通信。但是我们都知道网络通信是不可靠的，假设现在网络分区具有分区容错性，也就是说这个系统可以容忍网络的不可靠。这个时候d2就不一定能及时收到d1复制过来的数据data。为了保证用户访问数据的一致性，d2就只能阻塞，一直等到data数据复制过来后才能返回，这个时候就没法保证高可用性了。
- AP：为了保证高可用性，按照上面的情况，那么就直接返回数据，就可能会出现数据不一致的问题。
- AC：如果要保证可用性和一致性，那么只有在网络好且可靠的情况下才能实现。但是我们都知道网络是不可靠的，是存在丢包、断网等情况的。所以只有把d1和d2都放在一个区内才可以，也就是丧失了P这个属性。其实这个时候整个系统已经不是一个分布式系统了。
大型网站的选择：AP，牺牲掉C。因为一般来说，数据不一致性通常出现在系统高并发写操作或集群状态不稳定（故障恢复、集群扩容...）的情况下，应用系统需要对分布式数据处理系统的数据不一致性有所了解并进行某种意义上的补偿和纠错，以避免出现应用系统数据不正确。
数据备份
冷备：定期备份到存储介质（硬盘、光盘等）中。简单、廉价，成本和技术难度低。不能保证数据最终一致性（因为是定期备份，所以很可能丢失备份后那段时间的数据），也不能保证数据可用性（从冷备中恢复需要一些时间，而这段时间内数据将不可用）。
热备（实时备份）可分为两种：
- 异步热备：设定主节点和从节点，主节点写入数据后立刻返回响应，然后同步异步线程将数据写入到从节点。也就是常说的Master-Slave机制，其不仅解决了数据备份问题，还改善了数据库系统的性能（比如读写分离设计，写主库，读从库）
- 同步热备：多个数据副本的写入操作同步进行，即应用收到写入成功的响应时，意味着所有的副本都已经写入成功。如果收到写入失败的响应，则可能有部分副本写入失败了，也有部分副本写入成功了。这种情况下，所有副本都是对等的，方便管理和维护。
数据备份的几种类型：
- 完全备份：备份所有数据。特点是备份时间最长，但恢复时间最短，操作最方便可靠
- 差异备份：也称差分备份，它是针对完全备份的，即备份上一次的完全备份后发生变化的数据。特点是备份时间较长，占用空间较多，但恢复时间较短
- 增量备份：是针对上一次备份，即上一次备份后，所有发生变化的数据。特点是备份时间较短，占用空间较少，但恢复时间较长
- 按需备份：根据需要有选择地进行数据备份。特点是有很好的选择性。
异地备份：是容灾系统的核心技术，它不同于上面的备份方法，它的特点是具有异地性。它对于保证数据的一致性、可靠性及系统的可扩展性具有重要作用。通过有效的数据复制，实现远程的业务数据与本地业务数据的同步，确保一旦本地系统出现故障，远程的容灾中心能够迅速进行完整的业务接管。其典型例子就是911事件，尽管对金融业造成的巨大损失，但是他们的业务还能够正常运行。
高可用的软件质量保证
数据备份
冷备：定期备份到存储介质（硬盘、光盘等）中。简单、廉价，成本和技术难度低。不能保证数据最终一致性（因为是定期备份，所以很可能丢失备份后那段时间的数据），也不能保证数据可用性（从冷备中恢复需要一些时间，而这段时间内数据将不可用）。
热备（实时备份）可分为两种：
- 异步热备：设定主节点和从节点，主节点写入数据后立刻返回响应，然后同步异步线程将数据写入到从节点。也就是常说的Master-Slave机制，其不仅解决了数据备份问题，还改善了数据库系统的性能（比如读写分离设计，写主库，读从库）
- 同步热备：多个数据副本的写入操作同步进行，即应用收到写入成功的响应时，意味着所有的副本都已经写入成功。如果收到写入失败的响应，则可能有部分副本写入失败了，也有部分副本写入成功了。这种情况下，所有副本都是对等的，方便管理和维护。
数据备份的几种类型：
- 完全备份：备份所有数据。特点是备份时间最长，但恢复时间最短，操作最方便可靠
- 差异备份：也称差分备份，它是针对完全备份的，即备份上一次的完全备份后发生变化的数据。特点是备份时间较长，占用空间较多，但恢复时间较短
- 增量备份：是针对上一次备份，即上一次备份后，所有发生变化的数据。特点是备份时间较短，占用空间较少，但恢复时间较长
- 按需备份：根据需要有选择地进行数据备份。特点是有很好的选择性。
异地备份：是容灾系统的核心技术，它不同于上面的备份方法，它的特点是具有异地性。它对于保证数据的一致性、可靠性及系统的可扩展性具有重要作用。通过有效的数据复制，实现远程的业务数据与本地业务数据的同步，确保一旦本地系统出现故障，远程的容灾中心能够迅速进行完整的业务接管。其典型例子就是911事件，尽管对金融业造成的巨大损失，但是他们的业务还能够正常运行。
高可用的软件质量保证
在网站运维实践中，除了网络、服务器硬件故障等风险外，也有软件本身带来的风险。
- 网站发布：网站发布等于是一次提前预知的服务宕机，所以过程尽可能柔和，对用户影响更小。同处使用发布脚本来完成。发布脚本采用Nginx负载均衡来实现，使用负载均衡将服务从集群列表中移除，关闭服务实例，复制新服务，启动新服务，重新加入集群。重复步骤，直到所有的集群实例都部署完成。
- 自动化测试：线上部署完成后，为验证功能，可使用自动化工具或脚本进行测试。
- 预发布环境：提供预发布环境，保持和生产环境基本一致的情况（同数据库），然后进行验证，通过后才发布到生产环境。
- 代码控制：两种代码管理方式，主干开发、分支发布；主干发布、分支开发。
- 自动化发布：将发布流程自动化，自动提交、代码合并、发布、预发布验证、重新发布、正式发布。自动化程度越高，引入故障的可能性越低。
- 灰度发布：如果网站集群规模非常大，那么自动化发布后，如果都有问题，那就需要很长时间才能回滚。为了解决这个问题，提出了灰度发布的模式，即每次只发布一部分服务，观察一段时间后，如果没有问题，再继续发布其它服务。灰度发布也可以用作测试，即部分服务是新版本，其余服务还是老版本，然后使用新版本进行测试，并收集用户反馈，比较两个版本的满意度，已确定最终的发布版本。这种手段也被称作AB测试。
网站运行监控
不允许没有监控的系统上线！！！
监控数据采集
- 用户行为日志：记录用户OS、浏览器信息、IP信息、访问路径等信息，用于统计网站PV/UV指标、分析用户行为、优化网站设计、个性化营销与推荐等。实现方式：
-
- 服务端日志：从 服务端日志中获取。像Apache、Nginx等都自带这些日志。
- 客户端埋点：在前端代码中埋点，从而记录用户的行为。
- 服务器性能监控：监控系统负载、内存、磁盘、IO情况，提前预警，并通知处理。
- 运行数据报告：比如Oracle的 AWR（Automatic Workload Repository 自动工作负载库） 报告，可以查看Oracle的性能
监控管理
在收集到监控数据后，还需要进行如下操作：
- 系统报警：指标有问题，就进行告警，比如发短信，语音报警灯
- 失效转移：发现故障后，进行失效转移
- 自动优雅降级：指网站为了应付突然而来的高并发，主动关闭部分功能，释放系统资源，保障网站核心功能正常访问的一个手段。比如“双十一”关闭“评价”功能。
819
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
