怎么确保站点的可用性

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

??实现上述高可用架构的主要手段是数据和服务的冗余备份失效转移

??典型的分层模型是三层,即应用层、服务层、数据层;各层之间具有相对独立性,应用层主要负责详细页面逻辑处理;服务层负责提供可复用的服务;数据层负责数据的存储于訪问。中小型站点在详细部署时,通常将应用层和服务层部署在一起,而数据层则另外部署。

??在复杂的大型站点架构中,划分的粒度会更小、更详细,结构更加复杂,server规模更加庞大,但通常还是能够把这些服务划分到这三层中。

高可用的应用



??应用层主要处理站点应用的业务逻辑,因此有时也称作为业务逻辑层,应用的一个显著特点是应用的无状态性。

  1. 通过负载均衡进行无状态服务的失效转移

    负载均衡,顾名思义,主要使用在业务量和数据量较高的情况下。当单台server不足以承担全部的负载压力时,通过负载均衡手段,将流量和数据分摊到一个集群组成的多台server上,以提高总体的负载处理能力。

    眼下,无论是开源免费的负载均衡软件还是昂贵的负载均衡硬件。都提供失效转移功能。

  2. 应用server集群的Session管理

    应用server的高可用架构设计主要基于服务无状态这一特性,可是其实,业务总是有状态的。

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

??集群环境下。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的不同恶性分别设计其架构。

高可用的服务



??可复用的服务模块为业务产品提供公共服务,大型站点中这些服务通常都独立分布式部署,被详细应用远程调用。可复用的服务和应用一样。也是无状态的服务,因此能够使用相似负载均衡的失效转移策略实现高可用的服务。

??除此之外。详细实践中,还有下面几点高可用的服务策略。

  1. 分级管理

    运维上将server进行分机管理,核心应用和服务有限使用更好的硬件,在运维响应速度上爷格外迅速。显然。用户及时付款购物比能不能评价商品更重要,所以订单、支付服务比评价服务有更高优先级。同事在服务部署上也进行必要的隔离,避免故障的连锁反应。

  2. 超时设置

    在应用程序中设置服务调用的超时时间,一旦超时,通信框架就抛出异常,应用程序依据服务调度策略,可选择继续重试或者将请求转移到提供同样服务的其它server上

  3. 异步调用

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

    当然不是多有服务调用都能够异步调用,对于获取用户信息这类调用,採用异步方式会延长响应时间。得不偿失。

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

  4. 服务降级

    降级有两种手段:拒绝服务及关闭服务

  5. 幂等性设计

    有些服务天然具有幂等性,比方讲用户性别设置为男性,无论设置多少次,结果都一样。可是对转账交易等操作,问题就会比較复杂,须要通过交易编号等信息进行服务调用有效性校验。仅仅有有效的操作才干继续执行。

    (注:幂等性是系统的接口对外一种承诺(而不是实现), 承诺仅仅要调用接口成功, 外部多次调用对系统的影响是一致的. 声明为幂等的接口会觉得外部调用失败是常态, 而且失败之后必定会有重试.)

高可用的数据



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

站点执行监控



??“不同意没有监控的系统上线“,这是很多站点架构师在做项目上线评审时常说的一句话。

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

  1. 监控数据採集:用户行为日志收集;server性能监控;执行数据报告;
  2. 监控管理:系统报警;失效转移;自己主动优雅降级;
时间: 2024-10-13 16:20:47

怎么确保站点的可用性的相关文章

zabbix web scenario 监控Web站点的可用性

Zabbix也可以监控Web站点的可用性.前提是安装Zabbix时启用了libcurl支持. 要使用Web监控,首先需要定义Web Scenario.而每个Web Scenario有一个或者多个 "Http 请求"或者 "Steps"构成.Zabbix根据定义的顺序定期的执行步骤. 在一个Web Scenario中,搜集到的信息包含一下几种: 1. 整个web场景所有步骤的平均下载速度(每秒) 2. 执行出错的步骤(steps)编号 3. 最近的错误信息 而在每一个

[译]作为一个web开发人员,哪些技术细节是在发布站点前你需要考虑到的

前日在cnblogs上看到一遍文章<每个程序员都必读的12篇文章>,其中大多数是E文的. 先译其中一篇web相关的"每个程序员必知之WEB开发". 原文: http://programmers.stackexchange.com/questions/46716/what-technical-details-should-a-programmer-of-a-web-application-consider-before 问:对于一个web开发人员来说,在发布一个站点之前,他需

