精华内容
下载资源
问答
  • 2019-11-13 16:00:41

    含义

    可用性

    可用性是在某个考察时间,系统能够正常运行的概率或时间占有率期望值。

    可靠性

    可靠性一般指产品可靠性,是元件、产品、系统在一定时间内、在一定条件下无故障地执行指定功能的能力或可能性。
    光看定义比较抽象,下面看一个具体的例子。

    如果某个系统在每小时崩溃1ms,那么它的可用性就超过99.9999%,但是它还是高度不可靠。与之类似,如果一个系统从来不崩溃,但是每年要停机两星期,那么它是高度可靠的,但是可用性只有96%。

    可用性被定义为系统的一个属性,它说明系统已准备好,马上就可以使用。换句话说,高度可用的系统在任何给定的时刻都能及时地工作。
    可靠性是指系统可以无故障地持续运行,是一个持续的状态。与可用性相反,可靠性是根据时间段而不是任何时刻来进行定义的。

    1 WHAT - 什么是可用性?

    定义可用性,可以先定义什么是不可用。
    以网站为例,需要经历若干环节,网站的页面才能呈现在最终的用户面前;而其中的任何一个环节出现了故障,都可能会导致网站的页面不可访问,也就是出现了网站不可用的情况。
    我们可以利用百分比来对网站可用性进行度量:

    网站不可用时间=完成故障修复的时间点 - 故障发现的时间点
    网站年度可用时间=年度总时间 - 网站不可用时间
    网站年度可用性=(网站年度可用时间/年度总时间) x 100%

    99.99%可用性如何计算?

    举例:一些知名大型网站的可用性可达到99.99%(俗称4个9),我们可以算一下一年下来留给处理故障的时间有多少?
    年度总时间=365 * 24 * 60=525600分钟
    网站不可用时间=525600 * (1-99.99%)=52.56分钟
    也就是,如果网站要达到4个9的可用性,一年下来网站不可用时间最多53分钟(也就是不足1个小时)。

    可见,高可用性就是技术实力的象征,高可用性就是竞争力。

    2 WHY - 为什么会出现不可用?

    1. 硬件故障。网站多运行在普通的商用服务器,而这些服务器本身就不具备高可用性,再加之网站系统背后有数量众多服务器,那么一定时间内服务器宕机是大概率事件,直接导致部署在该服务器上的服务受影响。
    2. 软件BUG或网站更新升级发布。BUG不能消灭,只能减少;上线后的系统在运行过程中,难免会出现故障,而这些故障同样直接导致某些网站服务不可用;此外,网站更新升级发布也会引起相对较频繁的服务器宕机。
    3. 不可抗拒力。如地震、水灾、战争等。

    3 HOW - 如何做到高可用

    核心思想

    网站高可用的主要技术手段是服务与数据的冗余备份失效转移。同一服务组件部署在多台服务器上;数据存储在多台服务器上互相备份。通过上述技术手段,当任何一台服务器宕机或出现各种不可预期的问题时,就将相应的服务切换到其他可用的服务器上,不影响系统的整体可用性,也不会导致数据丢失。
    从架构角度看可用性:当前网站系统多采用经典的分层模型,从上到下为:应用层、服务层与数据层

    应用层主要实现业务逻辑处理;
    服务层提供可复用的服务;
    数据层负责数据读写;

    在部署架构上常采用应用和数据分离部署,应用会部署到不同服务器上,这些服务器被称为应用层的服务器;
    这些可复用的服务也会各自部署在不同服务器上,称为服务层的服务器;
    而各类数据库系统、文件柜等数据则部署在数据层的服务器。
    硬件故障方面引起不可用的技术解决措施:

    (1)应用服务器。可通过负载均衡设备将多个应用服务器构建为集群对外提供服务(前提是这些服务需要设计为无状态,即应用服务器不保存业务的上下文信息,而仅根据每次请求提交的数据进行业务逻辑的操作响应),当均衡设备通过心跳检测手段检测到应用服务器不可用时,则将其从集群中移除,并将请求切换到其他可用的应用服务上。

    (2)服务层服务器。这些服务器被应用层通过分布式服务框架(如Dubbo)访问,分布式服务框架可在应用层客户端程序中实现软件负载均衡,并通过服务注册中心提供服务的服务器进行心跳检测,当发现有服务器不可用时,立即通知客户端程序修改服务列表,同时移除响应的服务器。

    (3)数据服务器。需要在数据写入时进行数据同步复制,将数据写入多台服务器上,实现数据冗余备份;当数据服务器宕机时,应用程序将访问切换到有备份数据的服务器上。

    软件方面引起不可用的技术解决措施:通过软件开发过程进行质量保证。通过预发布验证、严格测试、灰度发布等手段,尽量减少上线服务的故障。

    更多相关内容
  • 系统可用性

    千次阅读 2020-07-16 16:09:06
    一个网站、系统的战术包括可用性战术、可修改性战术、性能战术、安全性战术、可测试性战术、易用性战术。可用性是在某个考察时间,系统能够正常运行的概率或时间占有率期望值。它是衡量设备在投入使用后实际使用的...

            一个网站、系统的战术包括可用性战术、可修改性战术、性能战术、安全性战术、可测试性战术、易用性战术。可用性是在某个考察时间,系统能够正常运行的概率或时间占有率期望值。它是衡量设备在投入使用后实际使用的效能,是设备或系统的可靠性、可维护性和维护支持性的综合特性。采用可用性战术将会阻止错误发展为故障,或者至少能够把错误的影响限制在一定范围内,从而使系统恢复成为可能。对于一个软件和系统,出现故障、不可用的现象是非常重大的事故,那么如何衡量系统的可用性和提高系统系统的可用性呢?

    可用性的衡量

    衡量系统的高可用性,一般通过SLA,全称Service Level Agrement,也就是有几个9的高可用性。我们经常可以看到很多公司会宣称自己的系统可以达到99.99%、99.999%等。

    工业界通常通过统计故障发生到恢复的时间的方法来测量SLA。一般以年度为单位,统计一年内的系统不可用总时长。具体对应关系如下表:

       对于 SLA 指标来说,9 的数字越多可用性越高,宕机时间越少,系统就可以在给定的时刻内高比例地正常工作。然而对系统的挑战就越大,投入的成本也会越高。 比如 5 个 9 要求系统每年只宕机 5 分钟左右,而 4 个 9 要求每年宕机时间不超过一个小时。这就使得系统需要在设计、基础设施、数据备份等不同层面采取多种方式,甚至增加基础设施投资来保证可用性。

    不同系统的可用性要求也是不同的,比如:淘宝、京东等这些电商系统用户量很多,不同区不同时刻都有大量的用户在使用系统,这必然对系统的可用性要求很高。

    据以往这些系统的故障统计和不准确地测试数据推测,它们目前的可用性是在 3 个 9 到 4 个 9 左右。相对而言,企业类的工作软件因为通常只在工作时间被使用,或只在某些特定的地区使用,或只给某部分人某一特定时间使用,可用性的需求就会低一些。

     

    如何提高系统可用性

           提高系统的可用性有三方面:

    1. 错误检测用来检测故障的某种类型的健康监视;
    2. 自动恢复用来检测到故障时某种类型的恢复;
    3. 错误预防用来阻止错误演变为故障。

    错误检测包括三个战术,第一个是信号或者响应,采用组件主动询问方式,在一个系统或网站中即一个组件发出一个信号,并希望在预定义的时间内收到一个来自审查组件的响应,该战术可以用在共同负责某项任务的一组组件内。第二种方式监视组件采用被动方式,就好像我们给老师汇报阶段学习,在系统或网站中即一个组件定期发出一个心跳信息,另一个组件收听该信息。心跳还可用于传递数据。第三个是异常:异常处理程序通常将错误在语义上转换为可以被处理的形式,异常通常与引入异常的程序在同一个进程中。

    错误恢复就是回滚,回到之前的状态,分为六种战术,第一种是表决,运行在冗余处理器上的每个进程都具有相等的输入,它们计算的值都发给表决者,表决者发现异常则终止进程,该方法用于纠正算法的错误操作或处理器的故障,通常用在控制系统中。第二种是主动冗余:所有的备份的组件都以并行的方式对事件做出响应,它们的状态都相同,但每次只使用一个组件的响应而丢弃其余组件的响应;主动冗余通常用在客户机或服务器的配置中,在这种配置中,即使发生错误,也可在极短的时间,通常为几毫秒内恢复,比如门户网站采取的策略。第三种是被动冗余:主组件对事件做出响应,并通知其它备用组件必须进行的状态更新。第四种是备件:备件是计算平台配置用于更换各种不同的故障组件。出现故障时,必须将其重新启动为适当的软件配置,并对其状态进行初始化。第五种是Shadow操作:出现故障的组件可以以“Shadow模式”运行,这样可以在系统恢复前模仿工作组件的行为。第六种是状态再同步:主动和被动冗余战术要求所恢复的组件在重新提供服务前更新其状态。错误预防就是设置进程监听器,当一个事物出现错误时,从进程中删除事物。

    可用性的保障

    影响可用性的因素有很多,包括系统故障、基础设施故障、数据故障、安全攻击、系统压力等等。

    可用性的保障涉及到很多层面,其中包括但不限于了:

    • 软件的设计、编码、测试、上线和软件配置管理的水平

    • 工程师的人员技能水平

    • 运维的管理和技术水平

    • 数据中心的运营管理水平

    • 依赖于第三方服务的管理水平

    • 对待技术的态度

    • 一个公司的工程文化

    • 领导者对工程的尊重

    保障系统的高可用,并不是一个简单的事情,真正的保证高可用,还是需要大量实践的!

     

    展开全文
  • 提高系统可用性的那些架构策略

    千次阅读 2021-12-08 13:26:57
    系统高可用面临的挑战有哪些? 1.资源不可用 在实际业务中,出现资源不可用的原因种类可能很多,有的概率很低,比如网线被挖断了,机房失火,地震等等导致网络不可用,有的概率相对来说很高比如服务器硬件资源不足,服务器...

    系统高可用面临的挑战有哪些?

    1.资源不可用

    在实际业务中,出现资源不可用的原因种类可能很多,有的概率很低,比如网线被挖断了,机房失火,地震等等导致网络不可用,有的概率相对来说很高比如服务器硬件资源不足,服务器故障等等。这些问题都可能会导致对应的资源不可用。

    2.资源不均衡

    由于系统架构设计的时候没有针对高并发和大流量进行可伸缩设计,导致无法应对并发很大的场景,出现系统瘫痪甚至崩溃。

    3.节点功能异常

    这种情况是最常见的,由于代码是人写的,bug和漏洞都是难免的,所以在实际业务中大概率会出现功能节点异常的问题。同时系统引入的一些第三方库或者中间件当中也有可能包含一些问题,会导致节点功能异常。

    解决问题的思路和策略

    1.尽可能避免问题发生

    避免问题发生是最直接的解决思路,比如我们可以通过UPS(Uninterruptible Power System)来避免服务器断电。可以引入移动、电信两条网线,来避免由于运营商网络问题导致的服务器不可用。通过实现机房异地部署,防止由于地震等自然灾害导致的服务器不可用。增加冗余的机器,避免在特殊场景下资源不足的问题。

    2.发生问题之后能实现故障迁移

    通过实现服务和服务器的冗余部署,确保在某个节点出现问题之后,能够实现功能的平滑过渡,不会由于某个服务或者节点故障导致系统不可用。

    3.降低故障对业务的影响

    如果故障无法以正面的方式解决,我们就要努力降低故障带来的影响。流量太大的时候,我们可以通过限流,来保证部分用户可以正常使用,或者说通过对一些非核心业务进行降级处理,保证核心业务的可用性。

    4.发生故障之后能够实现快速恢复

    可以通过监控系统快速定位到故障节点,然后修复故障节点,使系统恢复到正常状态。

    高可用方案的架构原则和方案

    1.系统冗余无单点

    确保系统的各个服务节点都是有冗余的,当一个节点出现问题的时候能切换到备用节点,保障系统的可用性。保障网络的可用性,也可以引入多条线路(如接入移动和联通两条线路),一条线路出问题的时候切换到备用线路。很多直播软件为了保障运行,就会接入多条线路。数据库也可以通过主库和从库的设计,实现数据库的冗余,提升可靠性。对于一些对可用性要求高的软件,会实现机房的异地冗余部署,避免由于地震等自然灾害导致的服务不可用。

    2.支持水平扩展,可伸缩

    为了应对大流量和高并发的出现,系统的各个节点需要是可伸缩的,支持水平扩展。可以通过Ngnix,将请求和压力分流到多台机器上,实现硬件机器的扩展。同时可以在每台机器上运行更多的服务实例,应对海量请求。也可以引入CDN,将部分静态资源放到CDN上,降低服务端的带宽压力。

    3.系统可以进行降级操作

    在服务器资源不够用的时候,为了保障运行,通常采用的手段有降级、限流和熔断。

    降级: 比如双11的时候为了应对短时间内的高并发,淘宝就会暂时关闭部分非核心功能比如评论、返积分等来保障核心业务的正常运行。

    限流:我们也可以通过设置Ngnix的并发数,进行限流操作,保障部分用户的正常业务,拒绝其它的请求,防止由于短时间的高并发引起系统瘫痪。

    熔断: 当某个服务出现异常的时候,直接关闭该服务,在请求链路中绕过该服务,在后续服务正常之后再进行补偿操作。

    4.允许出现状态差异的中间态

    在高并发的场景下,很多时候为了提高系统可用性,会出现状态不一致的问题,比如修改状态保存到了缓存中而并没有落到数据库里,此时读取数据库的时候会出现状态不一致。系统应该允许出现暂时的状态不一致,只要能保证状态最终一致即可

    5.完善的系统监控体系

    完善的监控体系对于系统提前预警和问题排查定位以及修复问题之后的快速恢复都是很关键的。通过监控系统,我们可以实时诊断当前系统的运行状态怎么样。

    高可用架构的落地实践

    1.通过引入两条网络线路,一主一备保障网络的高可用

    2.负载均衡层进行双节点和Keepalived部署,当一个节点出问题的时候,切换到另一个节点上保障负载均衡的高可用。

    3.负载均衡层通过设置并发数进行限流设置。

    4.Web应用节点多节点部署,可根据需求进行伸缩扩展。同时负载均衡层通过路由切换对应的Web应用,当一个节点出问题的时候,快速切换到正常的节点上。

    5.后台业务服务是无状态的可以进行多节点部署,可以根据需要进行伸缩扩展。并且当某个节点出问题之后,可以进行熔断操作,在调用链路中绕过对应的节点。

    6.数据库通过读写分离分库分表,降低数据库的访问压力。

    7.通过对数据库进行主从配置,当主库出问题的时候,从库马上顶上,确保数据访问的高可用。

    展开全文
  • 百言不如一图,直接上图

    百言不如一图,直接上图

    展开全文
  • 提高系统可用性

    千次阅读 2018-09-26 22:02:09
    首先前解释一下什么是计算机网络,计算机网络是指将地理位置不同的具有独立功能的多台计算机及其外部设备,通过通信线路连接起来,在网络操作系统,网络管理软件及网络通信协议的管理和协调下,实现资源共享和信息...
  • 系统可用性SLA指标

    万次阅读 2019-06-11 16:11:25
    是在一定开销下为保障服务的性能和可用性。 网站服务可用性SLA,9越多代表全年服务可用时间越长服务更可靠,停机时间越短,反之亦然。 互联网公司喊口号,我们今年一定要做到3个9、4个9的含义 1年 = 365天 = 8760...
  • 系统可用性几个9

    万次阅读 2018-05-07 22:10:31
    经常看到各种技术文章或者分布式系统介绍说系统可用性达到了多少个9,那么所谓”几个9“到底是怎么计算的?又意味着什么?我们简单计算分析下看看。所谓”1个9“是指90%,”2个9“是指99%,”3个9“是指99.9%,...
  • 系统可用性分析方法与设计模板

    千次阅读 2017-09-29 23:41:49
    1、可用性管理任务的时间与方式 服务或组件的可用性和不可用性,及其度量方法 2、可用性管理的被动活动: 调查服务与组件的不可用性并探究修复活动(事件、故障、问题)监视、测量、分析、报告和审查组件和...
  • 系统可用性衡量指标MTTR|MTTF|MTBF

    万次阅读 2015-09-04 18:00:46
    MTTR、MTTF、MTBF是体现系统可靠的重要指标,但是三者容易混淆,下文使用图解方式解释三者之间的区别,希望能起到解惑的效用。 MTTF (Mean Time To Failure,平均无故障时间),指系统无故障运行的平均时间,取...
  • 分布式系统可用性与一致性

    千次阅读 2017-06-23 09:55:27
    可用性(Availability)和一致性(Consistency)是分布式系统的基本问题,先有著名的CAP理论定义过分布式环境下二者不可兼得的关系,又有神秘的Paxos协议号称是史上最简单的分布式系统一致性算法并获得图灵奖,再有...
  • 可用性:Availability,系统可以被使用的时间的描述,即uptime,计算方式: A = uptime/(uptime + downtime),其中uptime和downtime分别为可用/不可用时间。 我们经常形容的“几个九”,最多情况下指的就是系统.....
  • 可用性系统

    千次阅读 2016-05-18 16:15:51
    所谓高可用性指的是系统如何保证比较高的服务可用率,在出现故障时如何应对,包括及时发现、故障转移、尽快从故障中恢复等等。本文主要以点评的交易系统的演进为主来描述如何做到高可用,并结合了一些自己的经验。...
  • 你的系统可靠性和可用性是几个9?

    千次阅读 2018-12-27 08:42:00
    点击上方“Java后端技术”,选择“置顶或者星标”你关注的就是我关心的!作者:侯树成微信公众号:Tomcat那些事儿(ID:tomcat0000)我们在评估一个系统可用...
  • 一、什么是提升系统的高可用性 JAVA服务端,顾名思义就是23体验网为用户提供服务的。停工时间,就是不能向用户提供服务的时间。高可用,就是系统具有高度可用性,尽量减少停工时间。如何用最简单的方法来搭建一个高...
  • 系统可用性量表(SUS )

    千次阅读 2012-05-31 17:22:54
    SUS(Syestem Usability Scale)用来测量系统可用性,百分制来计算的分数,超过60分被认为是good usability。SUS可用来测量某个网站或者产品的可用性,尤其在竞争对手分析(competitive analysis)的时
  • 可用性量表很多(见下图),SUS只是其中一个。  SUS简介: 量表作者:John Brooke (DigitalEquipment Corporation, UK, 1986) 问卷组成:10个问题,在5点量表上打分 量表中文版以及计分方式:查看这里 ...
  • 一般来说,架构除了关注功能性需求外,其实更重要的是要关注非功能性需求,比如,性能,可用性,可伸缩性,可扩展性。而且一旦架构决定下来,一般难以改变,所以要求我架构师从一开始就要设计一个满足性能,可用性,...
  • 可用性和可靠性的区别

    千次阅读 2020-12-14 14:46:08
    可用性(availability):软件系统在投入使用时可操作和可访问的程度,或能实现其指定系统功能的概率。例如: QA2:系统可用性要达到98%。 实话说我一直想吐槽这个定义,说得未免太模糊了一点。尤其是可用性的...
  • 微信红包后台系统可用性设计实践

    千次阅读 2017-07-04 21:28:48
    微信红包业务量级的高速发展,对后台系统架构的可用性要求越来越高。在保障微信红包业务体验的前提下,红包后台系统进行了一系列高可用方面的优化设计。本次演讲介绍了微信红包后台系统的高可用实践经验,主要包括...
  • 计算机系统可用性用平均无故障时间( MTTF)来度量,即计算机系统平均能够正常运行多长时间,才发生一次故障。系统可用性越高,平均无故障时间越长。可维护性用平均维修时间(MTTR)来度量,即系统发生故障后维修和...
  • SAP 预留——可用性检查

    千次阅读 2020-03-18 14:46:39
    业务:创建预留时,系统会自动检测库存是否足够: MD04查询到物料库存为200PC: MB21建立预留: ...后台---物料管理---库存管理和实际库存--预留----设置动态可用性检查 由于预留是事...
  • 可用性及容灾的几个衡量指标

    千次阅读 2020-03-29 19:33:52
    网站可用性 所谓网站可用性(availability)也即网站正常运行时间的百分比,业界用 N 个9 来量化可用性, 最常说的就是类似 “4个9(也就是99.99%)” 的可用性。 容灾恢复能力的关键指标 RPO:(Recovery Point ...
  • 数据库可靠性/可用性、稳定性RTO/RPO

    千次阅读 2017-09-30 22:02:10
    所谓 RTO,Recovery Time Objective,它是指灾难发生后,从 IT 系统当机导致业务停顿之时开始,到 IT 系统恢复至可以支持各部门运作、恢复运营之时,此两点之间的时间段称为 RTO。所谓 RPO,Recovery Point ...
  • 美团扫码付的前端可用性保障实践

    千次阅读 2018-08-10 17:14:32
    2017年,美团金融前端遇到了很多通用性问题,特别是在保障前端可用性的过程中,我们团队也踩了不少“坑”,在梳理完这些问题以后,我们还专门做了第31期线下沙龙给大家进行了分享。不管是在面试过程中与候选人讨论,...
  • 软件测试可用性常用指标

    千次阅读 2018-07-16 21:20:19
    网站可用性 所谓网站可用性(availability)也即网站正常运行时间的百分比,业界用 N 个9 来量化可用性, 最常说的就是类似 “4个9(也就是99.99%)” 的可用性。 描述 通俗叫法 可用性级别 年度停机时间 ...
  • 我们组做的是知识树软件,在写需求说明书需求时我分配的任务是可靠性和可用性需求、出错处理需求这两个,所有本周作业我就大根据自己的理解以及书上的介绍说明一下我们组的软件的这两个需求: 可靠性和可用性需求...
  • 可用性的HDFS:Hadoop分布式文件系统深度实践

    千次下载 热门讨论 2013-11-29 13:52:13
    本书专注于Hadoop 分布式文件系统(HDFS)的主流HA 解决方案,内容包括:HDFS 元数据解析、Hadoop 元数据备份方案、Hadoop Backup Node 方案、AvatarNode 解决方案以及最新的HA 解决方案Cloudrea HA Name Node 等。...
  • 如何保障系统的高可用

    千次阅读 2018-02-10 23:53:24
    假设系统一直能够提供服务,我们说系统可用性是100%。如果系统每运行100个时间单位,会有1个时间单位无法提供服务,我们说系统可用性是99%。很多公司的高可用目标是4个9,也就是99.99%,这就意味着,系统的年...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,141,378
精华内容 456,551
关键字:

系统可用性