怎么确保站点的可用性

  站点的高可用架构设计的主要目的就是保证server硬件故障时服务依旧可用、数据依旧保存并可以被訪问。web


  实现上述高可用架构的主要手段是数据和服务的冗余备份失效转移
  典型的分层模型是三层,即应用层、服务层、数据层;各层之间具备相对独立性,应用层主要负责详细页面逻辑处理;服务层负责提供可复用的服务;数据层负责数据的存储于訪问。中小型站点在详细部署时,一般将应用层和服务层部署在一块儿,而数据层则另外部署。算法


  在复杂的大型站点架构中,划分的粒度会更小、更详细,结构更加复杂,server规模更加庞大,但一般仍是可以把这些服务划分到这三层中。浏览器

高可用的应用


  应用层主要处理站点应用的业务逻辑,所以有时也称做为业务逻辑层,应用的一个显著特色是应用的无状态性。markdown

  1. 经过负载均衡进行无状态服务的失效转移
    负载均衡,顾名思义,主要使用在业务量和数据量较高的状况下。当单台server不足以承担所有的负载压力时,经过负载均衡手段,将流量和数据分摊到一个集群组成的多台server上,以提升整体的负载处理能力。
    眼下,不管是开源免费的负载均衡软件仍是昂贵的负载均衡硬件。都提供失效转移功能。
  2. 应用server集群的Session管理
    应用server的高可用架构设计主要基于服务无状态这一特性,但是其实,业务老是有状态的。


    web应用中将这些屡次请求改动使用的上下文对象称做会话(Session),单机状况下,Session可由部署在server上的Web容器管理。在使用负载均衡的集群环境中,因为负载均衡server可能会将请求分发到集群不论什么一台应用server上,因此保证每次请求依旧可以得到正确的Session比单机时要复杂很是多。cookie

  集群环境下。Session管理主要有下面几种手段。网络

  1. Session复制:方案简单。从本机读取session信息也很是高速。但仅仅能使用在集群规模比較小的状况下。当集群规模较大时,集群server间需要大量的通讯进行Session复制。占用server和网络的大量资源,系统不堪重负。
  2. Session绑定:可以利用负载均衡的源地址Hash算法实现,负载均衡server老是未来源于同一ip的请求分发到同一台server上(也可以更具Cookie信息将同一个用户的请求老是分发到同一台server上,固然这是负载均衡server必须工做在http层上)。但是session绑定的方案显然不符合咱们队系统高可用的需求。因为一旦某台server宕机,那么该机器的session就不复存在了,用户请求切换到其它机器后因为没有session而没法完毕业务处理。
  3. 利用Cookie记录session:可以利用浏览器支持的Cookie记录session。但是有一些缺点,比方受Cookie限制大小,能记录的信息有限,每次请求响应都需要传输cookie;假设关闭cookie。訪问就会不正常。
  4. Sessionserver:利用独立部署的Sessionserver(集群)统一管理Session。应用server每次读写Session时,都訪问Sessionserver。这样的解决方式其实是将应用server的状态分离。分为无状态的应用server和有状态的Sessionserver,而后针对这两种server的不一样恶性分别设计其架构。

高可用的服务


  可复用的服务模块为业务产品提供公共服务,大型站点中这些服务一般都独立分布式部署,被详细应用远程调用。可复用的服务和应用同样。也是无状态的服务,所以可以使用类似负载均衡的失效转移策略实现高可用的服务。
  除此以外。详细实践中,还有下面几点高可用的服务策略。session

  1. 分级管理
    运维上将server进行分机管理,核心应用和服务有限使用更好的硬件,在运维响应速度上爷格外迅速。显然。用户及时付款购物比能不能评价商品更重要,因此订单、支付服务比评价服务有更高优先级。同事在服务部署上也进行必要的隔离,避免故障的连锁反应。
  2. 超时设置
    在应用程序中设置服务调用的超时时间,一旦超时,通讯框架就抛出异常,应用程序依据服务调度策略,可选择继续重试或者将请求转移到提供一样服务的其它server上
  3. 异步调用
    应用对服务的调用经过消息队列等异步方式完毕。避免一个服务失败致使整个应用请求失败的状况。
    固然不是多有服务调用都可以异步调用,对于获取用户信息这类调用,採用异步方式会延长响应时间。得不偿失。

    对于那些必须确认服务调用成功才干继续下一步操做的应用也不合适使用异步调用。架构

  4. 服务降级
    降级有两种手段:拒绝服务及关闭服务
  5. 幂等性设计
    有些服务自然具备幂等性,比方讲用户性别设置为男性,不管设置多少次,结果都同样。但是对转帐交易等操做,问题就会比較复杂,需要经过交易编号等信息进行服务调用有效性校验。仅仅有有效的操做才干继续执行。
    (注:幂等性是系统的接口对外一种承诺(而不是实现), 承诺仅仅要调用接口成功, 外部屡次调用对系统的影响是一致的. 声明为幂等的接口会以为外部调用失败是常态, 并且失败以后一定会有重试.)

高可用的数据


  保证数据存储高可用的手段主要是数据备份和失效转移机智。负载均衡

站点执行监控


  “不一样意没有监控的系统上线“,这是不少站点架构师在作项目上线评审时常说的一句话。框架

站点执行监控对于站点运维和架构设计优化相当重要,运维没有监控的站点。宛如驾驶没有仪表的飞机。盲人骑瞎马,夜班临深渊而不知。生死尚且未卜,提升可用性、下降故障率就更无从作起了。

  1. 监控数据採集:用户行为日志收集;server性能监控;执行数据报告;
  2. 监控管理:系统报警;失效转移;本身主动优雅降级;
相关文章
相关标签/搜索