网站高可用架构--二

  可复用的服务模块为业务产品提供基础公共服务,这些服务通常独立分布式部署,被具体应用远程调用。可复用的服务和应用一样,都是无状态服务,应此可以使用类似负载均衡的失效转移策略实现高可用的服务。除此之外,具体实践中,还有以下几点高可用的服务策略:

  1.分级管理

      运维上将服务器进行分级管理,核心应用和服务优先使用更好的硬件,在运维响应速度上也格外迅速。同时在服务部署上也进行必要的隔离,避免故障连锁反应。低优先级的服务通过启动不同的线程或者部署在不同的虚拟机上进行隔离,而优先级较高的服务需要部署在不同的物理机上,核心服务或数据甚至需要部署在不同地域的数据中心。

  2.超时设置

 

  3.异步调用

      应用对服务的调用通过消息队列等异步方式完成,避免一个服务失败导致整个应用请求失败的情况。

  4.服务降级

   在网站访问高峰期,服务可能因为大量的并发调用而性能下降,严重时可能会导致服务宕机。为了保证核心应用和功能的正常运行,需要对服务进行降级。降级有两种手段:拒绝服务及关闭服务。

  拒绝服务:拒绝低优先级应用的调用,减少服务调用并发数,确保核心应用正常使用。或者随机拒绝部分请求调用。

     关闭功能:关闭部分不重要的服务,或者服务内部关闭部分不重要的功能,以节约系统开销,为重要的服务和功能让出资源。

  高可用的数据

     保证数据存储高可用的手段主要是数据备份和失效转移机制。数据备份是保证数据有多个副本,任意副本的失效都不会导致数据的永久丢失,从而实现数据完全持久化。而失效转移机制则保证当一个数据副本不可访问时,可以快速切换访问数据的其他副本,保证系统可用。

  数据持久性:保证数据可持久存储,在各种情况下都不会出现数据丢失的问题。

  数据可访问性:

  数据一致性

  1.CAP原理

 

  具体来说数据一致性又可分为如下几种:

 

  2.数据备份

      冷备的优点是简单和低廉,成本和技术难度都较低。缺点是不能保证数据最终一致性,同时也不能保证数据可用性,从冷备存储中恢复数据需要较长时间,而这段时间无法访问数据,系统也不可用。

      数据热备可分为两种:异步热备方式和同步热备方式。

      在异步写入方式下,存储服务器分为主存储服务器(Master)和从存储服务器(Slave),应用程序正常情况下只连接主存储服务器,数据写入时,由主存储服务器的写操作代理模块将数据写入本地存储系统后立即返回写操作成功响应,然后通过异步线程将写操作数据同步到从存储服务器。

 

      关系数据库热备机制就是通常所说的Master-Slave同步机制.Master-Slave机制不但解决了备份问题,还改善了数据库性能问题.

  3.失效转移

      若数据服务集群中任何一台服务器宕机,那么应用程序针对这台服务器的所有读写操作都需要重新路由到其他服务器,保证数据访问不会失效,这个过程叫做失效转移.失效操作有三部分组成:失效确认、访问转移、数据恢复。

  3.1失效确认

      判断服务器宕机是系统进行失效转移的第一步,系统确认一台服务器是否宕机的手段有两种:心跳检测和应用程序访问失败报告。

 

      对于应用程序的访问失败报告,控制中心还需要再一次发送心跳检测进行确认,以免错误判断服务器宕机,因为一旦数据访问的失效转移,就意味着数据存储多份副本不一致,需要进行一系列复杂操作。

  3.2访问转移

      确认某台服务器宕机后,就需要将数据读写访问中心路由到其他服务器上。对于完全对等的存储服务器,当其中一台宕机后,应用程序根据配置直接切换到对等服务器上。如果存储是不对等的,那么就要重新路由计算,选择存储服务器。

  3.3数据恢复

 因为服务器宕机,所以数据存储副本减少,必须将副本的数目恢复到系统设定的值,否则,再有服务器宕机时,就可能出现系统无法访问转移,数据永久丢失的情况。

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

  网站为了保证线上系统的可用性需要采取一些与传统软件开发不同的质量保证手段。

  网站发布:网站发布过程事实上和服务器宕机效果相当,其对系统可用性的影响也和服务器宕机相似。但是网站发布是一次提前预知的服务器宕机,所以选择过程更柔和,对用户影响更小。通常使用发布脚本来完成发布。

 

  自动化测试

  与发布验证

      在网站发布时,并不是把测试通过的代码包直接发布到线上服务器,而是先发布到预发布机器上,开发工程师和测试工程师在预发布服务器上进行与发布验证,确认系统没有问题后才正式发布。

 

  代码控制

  自动化发布

  灰度发布

      大型网站会使用灰度发布模式,将集群服务器分为若干个部分,每天只发布一部分服务器,观察运行稳定没有故障,接着继续发布一部分服务器,持续一段时间把整个集群全部发布完毕,期间如果发现问题,只需要回滚已发布的一部分服务器即可。

 

原文地址:https://www.cnblogs.com/wxgblogs/p/5483184.html