一个web开发人员在发布站点前你需要考虑哪些技术细节

转自http://www.xker.com/page/e2014/0520/132486.html 一个web开发人员在发布站点前你需要考虑哪些技术细节 文章转自Hedgehog博客 前日在cnblogs上看到一遍文章<每个程序员都必读的12篇文章>,其中大多数是E文的. 先译其中一篇web相关的”每个程序员必知之WEB开发”. 原文: http://programmers.stackexchange.com/questions/46716/what-technical-details-sho

作为一个web开发人员,哪些技术细节是在发布站点前你需要考虑到的

前日在cnblogs上看到一遍文章<每个程序员都必读的12篇文章>,其中大多数是E文的. 先译其中一篇web相关的"每个程序员必知之WEB开发". 原文: http://programmers.stackexchange.com/questions/46716/what-technical-details-should-a-programmer-of-a-web-application-consider-before 问:对于一个web开发人员来说,在发布一个站点之前,他需

大型站点技术架构(六)--站点的伸缩性架构

大型站点技术架构(一)--大型站点架构演化 大型站点技术架构(二)--架构模式 大型站点技术架构(三)--架构核心要素 大型站点技术架构(四)--站点的高性能架构 大型站点技术架构(五)--站点高可用架构 站点系统的伸缩性架构最重要的技术手段就是使用server集群功能.通过不断地向集群中加入server来增强整个集群的处理能力. "伸"即站点的规模和server的规模总是在不断扩大. 1.站点架构的伸缩性设计 站点的伸缩性设计能够分成两类,一类是依据功能进行物理分离实现伸缩.一类是单

你需要知道的18个Web可用性原则

使用网格线来做网站页面结构 在你为一个有创意的网格页面框布局兴奋并尖叫的时候,你要保证你的整个网站的页面布局都在框子(Box)里边.网格结构能让访问者视线流固定在本页面,这是很关键的.一旦你将页面拉下来,页面也是很清晰简洁的 - 创造有趣的东西你需要放进优秀的设计放到网格里边. 不要忘记搜索表单 在你为一个有创意的网格页面框布局兴奋并尖叫的时候,你要保证你的整个网站的页面布局都在框子(Box)里边.网格结构能让访问者视线流固定在本页面,这是很关键的.一旦你将页面拉下来,页面也是很清晰简洁的 -

站点整改反馈功能即将上线

在站长平台与百度反作弊团队共同努力下,百度站长平台即将推出站点整改反馈功能:提前通知站长站点内容存在低质与作弊问题,站长若在一定时间内修正问题,可避免被搜索引擎惩罚.希望使用此功能的站长请尽快登录百度站长平台,验证网站.完善联系方式. 功能具体流程如下图所示:站长在收到带有反馈功能的消息后,按照消息提示对网站问题进行整改,然后点击反馈按钮,申请反作弊团队对网站进行重新检测,确实完成整改的网站,可免受惩罚.  [重要]反馈消息将由百度反作弊团队指定发出,消息内容下方的蓝色反馈按钮仅可点击一次,请站

Visual studio 调试发布到IIS站点方式一

在项目开发过程中,前端项目可能调用多个API接口,并且这些API接口是在同一个资源解决方案下的,一个资源解决方案下只能设置一个启动项目.那么问题来了,某个API业务需求变更或有BUG,解决后是需要调试的.此时可以将这个API项目设置为启动项目运行起来,然后修改前端配置文件API的URL来调试.这只是一对一的调试方式,但如果同时多个API接口有修改且需要调试,就要改变启动项目运行调试,并还要修改前端配置文件中的多个API URL.这样显得特别麻烦,可以所有API发布到IIS上来调试. 1.IIS发

关于高并发下网站高可用性问题的总结

本文是工作中遇到的网站高并发问题及相关解决思路和方法的总结,比较零碎,且会在后续工作过程中不停丰富,有不对之处,请指正. 1.前后端分离 前后端分离后,可以使用更加轻量级的web容器部署静态资源,如nginx等,还可以对静态资源进行cdn加速,同时针对营销或者活动页面,可以使用内容管理平台,实时更改页面,快速迭代.服务端出来后,专注于业务流程,且为后续的服务拆分提供了便利. 2.按照业务领域拆分服务 随着业务量的增加,单体架构不能再满足高并发场景,按照业务领域将服务端拆分为多个独立的服务.服务拆