怎么确保站点的可用性
Posted wzjhoutai
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了怎么确保站点的可用性相关的知识，希望对你有一定的参考价值。
??站点的高可用架构设计的主要目的就是保证server硬件故障时服务依旧可用、数据依旧保存并能够被訪问。
??实现上述高可用架构的主要手段是数据和服务的冗余备份及失效转移。
??典型的分层模型是三层，即应用层、服务层、数据层；各层之间具有相对独立性，应用层主要负责详细页面逻辑处理；服务层负责提供可复用的服务；数据层负责数据的存储于訪问。中小型站点在详细部署时，通常将应用层和服务层部署在一起，而数据层则另外部署。
??在复杂的大型站点架构中，划分的粒度会更小、更详细，结构更加复杂，server规模更加庞大，但通常还是能够把这些服务划分到这三层中。
高可用的应用
??应用层主要处理站点应用的业务逻辑，因此有时也称作为业务逻辑层，应用的一个显著特点是应用的无状态性。
- 通过负载均衡进行无状态服务的失效转移
负载均衡，顾名思义，主要使用在业务量和数据量较高的情况下。当单台server不足以承担全部的负载压力时，通过负载均衡手段，将流量和数据分摊到一个集群组成的多台server上，以提高总体的负载处理能力。
眼下，无论是开源免费的负载均衡软件还是昂贵的负载均衡硬件。都提供失效转移功能。 - 应用server集群的Session管理
应用server的高可用架构设计主要基于服务无状态这一特性，可是其实，业务总是有状态的。
web应用中将这些多次请求改动使用的上下文对象称作会话（Session)，单机情况下，Session可由部署在server上的Web容器管理。在使用负载均衡的集群环境中，由于负载均衡server可能会将请求分发到集群不论什么一台应用server上，所以保证每次请求依旧能够获得正确的Session比单机时要复杂非常多。
??集群环境下。Session管理主要有下面几种手段。
- Session复制：方案简单。从本机读取session信息也非常高速。但仅仅能使用在集群规模比較小的情况下。当集群规模较大时，集群server间须要大量的通信进行Session复制。占用server和网络的大量资源，系统不堪重负。
- Session绑定：能够利用负载均衡的源地址Hash算法实现，负载均衡server总是将来源于同一ip的请求分发到同一台server上（也能够更具Cookie信息将同一个用户的请求总是分发到同一台server上，当然这是负载均衡server必须工作在http层上）。可是session绑定的方案显然不符合我们队系统高可用的需求。由于一旦某台server宕机，那么该机器的session就不复存在了，用户请求切换到其它机器后由于没有session而无法完毕业务处理。
- 利用Cookie记录session：能够利用浏览器支持的Cookie记录session。可是有一些缺点，比方受Cookie限制大小，能记录的信息有限，每次请求响应都须要传输cookie；假设关闭cookie。訪问就会不正常。
- Sessionserver：利用独立部署的Sessionserver（集群）统一管理Session。应用server每次读写Session时，都訪问Sessionserver。这样的解决方式实际上是将应用server的状态分离。分为无状态的应用server和有状态的Sessionserver，然后针对这两种server的不同恶性分别设计其架构。
高可用的服务
??可复用的服务模块为业务产品提供公共服务，大型站点中这些服务通常都独立分布式部署，被详细应用远程调用。可复用的服务和应用一样。也是无状态的服务，因此能够使用相似负载均衡的失效转移策略实现高可用的服务。
??除此之外。详细实践中，还有下面几点高可用的服务策略。
- 分级管理
运维上将server进行分机管理，核心应用和服务有限使用更好的硬件，在运维响应速度上爷格外迅速。显然。用户及时付款购物比能不能评价商品更重要，所以订单、支付服务比评价服务有更高优先级。同事在服务部署上也进行必要的隔离，避免故障的连锁反应。 - 超时设置
在应用程序中设置服务调用的超时时间，一旦超时，通信框架就抛出异常，应用程序依据服务调度策略，可选择继续重试或者将请求转移到提供同样服务的其它server上 - 异步调用
应用对服务的调用通过消息队列等异步方式完毕。避免一个服务失败导致整个应用请求失败的情况。
当然不是多有服务调用都能够异步调用，对于获取用户信息这类调用，採用异步方式会延长响应时间。得不偿失。对于那些必须确认服务调用成功才干继续下一步操作的应用也不合适使用异步调用。
- 服务降级
降级有两种手段：拒绝服务及关闭服务 - 幂等性设计
有些服务天然具有幂等性，比方讲用户性别设置为男性，无论设置多少次，结果都一样。可是对转账交易等操作，问题就会比較复杂，须要通过交易编号等信息进行服务调用有效性校验。仅仅有有效的操作才干继续执行。
（注：幂等性是系统的接口对外一种承诺(而不是实现), 承诺仅仅要调用接口成功, 外部多次调用对系统的影响是一致的. 声明为幂等的接口会觉得外部调用失败是常态, 而且失败之后必定会有重试.）
高可用的数据
??保证数据存储高可用的手段主要是数据备份和失效转移机智。
站点执行监控
??“不同意没有监控的系统上线“，这是很多站点架构师在做项目上线评审时常说的一句话。
站点执行监控对于站点运维和架构设计优化至关重要，运维没有监控的站点。宛如驾驶没有仪表的飞机。盲人骑瞎马，夜班临深渊而不知。生死尚且未卜，提高可用性、降低故障率就更无从做起了。
- 监控数据採集：用户行为日志收集；server性能监控；执行数据报告；
- 监控管理：系统报警；失效转移；自己主动优雅降级；
以上是关于怎么确保站点的可用性的主要内容，如果未能解决你的问题，请参考以下文章