网站的高可用架构
网站可用性度量
业界通过用多少个9来衡量网站的可用性
网站不可用时间 = 故障修复时间点 - 故障发现(报告)时间点
网站年度可用性指标 = (1 - 网站不可用时间 / 年度总时间) x 100%
达到4个9就很难了(99.99%)
高可用的网站架构
典型的网站设计通常为三层的架构模型, 即 应用层/服务层/数据层 (从上到下)
各层之间具有相对独立性
应用层负责具体业务逻辑的处理
服务层负责提供可复用的服务
数据层负责数据的存储与访问
大型网站的分层架构及物理服务器的分布式部署使得位于不同层次的服务器具有不同的可用性, 关闭服务器或者宕机时产生的影响也不一样. 高可用的解决方案也差异很大
- 应用层 - 通过负载均衡将一组服务器组成集群对外提供服务, 当负载均衡设备通过心跳等方式检测到某台服务器不可用时将其从集群列表中剔除来实现高可用
- 服务层 - 通过集群方式实现高可用, 只是这些服务被上层的应用层调用, 分布式服务调用框架会在应用层客户端内实现软件负载均衡, 并通过服务注册中心对提供服务的服务器进行心跳检测, 如服务不可用则通知客户端程序修改服务访问列表, 将不可用的服务器剔除
- 数据层 - 为保证数据不丢失, 需要在数据写入时进行数据的同步复制, 将数据写入到多个服务器上实现冗余备份. 服务器宕机时切换到备份服务器
高可用应用
应用层处理网站应用的业务逻辑, 所以也有人叫业务逻辑层, 应用的一个显著的特点是应用到的无状态性
无状态性指应用服务器不保存业务的上下文信息, 而是根据每次请求提交的数据进行业务处理, 多个服务器之间完全对等, 请求提交到任何服务器, 处理的结果都是一样的
通过负载均衡进行无状态服务的失效转移
对于无状态服务来说, 将某个请求交给哪个服务器都是一样的处理结果, 那么, 我们可以通过搭建集群来进行负载均衡, 同时, 当某台服务器出现问题时, 负载均衡服务器通过心跳检测发现该服务器异常, 将其从提供服务的列表中删除, 因为服务是无状态的所以不会影响最终的处理结果
负载均衡实际上在应用层起到了高可用的架构, 因此健全的架构应该是即使某个服务访问量非常少, 一台服务器足够处理, 也最好至少部署两台服务器加上负载均衡技术构建一个小型的集群
集群架构的Session管理
应用服务器的高可用架构主要基于服务无状态这一特征, 但是实际中业务总是有状态的, 比如说有的电商网站可能会有服务是购物车商品的加减等, 这种多次请求修改使用的上下文对象称之为会话(Session), 在负载均衡中, 由于负载均衡服务会将请求分发到集群中的任何一台服务器上, 所以对Session的处理比单机复杂得多, 一般有以下几种方法
Session复制
早期的应用系统使用较多的是在集群里的服务器之间开启Session的同步机制, 达到在每台服务器之间都保存所有用户的Session信息, 即使请求分配到不同的服务器也不会对结果产生影响
这种方法虽然简单粗暴, 从本机直接获取Session也是最快的途径, 但是如果集群的规模变大时服务器间仅仅同步Session就需要占用很大的资源和带宽, 系统不堪重负, 而且每台服务器都保存了这个集群每个用户的Session, 也可能会出现内存不够用的情况, 而且同步需要耗费时间, 有可能出现同步不及时导致的异常情况
Session绑定
负载均衡服务一般自带的有根据来源地址Hash算法来将同一来源的IP请求分发到同一台服务器, 也可以根据Cookie识别, 这个时候负载均衡服务必须工作在HTTP协议层之上, 这样集群中的某个服务器只需保存到达本机的Session即可. 这种又被称作 会话粘滞
但是如果集群中的某个服务器宕机则该机器上面的Session则丢失, 原有的用户被分配到新的服务器, 此时Session丢失, 对业务就产生了影响
利用Cookie记录Session
也有方法是将Session保存在客户端中(以Cookie的形式), 在请求时携带給服务端
这样每次都需要携带Cookie, 影响性能, 同时浏览器可手动阻止Cookie的传输造成请求不正常.
Session服务器
推荐的方法是部署一套Session服务器(最好是集群)来管理Session, 每次请求进入业务服务器后服务器根据逻辑去Session服务器请求获取Session再进行逻辑处理即可
对于Session服务器, 简单的方法是使用分布式缓存(redis/...)实现. 但是如果对Session管理有比较高的要求, 比如SSO(单点登录)等可能需要开发专门的Session服务平台
高可用服务
对于基础的公共服务, 大型网站中通常将其独立出来分布式部署来被具体的逻辑应用远程调用, 可复用的服务也是无状态的, 所以可以使用负载均衡技术的失效转移来实现高可用
分级管理
在服务部署时, 将核心的应用和服务优先分配给更好的硬件, 在运维过程中优先级也更高, 比如购物网站, 付款比评论优先级更高
同时在服务的部署上也进行必要的隔离, 避免发生连锁反应. 比如将低优先级的服务部署在虚拟机上, 高优先级的部署在物理机上等
超时设置
设置调用的超时, 如果在指定时间内被调用的服务没有响应, 此时通信框架应抛出异常, 根据服务调度策略重试漷请求转移
异步调用
对于某些业务, 比如注册, 背后可能需要多步操作, 比如像用户邮箱发送注册成功邮件, 开通对应权限等, 其中邮件服务一般是不具有同步性的. 此时应将邮件服务设置为异步调用, 不对整体的服务产生影响
并不是所有的业务都能通过异步来完成, 因此是否使用需要根据具体的业务来判断
服务降级
在网站访问的高峰期, 服务可能会因为大量的请求而导致性能的下降, 严重时可能会引发宕机. 所以为了保证高峰时核心应用和服务的正常运行, 需要对服务进行降级, 一般有拒绝服务和关闭服务两种
拒绝服务
拒绝低优先级的应用调用, 减少调用并发数量, 确保核心应用的正常使用. 当达到并发数量限制时新进入的请求返回错误给客户端. 或者是随机拒绝请求, 随机ban掉一些请求给客户端, Twitter喜欢这样
关闭功能
直接将服务的入口关闭, 或在服务内部关闭, 让所有用户都无法访问该功能, 淘宝在双11时会关闭 评价/确认收货 等功能保证核心服务顺利完成
幂等性设计
当应用调用服务失败时, 会将调用请求重新发送到其他服务器, 但是这个调用失败有可能失败在了中间一步, 有可能逻辑已经走了一半, 此时发送到其他服务器, 其他服务器重新执行流程可能会出现意想不到的问题
但是服务的重复调用是无法避免的, 应用层也不需要关心服务是否真的失败了, 只要没有接收到调用成功的响应即认为失败, 因此必须在服务层保证服务重复调用和调用一次产生的结果相同, 即服务具有 幂等性
高可用的数据
数据是最宝贵的物质资产, 保护网站的数据就是保护网站的命脉
因此数据的存储和高可用对网站很重要, 对于数据的保存, 一般使用专门的数据存储服务器, 当这个数据存储服务器宕机时, 数据的访问请求一般不能任意的切换到其他的数据服务器上
对于数据存储来讲, 一般使用数据的备份和失效转移机制, 数据备份即保证一份数据有多个副本, 任意副本的失效都不会导致数据的永久丢失. 从而实现数据完全的持久化, 失效转移即当一个数据副本不可访问时, 可以快速切换访问数据的其他副本保证系统可用.
对于缓存服务来说, 业内有两种观点, 一种是随着缓存的大量使用, 缓存的数据也成为了网站数据的一部分, 因此缓存也需要和数据一样实现高可用
一种是缓存部署数据存储服务, 缓存服务器宕机引发缓存数据丢失导致服务器压力高应该通过其他手段解决, 因为缓存本来就是只作用于提高访问速度, 而不是存储数据
CAP原理
在讨论高可用数据服务架构之前, 必须先知道, 为了保证数据的高可用, 网站通常会牺牲一定的数据一致性
什么是高可用?
数据持久性
保证数据可以持久的存储, 在任何情况下都不会丢失数据, 即在写入数据时写入到持久性的存储硬件中, 同时将数据备份到多个副本中, 存放在不同的物理硬件上保证数据不丢失
数据可访问性
如果一个数据存储设备损坏, 需要尽快将数据访问切换到另外一个存储设备上, 在切换期间, 该数据无法被访问
数据一致性
在数据有多个副本的情况下, 如果网络出现故障, 导致部分副本数据写入成功, 部分副本失败, 就会导致数据不一致的问题.
CAP的C为数据一致性, A为数据可用性, P为分区耐受性(跨网络分区的伸缩性)
需要知道的是, CAP不可能面面俱到
具体来说, 数据一致性分为下面几种
数据强一致性
各个副本的数据在物理存储中总是一致的, 数据的更新操作结果和操作响应总是一致的, 即操作响应通知更新失败时数据一定没有更新, 而不是处于不确定的状态
数据用户一致
数据在物理存储中的各个副本的数据不一定是一致的, 但是用户访问时通过纠错和校验机制, 可以确定一个一致的正确的数据返回给用户
数据最终一致
这是数据一致性中比较弱的一种, 即物理存储的数据可能是不一致的, 终端用户访问到的数据也可能是不一致的, 但是系统经过一段时间的自我修正后数据会最终一致
因为现实情况里很难满足数据的强一致性, 所以网站通常会综合成本/技术/业务场景等条件综合考虑来保障数据的正确性
数据备份
数据备份是最有效的数据保护手段, 早期的数据备份手段是冷备份, 即定期将数据复制到某种物理的存储介质中并存档保管, 如果系统存储损坏泽从冷备份的数据中恢复
冷备的优点是简单和廉价, 成本和技术难度都较低, 缺点则是无法保证数据的最终一致性, 由于数据是定期复制, 导致备份中的火速句永远比系统的数据陈旧. 如果系统的数据丢失, 那么从上次备份到系统数据损坏中的数据会永久丢失, 不能从备份中恢复. 同时也无法保证数据可用性, 而且从冷备份中恢复数据需要时间较长, 并且恢复中时无法访问数据, 系统也不可用
因此, 数据的冷备份作为一种传统的方案, 依然在使用, 但是还需要热备份双管齐下以提高数据的可用性
热备份可分为两种: 异步热备份与同步热备份
异步热备
异步指多份数据副本的写入操作异步完成, 应用程序收到数据服务系统返回成功时, 实际上只写成了一份, 然后再异步的同步到其他副本中(也有可能会失败)
在异步的情况下, 存储服务器分为主存储和从存储, 正常情况下应用只链接主存储服务器, 数据写入时写入到主存储中, 然后返回成功, 再异步的同步到从存储服务器中
同步热备
每份数据副本同时写入成功后再返回成功, 也有可能出现写入失败其实已经有几个成功的情况
为了提高速度, 应用程序在接收到指令后同时向多个存储服务器写入数据, 等待所有存储服务器都返回成功后再通知程序写入成功
此种情况下, 存储服务器之间没有主次之分, 完全对等, 便于管理和维护.
失效转移
若数据服务器集群中的其中一个服务器宕机, 那么应用程序针对这个服务器的所有读写操作都需要重新路由到其他的机器, 保证数据访问不失败, 这个过程叫做失效转移, 失效转移一般分下面几步
失效确认
系统首先要确认这个服务器是否宕机, 大多是有两种: 心跳检测和应用程序访问失败报告
一般的, 如果应用程序报告访问失败, 控制中心还需要发送一次心跳进行确认, 避免一次错误的判断导致触发失效转移, 因为失效转移过程复杂
访问转移
确认某台服务器宕机后, 就需要将数据读写的访问请求重新路由到其他正常的服务器上, 如果存储服务器之间完全对等, 其中一台宕机可根据配置重新切换到对等的服务器上. 如果存储不对等, 则需要重新计算出对等的路由选择存储服务器
数据恢复
某台服务器宕机后, 数据存储的副本数量 -1, 应当在后续将副本的数量恢复上, 才能保证访问转移