网站的高可用架构（高可用）
由于种种情况，在业务中硬件故障是常态，所以网站的高可用架构设计的主要目的就是保证服务器硬件故障时服务依然可用、数据依然保持并能够并访问。
高可用的主要手段：数据和服务的冗余备份及失效转移
高可用的应用
应用层高可用的前提是应用无状态性，即应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑判断，
多个服务器实例（服务器）之间完全对等，请求提交到任意服务器，处理结果都是完全一样的。
a.通过负载均衡进行无状态服务的失效转移
负载均衡服务器能够很好实现应用服务器可用状态实时监测、自动转移失败。
b.解决有状态服务的高可用
事实上，业务总是有状态的，在交易类的电子商务网站，需要有购物车记录用户的购买信息，而这些信息通常会存储在
session(上下文对象)中，但是session往往只在一个服务器当中。
通常有以下方式来在集群环境下管理session
- Session复制：在集群中的几台服务器之间同步Session对象，每台服务器都保存所有的用户的Sessio。（这种方式只使用比较小的网站）
- Session绑定：根据IP或者Cookie内容，把某个Session绑定在一个服务器上。（异常情况难以应对）
- 利用Cookie记录Session:但是Cookie的使用往往会限制性能。（很少去使用）
- Session服务器：利用独立部署的Session服务器（集群）统一管理Session,应用服务器每次读写Session时，都访问Session服务器。（如借助Redis集群）
高可用的服务
a.分级管理
根据业务的重要程度进行分级管理，让核心应用和服务优先使用更好的硬件。
b.超时设置
在应用程序中设置服务调用的超时时间，一旦超时，通信框架就抛出异常，应用程序根据服务调度策略，可继续重试或将请求转移到提供相同
服务的其他服务器上。
c.异步调用
对于那些不需要立刻获取反馈结果的业务，采用消息中间件的方式进行异步调用。
d.服务降级
服务降级通常有两种方式
- 拒绝服务：拒绝低优先级的或者随机部分请求，从而缓解高峰时期的并行压力，避免服务器陷入大规模的宕机
- 关闭功能：在高峰期，暂时关闭部分不重要的功能，为核心服务和功能让出资源。
e.幂等性设计
为了避免由于网络故障，没有收到响应而导致重复的服务调用，要保证服务的幂等性。
即在服务层保证服务重复调用和调用一次产生的结果相同。
高可用的数据
a.CAP原理
一个提供数据服务的存储系统无法同时满足：数据一致性、数据可用性、分区耐受性。
C数据一致性：所有应用程序都能访问到相同的数据。
A数据可用性：任何时候，任何应用程序都可以读写访问。
P分区耐受性：系统可以跨网络分区线性伸缩。（通俗来说就是数据的规模可扩展）
在大型网站中通常都是牺牲C，选择AP。为了可能减小数据不一致带来的影响，都会采取各种手段保证数据最终一致。
- 数据强一致：各个副本的数据在物理存储中总是一致的。
- 数据用户一致：数据在物理存储的各个副本可能是不一致的，但是通过纠错和校验机制，会确定一个一致的且正确的数据返回给用户。
- 数据最终一致：物理存储的数据可能不一致，终端用户访问也可能不一致，但是一段时间内数据会达成一致。
b.数据备份
数据备份分为冷备与热备
- 冷备:在关闭数据库的情况下进行数据备份。
- 热备:在数据库对外提供服务的同时，进行数据备份。
同时热备也分为：
- 异步热备：应用程序收到数据库服务系统的写操作成功时，只成功了一份，存储系统将异步地写入其他副本（这个时候分成Master-Slave关系 ）
- 同步热备：应用程序收到数据库服务系统的写操作成功时，多份数据已经写入成功。
c.失效转移
失效转移操作由三部分组成：失效确认、访问转移、数据恢复
1. 失效确认：通过心跳检测工具来确认服务器的运行情况。
2. 访问转移：如果存在对等的服务器（主从关系），当其中一台服务器宕机后，应用程序直接切换到对等服务器上。如果存储是不对等的，那么需要重新计算路由，选择存储服务器。
3. 数据恢复：通常来说数据会设置一个副本数，当一个节点宕机，数据副本必然会降低，这个时候要讲数据恢复到设定的值。
高可用网站的软件质量保证
a.网站的发布
大型网站的发布通常采用脚本完成，将服务器分为A和B两组，分批次平滑上线。
java平滑上线的方案：
1. 在流量低谷时，将服务器分成A、B两组，先让A组服务器下线（负载均衡服务器lvs 断开A组服务器）
2. 更改A组服务器代码和配置后，重启服务器后，分配到测试lvs中进行测试（此过程控制在10分钟内）
3. 断开测试lv,将A组挂到lvs中，瞬间关闭B组连接
4. 之后对B组进行代码和配置进行更改后，重启服务器，进过测试后，挂会到主lvs，完成平滑上线
b.自动化测试
使用Selenium运行在浏览器中，模拟用户操作。
c.预发布验证
在网站发布时，并不是把测试通过的代码包直接发布到线上服务器，而是先发布到预发布机器上，开发工程师和测试工程师在预发布服务器上进行预发布验证，
执行一些典型的业务流程，确认系统没有问题后才正式发布。
d.代码控制
通过svn工具，区分主干与分支。
主干开发、分支发布：便于管理和控制，也利于持续集成。
分支开发，主线发布：便于开发任务同时进行。
e.自动化发布
开发一个自动化发布工具，可以根据响应驱动流程，自动构造代码分支，进行代码合并，执行发布脚本等。
f.灰度发布
将集群服务器分成若干部分，每天只发布一部分服务器，观察运行稳定没有故障后，再继续发布一部分，持续几天才把整个集群全部发布完毕。
这个方式就是那部分用户做测试，从而获取反馈。
网站运行监控
不允许没有监控的系统上线
a.监控数据采集
1.用户行为日志收集
- 服务器端日志收集：利用Log4j日志系统进行收集。
- 客户端浏览器日志收集：通过JS进行埋点收集用户操作日志。
- 使用基于实时计算框架Storm的日志统计与分析工具。
2.服务器性能监控
使用Ganglia工具，以图形的方式在浏览器展示实时性能曲线。
3.运行数据报告
运行数据需要在具体程序中采集并报告，汇总后统一显示，应用程序需要在代码中处理运行数据采集的逻辑。
b.监控管理
监控管理应实现系统报警、失效转移、自动优雅降级。
