精华内容
下载资源
问答
  • 可用性 可用性是在某个考察时间,系统能够正常运行的概率或时间占有率期望值。 可靠性 可靠性一般产品可靠性,是元件、产品、系统在一定时间内、在一定条件下无故障地执行指定功能的能力或可能性。 光看定义比较...

    含义

    可用性

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

    可靠性

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

    如果某个系统在每小时崩溃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)数据服务器。需要在数据写入时进行数据同步复制,将数据写入多台服务器上,实现数据冗余备份;当数据服务器宕机时,应用程序将访问切换到有备份数据的服务器上。

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

    展开全文
  • 如何保证服务的高可用性 HA(High Availability)? 高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是,通过设计减少系统不能提供服务的时间。方法论上,高可用是通过冗余+自动...

    如何保证服务的高可用性 HA(High Availability)?

    高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。方法论上,高可用是通过冗余+自动故障转移来实现的。

    我们都知道,单点是系统高可用的大敌,单点往往是系统高可用最大的风险和敌人,应该尽量在系统设计的过程中避免单点。

    方法论上,高可用保证的原则是“集群化”,或者叫“冗余”:只有一个单点,挂了服务会受影响;如果有冗余备份,挂了还有其他backup能够顶上。

    保证系统高可用,架构设计的核心准则是:冗余。有了冗余之后,还不够,每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以,又往往是通过“自动故障转移”来实现系统的高可用。

    互联网架构中,通常是通过冗余+自动故障转移来保证系统的高可用特性。

    从实战经验来看如何保证服务的高可用性:

    一:服务架构层面
    (1)根据服务对象地区,考虑节点分布

    (2)避免服务单点,至少双机
    (3)防止代码之间干扰,避免稳定代码和迭代频繁代码放在一起,可以按照业务或者功能做服务分离。
    (4)防止服务之间干扰,重要服务最好做隔离,单独部署
    (5)防止数据库压力过大,不然,可能产生雪崩效应,可以根据业务特点做分库分表,加缓存等处理.
    (6)保证服务能力buffer, 尽量有冗余处理能力.

    二:运维层面
    (1)服务监控。比如磁盘、CPU、网络
    (2)监控多级别,到达不同级别给出不同警告

    三:代码层面
    (1)保证代码异常不会导致服务挂掉
    (2)保证服务是无状态的,可以支持水平扩展


    数据的水平扩展

    分层高可用架构实践

    常见互联网分布式架构如上,分为:

    (1)客户端层:典型调用方是浏览器browser或者手机应用APP
    (2)反向代理层:系统入口,反向代理
    (3)站点应用层:实现核心应用逻辑,返回html或者json
    (4)服务层:如果实现了服务化,就有这一层
    (5)数据-缓存层:缓存加速访问存储
    (6)数据-数据库层:数据库固化数据存储
    整个系统的高可用,又是通过每一层的冗余+自动故障转移来综合实现的。

    1. 客户端层->反向代理层的高可用

    客户端层到反向代理层的高可用,是通过反向代理层的冗余来实现的。以nginx为例:有两台nginx,一台对线上提供服务,另一台冗余以保证高可用,常见的实践是keepalived存活探测,相同virtual IP提供服务。

    自动故障转移:当nginx挂了的时候,keepalived能够探测到,会自动的进行故障转移,将流量自动迁移到shadow-nginx,由于使用的是相同的virtual IP,这个切换过程对调用方是透明的。

    2. 反向代理层->站点层的高可用

    反向代理层到站点层的高可用,是通过站点层的冗余来实现的。假设反向代理层是nginx,nginx.conf里能够配置多个web后端,并且nginx能够探测到多个后端的存活性。

    自动故障转移:当web-server挂了的时候,nginx能够探测到,会自动的进行故障转移,将流量自动迁移到其他的web-server,整个过程由nginx自动完成,对调用方是透明的。

    3. 站点层->服务层的高可用

    站点层到服务层的高可用,是通过服务层的冗余来实现的。“服务连接池”会建立与下游服务多个连接,每次请求会“随机”选取连接来访问下游服务。

    自动故障转移:当service挂了的时候,service-connection-pool能够探测到,会自动的进行故障转移,将流量自动迁移到其他的service,整个过程由连接池自动完成,对调用方是透明的(所以说RPC-client中的服务连接池是很重要的基础组件)。

    4. 服务层>缓存层的高可用

    服务层到缓存层的高可用,是通过缓存数据的冗余来实现的。 缓存层的数据冗余又有几种方式:第一种是利用客户端的封装,service对cache进行双读或者双写。

    缓存层也可以通过支持主从同步的缓存集群来解决缓存层的高可用问题。

    以redis为例,redis天然支持主从同步,redis官方也有sentinel哨兵机制,来做redis的存活性检测。

    自动故障转移:当redis主挂了的时候,sentinel能够探测到,会通知调用方访问新的redis,整个过程由sentinel和redis集群配合完成,对调用方是透明的。

    说完缓存的高可用,这里要多说一句,业务对缓存并不一定有“高可用”要求,更多的对缓存的使用场景,是用来“加速数据访问”:把一部分数据放到缓存里,如果缓存挂了或者缓存没有命中,是可以去后端的数据库中再取数据的。

    这类允许“cache miss”的业务场景,缓存架构的建议是:

    将kv缓存封装成服务集群,上游设置一个代理(代理可以用集群的方式保证高可用),代理的后端根据缓存访问的key水平切分成若干个实例,每个实例的访问并不做高可用。

    缓存实例挂了屏蔽:当有水平切分的实例挂掉时,代理层直接返回cache miss,此时缓存挂掉对调用方也是透明的。key水平切分实例减少,不建议做re-hash,这样容易引发缓存数据的不一致。

    5. 服务层>数据库层的高可用

    大部分互联网技术,数据库层都用了“主从同步,读写分离”架构,所以数据库层的高可用,又分为“读库高可用”与“写库高可用”两类。

    服务层>数据库层“读”的高可用

    服务层到数据库读的高可用,是通过读库的冗余来实现的。

    既然冗余了读库,一般来说就至少有2个从库,“数据库连接池”会建立与读库多个连接,每次请求会路由到这些读库。

    自动故障转移:当读库挂了的时候,db-connection-pool能够探测到,会自动的进行故障转移,将流量自动迁移到其他的读库,整个过程由连接池自动完成,对调用方是透明的(所以说DAO中的数据库连接池是很重要的基础组件)。

    服务层>数据库层“写”的高可用

    服务层到数据库写的高可用,是通过写库的冗余来实现的。

    以mysql为例,可以设置两个mysql双主同步,一台对线上提供服务,另一台冗余以保证高可用,常见的实践是keepalived存活探测,相同virtual IP提供服务。

    自动故障转移:

    当写库挂了的时候,keepalived能够探测到,会自动的进行故障转移,将流量自动迁移到shadow-db-master,由于使用的是相同的virtual IP,这个切换过程对调用方是透明的。

    小结:

    整个互联网分层系统架构的高可用,又是通过每一层的冗余+自动故障转移来综合实现的,具体的:

    (1)客户端层到反向代理层的高可用,是通过反向代理层的冗余实现的,常见实践是keepalived + virtual IP自动故障转移。
    (2)反向代理层到站点层的高可用,是通过站点层的冗余实现的,常见实践是nginx与web-server之间的存活性探测与自动故障转移。
    (3)站点层到服务层的高可用,是通过服务层的冗余实现的,常见实践是通过service-connection-pool来保证自动故障转移。
    (4)服务层到缓存层的高可用,是通过缓存数据的冗余实现的,常见实践是缓存客户端双读双写,或者利用缓存集群的主从数据同步与sentinel保活与自动故障转移;更多的业务场景,对缓存没有高可用要求,可以使用缓存服务化来对调用方屏蔽底层复杂性。
    (5)服务层到数据库“读”的高可用,是通过读库的冗余实现的,常见实践是通过db-connection-pool来保证自动故障转移。
    (6)服务层到数据库“写”的高可用,是通过写库的冗余实现的,常见实践是keepalived + virtual IP自动故障转移。

    SLA 是什么?

    SLA:服务等级协议(简称:SLA,全称:service level agreement)。是在一定开销下为保障服务的性能和可用性,服务提供商与用户间定义的一种双方认可的协定。通常这个开销是驱动提供服务质量的主要因素。

    SLA的定义来源百度,这到底是什么意思呢?

    我们平常经常看到互联网公司喊口号,我们今年一定要做到3个9、4个9,即99.9%、99.99%,甚至还有5个9,即99.999%。

    这么多9代表什么意思呢?

    首先,SLA的概念,对互联网公司来说就是网站服务可用性的一个保证。9越多代表全年服务可用时间越长服务更可靠,停机时间越短,反之亦然。

    这么多9是怎么计算的呢?

    全年拿365天做计算吧,看看几个9要停机多久时间做能才能达到!

    1年 = 365天 = 8760小时

    99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小时

    99.99 = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟

    99.999 = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟

    从以上看来,全年停机5.26分钟才能做到99.999%,即5个9。依此类推,要达到6个9及更多9,可说是非常难了吧。

    怎么做到更多的9?

    每个公司对几个9的定义都不一样,互联网公司至少都是99.99吧。像一些政府网站,如社保公积金等,经常故障服务不可用,能做到99.9就不错了。

    如果我们提供的服务可用性越低,意味着造成的损失也越大,别的不说,如果是特别重要的时刻,或许就在某一分钟,你可能就会因服务不可用而丢掉一笔大的订单,这都是始料未及的。所以,只要尽可能的提升SLA可用性才能最大化的提高企业生产力。

    要做到更多的9,就要不断的监控自己的服务,服务挂掉能及时恢复服务。就像开车出远门,首先得检查轮胎,同时还得准备一个备胎一样的道理。现在的产品和系统都非常的复杂,彼此连接依赖越来越复杂,为了整体的高速运转,对每个部件的稳定性越来越高,越来越精密,发展到一定程度,人力已经无法掌控,任何一个组件出异常都有可能牵一发而动全身,影响全局。每个部件的稳定性和精密程度决定了整体的工程质量,也决定了整体的发展速度。

    定义SLI

    SLI, Service Level Indicator 关键量化指标.

    SLI关注下面五点:
    要测量的指标是什么?

    测量时的系统状态?

    如何汇总处理测量的指标?

    测量指标能否准确描述服务质量?

    测量指标的可靠度(trust worthy)?

    SLO,Service-Level Objective 服务等级目标,指定了服务所提供功能的一种期望状态。

    一个有明确SLA的服务最理想的运行状态是: 增加额外资源来改进系统所带来的收益小于把该资源投给其他服务所带来的收益。

    一个简单的例子就是某服务可用性从99.9%提高到99.99%所需要的资源和带来的收益之比,是决定该服务是否应该提供4个9的重要依据。

    SLA的计算方式,是使用正常运行时间/(正常运行时间+故障时间),当指标为99.99的时候,每年的停机时间只有52.26分钟。。。停机时间又分为两种,一种是计划内停机时间,一种是计划外停机时间,而运维则主要关注计划外停机时间。

    在分布式系统中用时间指标来衡量系统的可用性,简直就是无效的。分布式系统中,部分可用的情况太多了,例如后端有两个rs,而一个rs坏了,那么就会有百分之五十的请求失败。这种情况SLA怎么来计算?扣时间还是不扣呢?

    在分布式系统中,一般使用请求的成功率来计算SLA,也就是

    SLA=请求成功/(请求成功+请求失败)

    在使用这种计算方式的时候,无论你是前端的web服务,还是后端的存储服务,还是离线服务,都是可以很好的计算。毕竟是一个可以量化的数据。在定义SLA的时候,顺便可以定义出监控的主要指标,例如请求的延迟,吞吐量等。

    在进行定义这些关键性指标的时候,也就是定义哪些请求成功,哪些请求失败,是有很大关系的,例如支付宝的核心功能是支付,如果支付功能可以,那么就满足了大多数的高可用,而所谓的其他的一些附加功能,例如城市服务,也影响不了多少人,当然, 也要看基数。

    在提供服务的时候,服务可以分为两种类型,一种类型是面对消费者的服务,一种是基础设施服务,例如微信就是面对消费者的服务,而各种云平台则是基础设施服务。

    当面对消费者服务的时候,一般会有对应的产品经理,那么可以由产品经理定义各种关键性的指标来衡量一个服务的可用性,例如微信在定义的时候,可以使用发送消息的成功率;消费者服务,可以参考竞争对手的可用性水平;免费的还是收费的;有没有替代产品可以使用。在这个时候,其实还可以定义服务降级,例如微信最常用的功能是发送消息和朋友圈,这两个服务的可用性可以定义为四个9,而对于所谓的摇一摇,附近等服务,可以定义低等级的可用性,例如两个9,这种构建方式,可以很大程度上节省成本,毕竟物理服务器冗余才是提高可用性的唯一方式。

    在消费者服务类型中,还需要注意每个请求的成败后果是不一样的,例如系统注册,或者是一个信息发送失败,系统注册失败,可能就不用这个系统了,而一个信息发送失败,用户可能认为是自己的网络有问题。。。

    在提供基础设施服务的时候,一般分为两个部分,一个部分是直接提供给用户使用的功能,例如提供VM访问服务;一个部分是平台的管控功能,例如云平台里面创建虚拟机,创建SLB等。这两个的失败是完全不一样的,用户的功能出了问题,那么就是故障了,但是管控服务出现问题,只要及时修好就行了,这种一般使用的评率很少,所以请求数量也不多。

    亚马逊的S3服务水平协议

    可用性保证(Service Commitment )

    保证“每月99.9%的正常运行时间”。S3 SLA保证一个月里所有以5分钟为单位的时间片中,平均有99.9%是可用的。SLA容许的最遭情况等于每月有40分钟不可用。

    服务补偿

    如果达不到SLA的承诺,Amazon会提供服务补偿,如果达不到 99.9%的服务水平,那么Amazon将减免下个月10%的费用。如果可用性下降到99.0%以下,换算后相当于一个月内至少有将近7个小时无法服务, 那么Amazon将减免25%的费用。

    假设一个用户存放了500G的数据。把500G数据放进S3并且在一个月内全部数据都使用10次的话,总共的费用大约是 $1000

    如果发生5小时的故障,那么该用户将得到 $100 的退款。如果故障时间从7个小时到一整个月的话, 该用户将得到 $250 的补偿。

    附:支付宝高可用性架构演进

    应用中间件技术架构应用:

    展现 SOFA-MVC (full stack)分布式 session安全框架 security SOFA-Mashup (component) A/B Test组件

    协调/调度中心 (scheduler)

    服务容器 组件集合(rule,jbpm,xts,cache,schedule) SOFA3 (SCA:bundle,service/reference,pub/sub,extension,sla) CloudEngine (servlet 3.0,drm,management,osgi) web Tomcat Datasource zds drm webservice jetty Apache/nginx (spdy,https)

    配置中心 (confreg2.0)

    应用中间件平台

    协调中心 (zdipper,zookeeper)

    分布式锁 (dlslock)

    JVM (JVMTI,JNI)

    超时调度中心 (timeout)

    参考资料

    https://blog.csdn.net/daiyudong2020/article/details/50550471
    https://blog.csdn.net/chdhust/article/details/74086776
    https://blog.csdn.net/tm6znf87mdg7bo/article/details/83663392
    https://blog.csdn.net/chenyong19870904/article/details/52986784
    https://wenku.baidu.com/view/444baa0ace2f0066f433221e.html


    Kotlin开发者社区

    专注分享 Java、 Kotlin、Spring/Spring Boot、MySQL、redis、neo4j、NoSQL、Android、JavaScript、React、Node、函数式编程、编程思想、"高可用,高性能,高实时"大型分布式系统架构设计主题。

    High availability, high performance, high real-time large-scale distributed system architecture design

    分布式框架:Zookeeper、分布式中间件框架等
    分布式存储:GridFS、FastDFS、TFS、MemCache、redis等
    分布式数据库:Cobar、tddl、Amoeba、Mycat
    云计算、大数据、AI算法
    虚拟化、云原生技术
    分布式计算框架:MapReduce、Hadoop、Storm、Flink等
    分布式通信机制:Dubbo、RPC调用、共享远程数据、消息队列等
    消息队列MQ:Kafka、MetaQ,RocketMQ
    怎样打造高可用系统:基于硬件、软件中间件、系统架构等一些典型方案的实现:HAProxy、基于Corosync+Pacemaker的高可用集群套件中间件系统
    Mycat架构分布式演进
    大数据Join背后的难题:数据、网络、内存和计算能力的矛盾和调和
    Java分布式系统中的高性能难题:AIO,NIO,Netty还是自己开发框架?
    高性能事件派发机制:线程池模型、Disruptor模型等等。。。

    合抱之木,生于毫末;九层之台,起于垒土;千里之行,始于足下。不积跬步,无以至千里;不积小流,无以成江河。

    展开全文
  • 可用性系统

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

    http://tech.meituan.com/high-availability-systems-dianping.html

    所谓高可用性指的是系统如何保证比较高的服务可用率,在出现故障时如何应对,包括及时发现、故障转移、尽快从故障中恢复等等。本文主要以点评的交易系统的演进为主来描述如何做到高可用,并结合了一些自己的经验。需要强调的是,高可用性只是一个结果,应该更多地关注迭代过程,关注业务发展。

    可用性的理解

    理解目标

    业界高可用的目标是几个9,对于每一个系统,要求是不一样的。研发人员对所设计或者开发的系统,要知道用户规模及使用场景,知道可用性的目标。
    比如,5个9的目标对应的是全年故障5分钟。

    result

    拆解目标

    几个9的目标比较抽象,需要对目标进行合理的分解,可以分解成如下两个子目标。

    频率要低:减少出故障的次数

    不出问题,一定是高可用的,但这是不可能的。系统越大、越复杂,只能尽量避免问题,通过系统设计、流程机制来减少出问题的概率。但如果经常出问题,后面恢复再快也是没有用的。

    时间要快:缩短故障的恢复时间

    故障出现时,不是解决或者定位到具体问题,而是快速恢复是第一要务的,防止次生灾害,问题扩大。这里就要求要站在业务角度思考,而不仅是技术角度思考。
    下面,我们就按这两个子目标来分别阐述。

    频率要低:减少出故障的次数

    设计:根据业务变化不断进行迭代

    以点评交易系统的演进过程为例。

    幼儿时期:2012年前

    使命:满足业务要求,快速上线。
    因为2011年要快速地把团购产品推向市场,临时从各个团队抽取的人才,大部分对.NET更熟悉,所以使用.NET进行了第一代的团购系统设计。毕竟满足业务要求是第一的,还没有机会遇到可用性等质量问题。考虑比较简单,即使都挂了,量也比较小,出现问题,重启、扩容、回滚就解决问题了。
    系统架构如下图所示。

    result

    少年时期:垂直拆分(2012-2013)

    使命:研发效率&故障隔离。

    当2012年在团单量从千到万量级变化,用户每日的下单量也到了万级时候,需要考虑的是迭代速度、研发效率。垂直拆分,有助于保持小而美的团队,研发效率才能更高。另外一方面也需要将各个业务相互隔离,比如商品首页的展示、商品详情页的展示,订单、支付流程的稳定性要求不一样。前面可以缓存,可以做静态化来保证可用性,提供一些柔性体验。后面支付系统做异地容灾,比如我们除了南汇机房支付系统,在宝山机房也部署了,只是后来发现这个系统演进太快,没有工具和机制保证双机房更新,所以后来也不好使用了。
    系统演进如下图所示。服务垂直化了,但是数据没有完整隔离开,服务之间还需要互相访问非自己的数据。

    result

    青年时期:服务做小,不共享数据(2014-2015)

    使命:支撑业务快速发展,提供高效、高可用的技术能力。

    从2013年开始,Deal-service (商品系统)偶尔会因为某一次大流量(大促或者常规活动)而挂掉,每几个月总有那么一次,基本上可用性就在3个9徘徊。这里订单和支付系统很稳定,因为流量在商品详情页到订单有一个转化率,流量大了详情页就挂了,订单也就没有流量了。后来详情页的静态化比较好了,能减少恢复的速度,能降级,但是Deal-service的各个系统依赖太深了,还是不能保证整体端到端的可用性。
    所以2014年对Deal-service做了很大的重构,大系统做小,把商品详情系统拆成了无数小服务,比如库存服务、价格服务、基础数据服务等等。这下商品详情页的问题解决了,后面压力就来了,订单系统的压力增大。2014年10月起,订单系统、支付系统也启动了全面微服务化,经过大约1年的实践,订单系统、促销系统、支付系统这3个领域后面的服务总和都快上百个了,后面对应的数据库20多个,这样能支撑到每日订单量百万级。
    业务的增长在应用服务层面是可以扩容的,但是最大的单点——数据库是集中式的,这个阶段我们主要是把应用的数据访问在读写上分离,数据库提供更多的从库来解决读的问题,但是写入仍然是最大的瓶颈(MySQL的读可以扩展,而写入QPS也就小2万)。
    这时系统演变成如下图所示。这个架构大约能支撑QPS 3000左右的订单量。

    result

    成年时期:水平拆分(2015至今)

    使命:系统要能支撑大规模的促销活动,订单系统能支撑每秒几万的QPS,每日上千万的订单量。

    2015年的917吃货节,流量最高峰,如果我们仍然是前面的技术架构,必然会挂掉。所以在917这个大促的前几个月,我们就在订单系统进行了架构升级和水平拆分,核心就是解决数据单点,把订单表拆分成了1024张表,分布在32个数据库,每个库32张表。这样在可见的未来都不用太担心了。
    虽然数据层的问题解决了,但是我们还是有些单点,比如我们用的消息队列、网络、机房等。举几个我过去曾经遇到的不容易碰到的可用性问题:
    服务的网卡有一个坏了,没有被监测到,后来发现另一个网卡也坏了,这样服务就挂了。
    我们使用 cache的时候发现可用性在高峰期非常低,后来发现这个cache服务器跟公司监控系统CAT服务器在一个机柜,高峰期的流量被CAT占了一大半,业务的网络流量不够了。
    917大促的时候我们对消息队列这个依赖的通道能力评估出现了偏差,也没有备份方案,所以造成了一小部分的延迟。
    这个时期系统演进为下图这样:

    result

    未来:思路仍然是大系统做小,基础通道做大,流量分块

    大系统做小,就是把复杂系统拆成单一职责系统,并从单机、主备、集群、异地等架构方向扩展。
    基础通道做大就是把基础通信框架、带宽等高速路做大。
    流量分块就是把用户流量按照某种模型拆分,让他们聚合在某一个服务集群完成,闭环解决。
    系统可能会演进为下图这样:

    result

    上面点评交易系统的发展几个阶段,只以业务系统的演进为例。除了这些还有CDN、DNS、网络、机房等各个时期遇到的不同的可用性问题,真实遇到过的就有:联通的网络挂了,需要切换到电信;数据库的电源被人踢掉了,等等。

    易运营

    高可用性的系统一定是可运营的。听到运营,大家更多想到的是产品运营,其实技术也有运营——线上的质量、流程的运营,比如,整个系统上线后,是否方便切换流量,是否方便开关,是否方便扩展。这里有几个基本要求:

    可限流

    线上的流量永远有想不到的情况,在这种情况下,系统的稳定吞吐能力就非常重要了,高并发的系统一般采取的策略是快速失败机制,比如系统QPS能支撑5000,但是1万的流量过来,我能保证持续的5000,其他5000我快速失败,这样很快1万的流量就被消化掉了。比如917的支付系统就是采取了流量限制,如果超过某一个流量峰值,我们就自动返回“请稍后再试”等。

    无状态

    应用系统要完全无状态,运维才能随便扩容、分配流量。

    降级能力

    降级能力是跟产品一起来看的,需要看降级后对用户体验的影响。简单的比如:提示语是什么。比如支付渠道,如果支付宝渠道挂了,我们挂了50% ,支付宝旁边会自动出现一个提示,表示这个渠道可能不稳定,但是可以点击;当支付宝渠道挂了100% ,我们的按钮变成灰色的,不能点击,但也会有提示,比如换其他支付渠道(刚刚微信支付还挂了,就又起作用了)。另一个案例,我们在917大促的时候对某些依赖方,比如诚信的校验,这种如果判断比较耗资源,又可控的情况下,可以通过开关直接关闭或者启用。

    result

    可测试

    无论架构多么完美,验证这一步必不可少,系统的可测试性就非常重要。
    测试的目的要先预估流量的大小,比如某次大促,要跟产品、运营讨论流量的来源、活动的力度,每一张页面的,每一个按钮的位置,都要进行较准确的预估。
    此外还要测试集群的能力。有很多同学在实施的时候总喜欢测试单台,然后水平放大,给一个结论,但这不是很准确,要分析所有的流量在系统间流转时候的比例。尤其对流量模型的测试(要注意高峰流量模型跟平常流量模型可能不一致)系统架构的容量测试,比如我们某一次大促的测试方法
    从上到下评估流量,从下至上评估能力:发现一次订单提交有20次数据库访问,读写比例高峰期是1:1,然后就跟进数据库的能力倒推系统应该放入的流量,然后做好前端的异步下单,让整个流量平缓地下放到数据库。

    result

    降低发布风险

    严格的发布流程

    目前点评的发布都是开发自己负责,通过平台自己完成的。上线的流程,发布的常规流程模板如下:

    result

    灰度机制

    服务器发布是分批的,按照10%、30%、50%、100%的发布,开发人员通过观察监控系统的曲线及系统的日志,确定业务是否正常。
    线上的流量灰度机制,重要功能上线能有按照某种流量灰度上线能力。
    可回滚是标配,最好有最坏情况的预案。

    时间要快:缩短故障的恢复时间

    如果目标就要保证全年不出故障或者出了故障在5分钟之内能解决,要对5分钟进行充分的使用。5分钟应该这样拆解:1分钟发现故障,3分钟定位故障出现在哪个服务,再加上后面的恢复时间。就是整个时间的分解,目前我们系统大致能做到前面2步,离整体5个9的目标还有差距,因为恢复的速度跟架构的设计,信息在开发、运维、DBA之间的沟通速度及工具能力,及处理问题人员的本身能力有关。
    生命值:

    result

    持续关注线上运行情况

    熟悉并感知系统变化,要快就要熟,熟能生巧,所以要关注线上运营情况。
    了解应用所在的网络、服务器性能、存储、数据库等系统指标。
    能监控应用的执行状态,熟悉应用自己的QPS、响应时间、可用性指标,并对依赖的上下游的流量情况同样熟悉。
    保证系统稳定吞吐
    系统如果能做好流量控制、容错,保证稳定的吞吐,能保证大部分场景的可用,也能很快地消化高峰流量,避免出现故障,产生流量的多次高峰。
    故障时

    快速的发现机制

    告警的移动化

    系统可用性的告警应该全部用微信、短信这种能保证找到人的通信机制。

    告警的实时化

    目前我们只能做到1分钟左右告警。

    监控的可视化

    我们系统目前的要求是1分钟发现故障,3分钟定位故障。这就需要做好监控的可视化,在所有关键service里面的方法层面打点,然后做成监控曲线,不然3分钟定位到具体是哪个地方出问题,比较困难。点评的监控系统CAT能很好的提供这些指标变化,我们系统在这些基础上也做了一些更实时的能力,比如订单系统QPS就是秒级的监控曲线。

    result

    有效的恢复机制

    比如运维的四板斧:回滚、重启、扩容、下服务器。在系统不是很复杂、流量不是很高的情况下,这能解决问题,但大流量的时候就很难了,所以要更多地从流量控制、降级体验方面下功夫。

    几点经验

    珍惜每次真实高峰流量,建立高峰期流量模型。

    因为平常的压力测试很难覆盖到各种情况,而线上的真实流量能如实地反映出系统的瓶颈,能较真实地评估出应用、数据库等在高峰期的表现。

    珍惜每次线上故障复盘,上一层楼看问题,下一层楼解决问题。

    线上出问题后,要有一套方法论来分析,比如常见的“5W”,连续多问几个为什么,然后系统思考解决方案,再逐渐落地。

    可用性不只是技术问题。

    系统初期:以开发为主;
    系统中期:开发+DBA+运维为主;
    系统后期:技术+产品+运维+DBA。
    系统较简单、量较小时,开发同学能比较容易地定位问题并较容易解决问题。
    当系统进入较复杂的中期时,就需要跟运维、数据库的同学一起来看系统的瓶颈。
    当系统进入复杂的后期时,系统在任何时候都要考虑不可用的时候如何提供柔性体验,这就需要从产品角度来思考。

    单点和发布是可用性最大的敌人。

    可用性要解决的核心问题就是单点,比如常见的手段:垂直拆分、水平拆分、灰度发布;单机到主备、集群、异地容灾等等。
    另外,系统发布也是引起系统故障的关键点,比如常见的系统发布、数据库维护等其他引起系统结构变化的操作。


    展开全文
  • 什么是可用性测试?

    千次阅读 2007-05-30 19:29:00
     可用性(Usability)是交互式IT产品/系统的重要质量指标,的是产品对用户来说有效、易学、高效、好记、少错和令人满意的程度,即用户能否用产品完成他的任务,效率如何,主观感受怎样,实际上是从用户角度所看到...
    1. 什么是可用性?
        可用性(Usability)是交互式IT产品/系统的重要质量指标,指的是产品对用户来说有效、易学、高效、好记、少错和令人满意的程度,即用户能否用产品完成他的任务,效率如何,主观感受怎样,实际上是从用户角度所看到的产品质量,是产品竞争力的核心。
        ISO 9241-11国际标准对可用性作了如下定义:产品在特定使用环境下为特定用户用于特定用途时所具有的有效性(effectiveness)、效率(efficiency)和用户主观满意度(satisfaction)。其中:
        有效性 -用户完成特定任务和达到特定目标时所具有的正确和完整程度;
        效率 -用户完成任务的正确和完整程度与所使用资源(如时间)之间的比率;
        满意度 -用户在使用产品过程中所感受到的主观满意和接受程度。

    2. 怎么获得可用性?
    可以参考以下原则:Gould、Boies 和 Lewis (1991) 为以用户为中心的设计定义了 4 个重要的原则:
    • 及早以用户为中心:设计人员应当在设计过程的早期就致力于了解用户的需要。
    • 综合设计:设计的所有方面应当齐头并进的发展,而不是顺次发展。使产品的内部设计与用户界面的需要始终保持一致。
    • 及早并持续性地进行测试:当前对软件测试的唯一可行的方法是根据经验总结出的方法,即若实际用户认为设计是可行的,它就是可行的。通过在开发的全过程引入可用性测试,可以使用户有机会在产品推出之前就设计提供反馈意见。
    • 反复式设计:大问题往往会掩盖小问题的存在。设计人员和开发人员应当在整个测试过程中反复对设计进行修改。

    3.. 什么是可用性测试?

    可用性测试是依照可用性标准对GUI的系统评估。

    可用性测试是用户在和系统(网站,软件应用程序,移动技术或任何用户操作的设备)交互时对用户体验质量的度量。

    4. 如何去做可用性测试?

    l         实验室实验

    在一个受控地环境下执行测试。用户被引入系统并且要求根据预先设置地场景执行几个关键的任务。

    可用性测试可能在一个真实的系统上执行,在一个书面的原型,或是一个演示(例如,PowerPoint),它们只展示被测试系统中的元素.

    用户的活动使用两个摄像机录制下来-一个录制屏幕上的活动,一个录制用户的反应和表情。另外,可用性专家监视可用性测试,记录感兴趣的任何项目。

     

    l         现场观察

    实验室实验相似,只不过在现场执行。它通常在系统或环境很复杂以致于很难在实验室中复制的情况下操作。现场观察可能也被用于研究在真实环境下的用户表现.

    现场观察使研究工作在他们典型工作环境系统的用户变为可能

    这种类型测试的好处使它给与用户较小正式感觉关于测试,并且使一个相关长的观察期间变得可能。非正式的设置帮助从一个真实的环境中收集信息,不仅仅从现有的场景中。

     

    l         问卷表

    用于接收随着系统的使用来自用户的详细反馈。这种信息是主观的,并且给与一个良好的关于用户如何使用系统的指引。

    可以使用一个在线的问卷或书面的表格.

    问卷表的最主要的好处是反馈是基于用户主观使用系统的经历。它所认识到的有用性和可用性。有可能量化这个反馈并且使用具体的数据提交报告,例如“40%的用户给新的Intranet打分为8分或8分以上”.

     

    l         启发式评估

    一个用户界面的系统评估通常由一个以上的可用性专家根据已知的标准(启发法)执行.

    启发式评估的主要好处是, 它允许在相对早的时候发现严重的问题。启发式评估最好在结束版本之前和在其他类型实用性测试之前执行.

    转自:卖烧烤的鱼博客

    展开全文
  • 可用性和可靠性区别

    千次阅读 2016-08-18 11:34:41
    可用性:讲究失败时间/总时间,失败次数/总次数 可靠性:用启动后遇到第一次失败的时间衡量,越久越好. 一般提高可靠性的同时,也同时提高了可用性。     可靠性和可用性是我们常见的IT系统衡量...
  • 前端可用性保障实践

    千次阅读 2017-08-10 19:56:00
    一般可用性都是说后端服务的可用性,都说我们的服务可用性到了几个9,很少有人把可用性放到前端来。其实对于任何一个有UI交互流程的业务,都会有前端服务可用性,后端的可用性做的再高,前端一个按钮写的有问题点击...
  • 可用性研究

    千次阅读 2012-07-27 10:52:30
    可用性分类(Availability Taxonomy)   A:Faults, Failures and Outages   错误(Faults):从概念上说,一个错误可以描述为一个系统中不期望发生的行为,可以分为可再现和不可再现两类。Conceptually, a fault...
  • 软件测试可用性常用指标

    千次阅读 2018-07-16 21:20:19
    网站可用性 所谓网站可用性(availability)也即网站正常运行时间的百分比,业界用 N 个9 来量化可用性, 最常说的就是类似 “4个9(也就是99.99%)” 的可用性。 描述 通俗叫法 可用性级别 年度停机时间 ...
  • 提高系统可用性

    千次阅读 2018-09-26 22:02:09
    计算机网络是将地理位置不同的具有独立功能的多台计算机及其外部设备,通过通信线路连接起来,在网络操作系统,网络管理软件及网络通信协议的管理和协调下,实现资源共享和信息传递的计算机系统。 计算机网络也...
  • 提高应用程序可用性的五个要点

    千次阅读 2017-06-29 13:41:14
    可用性问题通常会在你最想不到的地方出现,许多问题都是系统性的问题,而不仅仅是代码的问题。本文提出了五个要点能够帮助你的系统在规模增长的同时保证高可用性。 如您对可用性不是很了解,试试在微信后台回复...
  • 对于单机系统和集中系统是...1.单机系统的可用性和一致性(ACID)对于单机系统最主要的指标就是数据的一致性和可用性。其可以用ACID来度量一个系统的可用性和一致性。 Atomicity原子性:一个事务中所有操作都必须全部
  • 可用性及容灾的几个衡量指标

    万次阅读 2014-04-09 14:59:07
    网站可用性所谓网站可用性(availability)也即网站正常运行时间的百分比,业界用 N 个9 来量化可用性, 最常说的就是类似 “4个9(也就是99.99%)” 的可用性。描述通俗叫法可用性级别年度停机时间基本可用性2个999%...
  • 防火墙高可用性(HA)

    千次阅读 2019-04-11 15:56:28
    防火墙高可用性也称双机热备,基于两台设备的高可用性。双机热备的模式分为主备模式和主主模式。 主备模式 主-备方式即的是一台设备处于某种业务的激活状态(即Active状态),另一台设备处于该业务的备用状态...
  • 网站可用性测试设计

    千次阅读 2014-06-28 15:11:38
    大多网站设计开发者面临着要在尽可能短的时间内发布网站的压力,这种紧迫性的结果往往是忽略了网站整体功能性和可用性,导致用户满意度、忠诚度降低,设置流失,给今后的网站维护和改进增加了更多难度。用户的真实...
  • 架构要素-高可用性

    千次阅读 2014-07-31 16:26:39
    可用性---万无一失实现高可用架构的主要手段是数据和服务的冗余备份及失效转移。高可用的应用: 应用层主要处理网站应用的业务逻辑,因此也称业务逻辑层,应用的一个显著特点是应用的无状态。所谓无状态的应用是...
  • RocketMQ-----怎么保证MQ的高可用性

    千次阅读 2019-08-05 16:04:41
    目录推荐公众号前言正文怎么保证MQ的高可用性?什么是高可用MQ高可用建议 推荐公众号 前言 之前说了怎么搭建多master多slave模式,今天公司发布的时候忽然思考,现在公司的服务都是水平+垂直拆分,为什么这样做呢,...
  • 常用的可用性工程方法

    千次阅读 2014-01-10 17:35:37
    可用性工程包括了一整套以提高和评估产品可用性质量为目的、以用户为中心的实用工程方法,分别运用于产品生命周期的不同阶段。它的基本宗旨是强调在产品开发过程中要紧紧围绕用户这个出发点,要有用户的积极参与,...
  • 可用性解决方案概述http://mssqlmct.blog.51cto.com/9951484/164102811.1 高可用性解决方案概述11.1.1 可用性 可用性在某个考察时段内,系统能够正常运行的概率或者时间占有率的期望值。。通常用以下公式...
  •  可用性特定的用户在特定的环境下使用产品并达到特定目标的效力、效率和满意的程度。 可用性五个方面:  有效性(effective):怎样准确、完整地完成工作或达到目标  效率 (efficient):怎样快速地完成工作 ...
  • 一、HAWQ高可用简介 HAWQ作为一个传统数仓在Hadoop上的替代品,其高可用性至关重要。通常硬件容错、HAWQ HA、HDFS HA是保持系统高可用时需要考虑并实施的三个层次。另外实时监控和定期维护,也是保证集群所有组件...
  • 软件设计中的可用性

    千次阅读 2005-12-07 18:17:00
    软件设计中的可用性Microsoft Corporation 2000年10月摘要:本文介绍了可用性的概念,说明为什么可用性应当是所有软件设计项目中的一个重要部分。目录 简介 可用性定义 常见问题 资源 简介 在工作中体现可用性 在...
  • 所谓高可用性指的是系统如何保证比较高的服务可用率,在出现故障时如何应对,包括及时发现、故障转移、尽快从故障中恢复等等。本文主要以点评的交易系统的演进为主来描述如何做到高可用,并结合了一些自己的经验。...
  • 内存的可靠性、可用性和诊断功能(内存RAS) RAS - Reliability, Availability and Serviceability Reliability:可靠性。的是系统必须尽可能的可靠,不会意外的崩溃,重启甚至导致系统物理损坏,这意味着一个...
  • 网站可用性所谓网站可用性(availability)也即网站正常运行时间的百分比,业界用 N 个9 来量化可用性, 最常说的就是类似 “4个9(也就是99.99%)” 的可用性。 描述 通俗叫法 可用性级别 年度停机时间 基本可用性 2...
  • 读书笔记:网站架构之可用性

    千次阅读 2013-12-09 21:32:41
    一、高可用的网站架构 二、高可用的应用 三、高可用的服务 四、高可用的数据 五、网站的软件质量保证和运行监控 PS:本文为《大型网站技术架构 & 核心原理与案例分析(李智慧 著)》一书的读书笔记
  • 某一个请求从发出到接收到响应消耗的时间。 在对响应时间进行测试时,通常采用重复请求方式,然后计算平均响应时间。 2. 吞吐量/吞吐率 系统在单位时间内可以处理的请求数量,通常使用每秒的请求数来衡量。 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 332,096
精华内容 132,838
关键字:

信息的可用性是指