网站的高可用架构

应用层通过负载均衡设备将一组服务器组成一个集群共同对外提供服务，负载均衡设置通过心跳检测等手段检测到某台应用服务器不可用时，就将其从集群列表剔除，从而使整个集群保持可用。

服务层与应用层类似，只是这些服务器被应用层通过分布式服务调用框架访问，分布式服务调用框架会在应用层客户端程序中实现软件负载均衡，并通过服务注册中心对提供服务的服务器进行心跳检测。

 

高可用的应用

应用层主要处理网站应用的业务逻辑，也被称为业务逻辑层，应用层一个显著的特点就是无状态性。这样的特点为负载均衡进行无状态服务的失效转移提供了支持。

Session管理

应用服务器的高可用架构设置主要基于服务无状态这一特性，但是业务总是有状态的。比如用户的Seesion数据，集群环境下有如下几种Session管理措施。

① session 复制

将session复制到每一台应用集群服务器中，但当集群规模越来越大时，同步Session的成本也会越来越高。

② session绑定

Session绑定可以利用负载均衡的源地址Hash算法实现，负载均衡服务器总是将同一IP的请求分发到同一台服务器上，这样一个用户的Session就绑定再某台特定的服务器上，但是当这台服务器宕机后，用户切换到其他服务器上回因为没有Session导致业务无法完成。

③ 利用Cookie记录Session

这个方案是将本该服务端存储的Session信息，下发到Cookie中，并存入浏览器，但是同样存在问题：cookie的大小限制，能记录的信息有限。

④ Session 服务器

利用独立部署的Session服务器集群统一管理Session，应用服务器每次读写Session时，都访问Session服务器。这种解决方案事实上是将应用服务器的状态分离。分为无状态的应用服务器和有状态的Session服务器，然后针对这两种服务器的不同特性分别设计其架构。

 

高可用的服务

可复用的服务和应用一样，也是无状态的服务，因此可以使用类似负载均衡的失效转移策略实现高可用的服务。

分级管理

运维上将服务器进行分级管理，核心应用和服务优先使用最好的硬件。

超时设置

为避免服务器宕机，线程死锁等原因导致请求长时间得不到响应，同时还占用应用程序资源，应在应用程序中设置超时时间，一旦超时，通信框架抛出异常，应用程序根据服务调度策略，可继续重试或将请求转移到其他服务器上。

异步调用

已经提到多次，此处不再重复

服务降级

在网站访问高峰期，为了保证核心应用和功能的正常运行，需要对服务进行降级，降级有两种手段：拒绝服务和关闭服务。

幂等性设计

必须在服务层保证服务重复调用和调用一次产生的结果相同，即服务具有幂等性。

 

高可用的数据

CAP原理

CAP原理认为，一个提供数据服务的存储系统无法同时满足数据一致性（Consistency）、数据可用性（Availibility）、分区耐受性（Partition Tolerance）这三个条件。在大型网站中，通常会选择强化分布式存储系统的可用性（A）和伸缩性（P），而在某种程度上放弃一致性（C）。

数据一致性可分为如下几点

① 数据强一致

各个副本的数据在物理存储上总是一致的

② 数据用户一致

即数据在物理存储中的各个副本数据可能不一致，但是终端用户访问时，通过纠错和校验机制，可以确定一个一致切正确的数据返回给用户。

③ 数据最终一致性

这是数据一致性中较弱的一种，即物理存储的数据可能不一致，终端用户访问到的数据也是不一致的，但系统通过一段时间的自我恢复和修正，数据最终会达到一致。

数据备份

数据备份分为冷备份和热备份，冷备份就是定期的将数据复制到某种存储介质上并物理存档保管，缺点是不能保证数据最终一致性，并且当数据需要从庞大的磁盘中恢复过来时，需要很长一段时间，这段时间内也无法访问数据，因此也不能保证数据可用性。

热备份可分为两种：异步热备份和同步热备份。

最典型的异步热备份就是数据库的主从同步，主存储服务器的写操作代理模块将数据写入本机存储系统后立即返回写操作成功响应，然后通过异步线程将写操作数据同步到从存储服务器。异步热备份并不能保证数据同步到所有的备份当中。

同步热备份实现时，应用程序并发向多个存储服务器同时写入数据，等待所有的写操作都完成了，才返回操作成功响应，传统企业级关系型数据库系统几乎都提供了数据实时同步备份的机制。

失效转移

① 失效确认

系统确认一台服务器是否宕机的手段有两种：心跳检测和应用程序访问失败报告。

② 访问转移

确认某台服务器宕机后，就需要将数据读写重新路由到其他服务器上。

③ 数据恢复

某台服务器宕机后，数据存储的副本数量就会减少，必须将副本数目恢复到系统设置的值。

 

高可用网站的软件质量保证

网站发布过程

为了减少对客户的影响，网站的发布可以通过关闭负载均衡上一小批的服务器路由，然后将代码同步到这些服务器上，同步完成后再打开这些服务器路由，多次循环的发布一小批应用服务器直至所有服务器上的代码都已经是最新的，此时发布完成。

自动化测试

continue......

预发布验证

预发布服务器是一种特殊用途的服务器，它和线上的正式服务器唯一的不同就是没有配置到负载均衡服务器列表中，外部用户无法访问。因此可以通过在预发布环境上验证功能是否正确。

代码控制

主要是合理高效实用git的分支功能。

自动化发布

continue.....

灰度发布

恢复发布与上面所说的网站发布流程异曲同工，都是每次发布代码到部分服务器，然后在一段时间内观察服务器的运行状态。

 

以上就是构建一个高可用的架构所必须考虑的

 

此文主要参考《大型网站技术架构》一书的内容