精华内容
下载资源
问答
  • 10 网站可用性的度量与考核

    千次阅读 2021-05-08 14:55:45
    这一故障导致美国许多使用亚马逊云服务的知名网站(如:Foursquare, Quora )受 到影响,并引发了人们对使用云计算安全、可靠的大规模讨论。 2010年1月12日,百度被黑客攻击,其DNS域名被劫持,导致百度全站长达数...

    在这里插入图片描述

    2011年4月12 B ,亚马逊云计算服务EC2 ( Elastic Computer Cloud )发生故障,其 ESB ( Elastic Block Storage )服务不可用,故障持续了数天,最终还是有部分数据未能恢 复。这一故障导致美国许多使用亚马逊云服务的知名网站(如:Foursquare, Quora )受 到影响,并引发了人们对使用云计算安全性、可靠性的大规模讨论。

    2010年1月12日,百度被黑客攻击,其DNS域名被劫持,导致百度全站长达数小
    时不可访问。该事件一时成为新闻焦点,各种媒体争相报道。

    网站的可用性(Availability )描述网站可有效访问的特性(不同于另一个网站运营指 标:Usability,通常也被译作可用性,但是后者强调的是网站的有用性,即对最终用户的 使用价值),相比于网站的其他非功能特性,网站的可用性更牵动人们的神经,大型网站 的不可用事故直接影响公司形象和利益,许多互联网公司都将网站可用性列入工程师的 绩效考核,与奖金升迁等利益挂钩。

    网站的页面能完整呈现在最终用户面前,需要经过很多个环节,任何一个环节出了 问题,都可能导致网站页面不可访问。DNS会被劫持、CDN服务可能会挂掉、网站服务器可能会宕机、网络交换机可能会失效、硬盘会损坏、网卡会松掉、甚至机房会停电、 空调会失灵、程序会有Bug、黑客会攻击、促销会引来大量访问、第三方合作伙伴的服务 会不可用……要保证一个网站永远完全可用几乎是一件不可能完成的使命。


    1 网站可用性度量

    网站不可用也被称作网站故障,业界通常用多少个9来衡量网站的可用性,如QQ的
    可用性是4个9,即QQ服务99.99%可用,这意味着QQ服务要保证其在所有运行时间中, 只有0.01%的时间不可用,也就是一年中大约最多53分钟不可用。

    网站不可用时间(故障时间)=故障修复时间点-故障发现(报告)时间点

    网站年度可用性指标=(1-网站不可用时间/年度总时间)xl00%

    对于大多数网站而言,2个9是基本可用,网站年度不可用时间小于88小时;3个9 是较高可用,网站年度不可用时间小于9小时;4个9是具有自动恢复能力的高可用,网 站年度不可用时间小于53分钟;5个9是极高可用性,网站年度不可用时间小于5分钟。

    由于可用性影响因素很多,对于网站整体而言,达到4个9,乃至5个9的可用性, 除了过硬的技术、大量的设备资金投入和工程师的责任心,还要有个好运气。

    常使用Twitter的用户或多或少遇到过那个著名的服务不可用的鲸鱼页面,事实上, Twitter网站的可用性不足2个9。


    2 网站可用性考核

    可用性指标是网站架构设计的重要指标,对外是服务承诺,对内是考核指标。从管 理层面,可用性指标是网站或者产品的整体考核指标,具体到每个工程师的考核,更多 的是使用故障分。
    所谓故障分是指对网站故障进行分类加权计算故障责任的方法。表5.1为某网站故障分类权重表。
    在这里插入图片描述

    故障分的计算公式为:
    故障分=故障时间(分钟)x故障权重

    在年初或者考核季度的开始,会根据网站产品的可用性指标计算总的故障分,然后 根据团队和个人的职责角色分摊故障分,这个可用性指标和故障分是管理预期。在实际 发生故障的时候,根据故障分类和责任划分将故障产生的故障分分配给责任者承担。等 年末或者考核季度末的时候,个人及团队实际承担的故障分如果超过了年初分摊的故障 分,绩效考核就会受到影响。

    一个简化的故障处理流程如图5.1所示。

    在这里插入图片描述

    有时候一个故障责任可能由多个部门或团队来承担,故障分也会相应按责任分摊到 不同的团队和个人。

    不同于其他架构指标,网站可用性更加看得见摸得着,跟技术、运营、相关各方的 绩效考核息息相关,因此在架构设计与评审会议上,关于系统可用性的讨论与争执总是 最花费时间与精力的部分。

    当然,不同的公司有不同的企业文化和市场策略,这些因素也会影响到系统可用性 的架构决策,崇尚创新和风险的企业会对可用性要求稍低一些;业务快速增长的网站忙 于应对指数级增长的用户,也会降低可用性的标准;服务于收费用户的网站则会比服务 于免费用户的网站对可用性更加敏感,服务不可用或关键用户数据丢失可能会导致收费 用户的投诉甚至引来官司。

    展开全文
  • 5.1 网站可用性的度量与考核 5.1.1 网站可用性度量 网站不可用时间(故障时间)=故障修复时间-故障发现(报告)时间点 网站年度可用性指标=(1-网站不可用时间/年度总时间)x100% 2个9是基本可用,网站年度不...

    5.1 网站可用性的度量与考核

     

    5.1.1 网站可用性度量

    网站不可用时间(故障时间)=故障修复时间-故障发现(报告)时间点

     

    网站年度可用性指标=(1-网站不可用时间/年度总时间)x100%

     

    2个9是基本可用,网站年度不可用时间小于88小时;

    3个9是较高可用,网站年度不可用时间小于9小时;

    4个9是具有自动恢复能力的高可用,网站年度不可用时间小于53分钟;

    5个9是极度高可用,网站年度不可用时间小于5分钟。

     

    由于可用性影响因素很多,对于网站整体而言,达到4个9,乃至5个9的可用性,除了过硬的技术、大量的设备资金投入和工程师的责任心,还要有个好运气。

     

    5.1.2 网站可用性考核

    网站可用性,跟技术、运营、相关各方的绩效考核息息相关,因此在架构设计与评审会议上,关于系统可用性的讨论与争执总是最花时间与精力的部分。

     

    当然不同的公司有不同的企业文化和市场策略,这些因素也会影响到系统可用性的架构决策,崇尚创新和风险的企业会对可用性要求稍低一些;

    业务增长快速的网站忙于应对指数级增长的用户,也会降低可用性标准;

    服务于收费用户的网站则会比服务于免费用户的网站对可用性更加敏感。

     

    5.2 高可用网站架构

    高强度频繁读写会导致硬件故障。高可用架构设计的目的就是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问。

     

    实现高可用的主要手段是数据和服务的冗余备份和失效转移,一旦某些服务器宕机,就将服务切换到其他可用的服务器上,如果磁盘损坏,则从备份的磁盘读取数据。

     

    三层分层架构

    不同业务产品属于应用层

    不同产品依赖的一些共同的复用的业务,如注册登录服务、Session管理服务、账户管理服务等,属于服务层

    数据层:数据库、文件服务、缓存服务、搜索服务

     

    应用层高可用:

    通过负载均衡技术,将一组服务器组成一个集群共同对外提供服务,当负载均衡设备通过心跳检测手段监控到某台应用服务器不可用时,就将其从集群列表中剔除,并将请求分发到集群中其他可用的服务器上,使整个集群保持可用,从而实现应用高可用。

     

    服务层高可用:

    通过集群实现高可用,这些服务器被应用层通过分布式服务调用框架访问,分布式服务调用框架会在应用层客户端中实现软件负载均衡,并通过服务注册中心对提供的服务器进行心跳检测,发现有服务不可用,立即通知客户端程序修改服务访问列表,剔除不可用的服务器。

     

    数据层高可用:

    数据层高可用一般会热备,在数据写入时进行数据同步复制,将数据写入多台服务器上,实现数据冗余备份。当服务器宕机时,应用程序将访问切换到有备份数据的服务器上。

     

    上面是应对硬件故障的可用性措施,除了这些,还要应对发布升级引起的宕机,因为发布越频繁,发布的内容越多,越复杂,更容易出故障。

     

    需要通过发布自动化将认为发布引起的故障降到最小。

     

    转载于:https://www.cnblogs.com/wozixiaoyao/p/11494487.html

    展开全文
  • 前言 上节我们讲了网站核心要素之性能,这节我们接着讲第二个核心要素可用性,网站的可用性,描述的是一个网站是否可以...网站可用性的度量与考核 网站可用性度量:网站不可用又称为网站故障,通常用多少个9来衡.

    前言

    上节我们讲了网站核心要素之性能,这节我们接着讲第二个核心要素可用性,网站的可用性,描述的是一个网站是否可以正常使用的特性,这个特性是比较关键的,直接影响公司形象和利益,因此也有很多大公司把这点作为技术人员的绩效考核之一。既然那么重要,那么我们就好好的谈一谈如何构建一个高性能网站架构,我们将从如下几个大方面展开讨论:度量与考核网站架构高可用应用高可用服务高可用数据高可用软件质量保证运行监控

     

    网站可用性的度量与考核

    • 网站可用性度量:网站不可用又称为网站故障,通常用多少个9来衡量,对于大多数网站来说,2个9是基本可用(网站年度不可用时间小于88小时),3个9是较高可用(小于9个小时),4个9是具有自动恢复能力的高可用(小于53分钟),5个9就是极高可用性(小于5分钟)。

      网站不可用时间(故障时间)=故障修复时间点-故障发现(报告)时间点

      网站年度可用性指标=(1-网站不可用时间、年度总时间)*100%

    • 网站可用性考核:可用性指标是网站架构设计的重要指标,对外是服务承诺,对内是考核指标,从管理层面上来说可用性指标是网站或者产品的整体考核指标;从每个工程师层面来说,考核更多的是只是故障分。

      故障分是指对网站故障进行分类加权计算故障责任的方法,一般分类权重如下,故障分的计算公式:故障分=故障时间(分钟)*故障权重

      简化版故障处理流程如下:

       

      有时候一个故障可能由多个部门或团队来承担,故障分也会相应按责任分摊到不同的团队和个人。

     

    高可用的网站架构

    • 高可用架构设计目的:为了保证当服务器硬件故障时,服务依然可用、数据依然保存并能够被访问;

    • 高可用架构实现手段:主要手段是数据和服务的冗余备份及失效转移,一旦某些服务器宕机,就将服务切换到其他可用的服务器上,如果磁盘损坏,则从备份的磁盘中读取数据。

      一个典型的网站设计一般遵循基本的分层架构模型:应用层-服务层-数据层,各层之间具有相对的独立性。应用层主要负责业务逻辑处理;服务层负责提供可复用的服务;数据层负责数据的存储与访问。不同规模网站架构分层部署也不同,下面分别看下中型和大型网站分层部署,如下图所示:

       

       

       

      应用层:通常为了应对高并发的访问请求,会通过负载均衡器将一组服务器组成一个集群共同对外提供服务,当负载均衡器通过心跳检测等手段监控到某台应用服务器不可用时,就将其从集群中剔除,并将请求分发到集群中其他可用的服务器上,使整个集群保持可用,从而实现应用高可用;

      服务层:服务层和应用层差不多,也是通过集群方式实现高可用,只是这些服务器被应用层通过分布式服务调用框架访问,分布式服务调用框架会在应用层客户端程序中实现软件负载均衡,并通过服务注册中心对提供服务的服务器进行心跳检测,发现有服务不可用时,立即通知客户端程序修改访问列表,剔除不可用的服务器;

      数据层:数据层的服务器比较特殊,上面存储着数据,为了保证服务器宕机时数据不丢失,数据访问服务不中断,需要在数据写入时进行数据同步复制,将数据写入多台服务器,实现数据冗余备份。当数据服务器宕机时,应用程序将访问切换到有备份数据的服务器上;

    • 网站高可用设计时,除了考虑实际的硬件故障引起的宕机,还要考虑网站升级发布所引起的宕机;

     

    高可用的应用

        应用层主要处理网站应用的业务逻辑,因此也成为业务逻辑层,应用的一个现住特点是应用无状态,所谓的无状态是指应用服务器不保存业务的上下文信息,而仅仅根据每次请求提交的数据进行相应的业务逻辑处理,多个服务器之间完全对等,请求提交到任何一个服务器,处理的结果都是一样的。

    什么是负载均衡:实现服务器可用状态实时监测,自动转移失任务的机制叫负载均衡,主要是使用在业务量和数据量较高的情况下,当单台服务器不足以承担所有的负载压力时,通过引入负载均衡器,将流量和数据分摊到一个集群组成的多台服务器上,以提高整体的负载能力,在网站应用中,当集群中的服务都是无状态对等时,负载均衡可以起到高可用的作用,如下图:

    当web服务器集群中的服务都是可用时,负载均衡器会把请求分发到任意一台服务器上处理,而当服务器139.19.0.1发生宕机时,负载均衡器通过心跳检测机制发现该服务器失去响应,就会把它从服务器列表中剔除,而将请求发送到其他服务器上,这些服务都是对等的,所以处理的结果都是一样的。

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

    • 应用服务器集群的session集中式管理

      应用服务器的高可用架构是基于服务无状态设计的,但是实际我们的业务总是有状态的,例如我们需要记录用户的当前登录状态;

      web应用中将多次请求修改使用的上下文对象称为会话(session),单机情况下,session可以由部署在服务器上的web容器管理如tomcat,在使用负载均衡的集群环境下,由于负载均衡器会将请求随机分发到集群中某一台服务器上,所以要保证每次请求依然获取正确的session是比较复杂的,主要从以下几个方面入手:

      • Session复制:应用服务器开启web容器的session复制功能,在集群中的几台服务器之间同步session对象,使得每台服务器上都保存所有用户的session信息,这样任何一台服务器宕机都不会导致session丢失,而服务器使用session时只需要在本机上直接获取即可,如下图:

        这种方案虽然简单,服务器从本地获取session也很快速,但是这种只适合在集群规模比较小的情况下,当集群规模比较大时,集群服务器间需要大量的通信进行session复制,这是极大的占用服务器资源,系统将是承受不起的,而且由于所有的用户的session信息在每台服务器上都有备份,在大量用户访问的情况下,甚至会出现服务器内存不够session存储的情况,对于大型网站架构而言,集群服务器成千上万,因此这种方案不适合大型网站。

      • Session绑定:利用负载均衡的源地址Hash算法实现,负载均衡器总是将来自同一个IP的请求分发给同一台服务器(如果你是通过HTTP协议走请求,也可以通过cookie信息将同一个用户的请求分发到同一台服务器),这样在整个会话期间,同一个用户所有的请求都在同一个服务器上被处理,即每个用户的session绑定在某台特定的服务器上,保证该用户session就从该服务器上获取即可,这种方法又称为会话黏滞

        session绑定的方案显然不符合我们对系统高可用的需求,当一台服务器宕机时,我们就失去了该台服务器所有用户的session信息,用户请求切换到其他服务器时,显然因为获取不到session而业务处理失败,因此很少有网站会用这种方式去进行session管理。

      • 利用cookie记录session:将session记录在客户端,每次请求服务器的时候,将session放在请求中发送给服务器,服务器处理完请求之后再将新的session返回给客户端,网站的客户端就是浏览器,所以我们可以利用浏览器的cookie记录session,cookie简单易用,可用性高,支持应用服务器的线性伸缩,示例见下图:

        利用cookie记录session也存在一些缺陷:

        • 受cookie大小的限制,能记录的session有限

        • 每次请求都需要传输cookie,影响性能

        • 依赖cookie,如果用户禁用了cookie,那就完全没法玩了

      • session服务器:前面所说的方案或多或少都有些不足,那么有没有可用性高、伸缩性好、性能也不错、对session大小也没有限制的解决方案呢?答案就是session服务器。利用独立部署的session服务器(集群)统一管理session,应用服务器每次读写session时都访问session服务器,如下图所示:

        这种解决方案本质上是将应用服务器状态分离,分为无状态的应用服务器和有状态的session服务器,然后针对这2种分别设计架构。

        有状态的session服务器,一般采用分布式缓存、数据库等方案,但是如果网站业务场景对session管理有较高的要求,那么最好还是需要开发一个专门的session服务管理平台。

         

    高可用的服务

    可复用的服务模块为业务产品提供公共服务,大型网站中这些服务通常都独立分布式部署,被远程应用调用,可复用的服务和应用一样,也是无状态的服务,因此使用类似负载均衡的失效转移策略也可以实现高可用的服务,此外还有以下几种高可用服务策略:

    • 分级管理:运维将服务器进行分级管理,核心应用和服务优先使用更好的硬件;同时在服务部署上也进行必要的隔离,避免故障的连锁反应。低优先级的服务通过启动不同的线程或者部署在不同的虚拟机上进行隔离,而高优先级的服务则需要部署在不同的物理机上,核心服务和数据甚至需要部署在不同地域的数据中心;

    • 超时设置:由于服务器宕机、线程死锁等原因,可能会导致应用程序对服务端的调用十七冶响应,进而导致用户请求长时间得不到响应,同时还占用应用程序的资源,不利于及时将访问请求转移到正常服务器上。所以在应用程序中设置服务调用的超时时间,一旦超时未响应,就抛出异常,应用程序根据服务调度策略,可以选择继续重试请求或者将请求转移到其他服务器;

    • 异步调用:通过消息队列等异步方式完成,避免一个服务失败导致整个应用请求失败。但是,对于那些必须确认服务调用成功才能继续下一步操作的应用就不适合使用异步调用了;

    • 服务降级:在网站访问高峰期时,服务可能因大量的并发调用而性能下降,严重的可能会导致服务宕机,为了保证核心应用和功能的正常运行,需要对服务进行降级。降级的方案有2种:

      • 拒绝服务:拒绝优先级低的应用调用,减少服务调用并发数,确保核心应用正常使用;或者随机拒绝部分请求调用,节约资源,让另一部分请求得以成功

      • 关闭服务:关闭部分不重要的服务,或者服务内部关闭部分不重要的功能,以节约系统开销,为重要的服务和功能让出资源

    • 幂等性设计:服务重复调用是无法避免的,应用层也不需要关心服务是否真的失败,只要没有收到调用成功的响应,就可以认为调用失败了,并重试服务调用。因此必须在服务层保证服务重复调用和调用一次产生的结果相同,这就是服务必须具有的幂等性。

     

    高可用的数据

    保证数据存储高可用的方案主要有2种:数据备份和失效转移机制

    数据备份是保证数据有多个副本,任意副本的失效都不会导致数据永久的丢失,从而实现数据完全的持久化。

    失效转移机制则保证当一个数据副本不能访问时,可以快速切换到访问数据的其他副本,保证系统数据的高可用。

    • CAP原理:在讨论数据服务高可用之前,我们先看下数据一致性,因为为了保证数据高可用,往往需要牺牲数据一致性作为代价。

      高可用的数据有如下几个层面的含义:

      数据持久性:保证数据可持久存储,在各种情况下都不会出现数据丢失问题,为了实现数据的持久性,不但在写入数据时需要写入持久性存储,还需要将数据备份一个或者多个副本,存放在不同的物理存储设备上,在某个存储故障或灾难发生时,数据不会丢失;

      数据可访问性:在多份数据副本分别存放在不同存储设备的情况下,如果一个数据存储设备损坏,就需要将数据切换到另一个数据存储设备上,如果这个过程不能很快完成,或者在完成过程中需要停止用户访问数据,那么这段时间数据是不可访问的;

      数据一致性:在数据有多份副本的情况下,如果网络、服务器或者软件出现故障,会导致部分副本写入成功,部分写入失败,这就会造成各个副本之间的数据不一致,数据内容冲突。CAP原理认为:一个提供数据服务的存储系统无法同时满足数据一致性(Consistency)、数据可用性(Availability)、分区耐受性(Partition tolerance)这三个条件,如图所示:

      在大型网站应用中,数据规模总是快速扩张的,所以可伸缩性即分区耐受性必不可少,规模变大以后机器数量也变大,网络和服务器故障就会频繁出现,要想保证应用高可用,就必须保证分布式处理系统的高可用性,所以通常会选择强化分布式存储系统的可用性和伸缩性,而在一定程度上放弃一致性;具体来说数据一致性又可以分为下面几点

      数据强一致性:各个副本的数据在物理存储中总是一致的;更新操作结果和操作响应总是一致的。

      数据用户一致:即数据在物理存储中的各个副本数据不一定是一致的,但是终端用户在访问时,通过纠错和校验机制,可以保证一个一致的且正确的数据返回给用户。

      数据最终一致:这是数据一致性中较弱的一种,即物理存储的数据可能不一致,终端用户访问到的数据也可能不一致,但是系统经过一段时间的自我恢复和修正,数据最终会达到一致。

      因为难以满足数据强一致,网站通常会综合成本、技术和业务场景,结合应用服务和其他数据监控与纠错能力,使存储系统达到用户一致性,保证最终用户访问数据的正确性。

    • 数据备份:数据备份分为冷备份和热备份

      • 冷备份:定期将数据复制到某种存储介质上并物理存档保存,如果系统存储损坏,就从冷备的存储设备中恢复数据;

        冷备份的优点是简单廉价,成本和技术难度较低;

        冷备份缺点是不能保证数据最终一致性,因为数据是定期备份,因此备份设备中的数据比系统中的数据旧,如果系统数据丢失,那么从上个备份点开始更新的数据就会永久丢失,不能恢复;此外也不能保证数据可用性,从冷备份存储中恢复数据需要较长的时间,而这段时间无法访问数据,系统也不可用;

      • 热备份:热备份又分为2种,异步热备份和同步热备份

        异步热备份:指多份数据副本的写入操作异步完成,应用程序收到数据服务系统的写操作成功响应时,只写成功一份,存储系统将会异步地写其他副本(这个过程可能会失败)如下图:

        在异步写入方式下,存储服务器分为主存储服务器(Master)和从存储服务器(Slave),应用程序正常情况下只连接主存储服务器,数据写入时,由主存储器的写操作代理模块将数据写入本机存储系统后立即返回写操作成功响应,然后通过异步线程将写操作数据同步到从存储服务器;

        同步热备份:指多份数据副本的写入操作同步完成,即应用程序收到数据服务系统的写成功响应时,多份数据都已经写操作成功,但是当应用程序收到写操作失败时,可能会有部分副本或者全部副本已经写成功;

        同步热备实现的时候,为了提高性能,在应用程序客户端并发向多个存储服务器同时写入数据,然后等待所以存储服务器都返回操作成功的响应后,再通知应用程序写操作成功。这种情况下,存储服务器没有主从之分,完全对等,更便于管理和维护,存储服务客户端在写多份数据时,并发操作,这意味着多份数据的总写操作延迟是响应最慢的那台存储服务器的响应延迟,而不是多台存储服务器响应延迟之和,其性能和异步热备差不多。

    • 失效转移:数据服务器集群中一台服务器宕机,那么应用程序针对这台服务器的所有写操作都需要重新路由到其他服务器,保证数据访问不会失败,这个过程称之为失效转移;该操作由三部分组成:

      • 失效确认:判断服务器宕机是系统进行失效转移的第一步,系统确认一台服务器是否宕机有2种方式:心跳检测和应用程序访问失败报告

        对于应用程序的访问失败报告,控制中心还需要再进行一次心跳检测进行确认,以免错误判断服务器宕机,因为一旦进行数据访问的失效转移,就意味着数据存储多份副本不一致,需要进行一系列后续操作。

      • 访问转移:确认某台数据存储服务器宕机后,就需要将数据写访问重新路由到其他服务器上,对于完全对等存储的服务器,当其中一台宕机后,应用程序根据配置直接切换到对等服务器即可,但是如果存储是不对等的,那么就需要重新计算路由,选择存储服务器。

      • 数据恢复:因为某台服务器宕机,所以数据存储的副本数目就会减少,必须将副本的数目恢复到系统设定的值,否则再有服务器宕机时,就可能出现无法访问转移(所有副本服务都宕机),数据将会永久丢失,因此系统需要从正常的服务器复制数据,将数据副本数目恢复。

     

    高可用网站的软件质量保证

    • 网站发布:不管是发布新功能还是增加一个核心业务,都需要在服务器上关闭原有应用,然后重新部署新的应用,整个过程还要求不影响用户的使用;

      网站发布过程本质上和服务器宕机效果是一样的,但是网站发布是一次提前预知的服务器宕机,所以这个过程会比较友好,对用户影响更小,通常使用发布脚本来完成发布,流程如下:

      发布过程,每次关闭的服务器都是集群中的一小部分,并在发布完成后立即可以访问,因此整个发布过程不影响用户使用。

    • 自动化测试:代码发布到线上服务器之前需要进行严格的测试,为了保证系统没有引入未预料的bug,还是需要对整个网站功能进行全面的回归测试。目前大部分网站都采用web自动化测试技术,使用自动化脚本测试工具或者脚本完成测试,大型公司一般也会开发自己的自动化测试工具,可以一键完成系统部署,测试数据生成,测试执行,测试报告生成等全部测试过程。

    • 预发布验证:网站发布的时候,并不是直接把测试通过的代码包发布到线上服务器,而是先发布到预发布机器上,开发工程师和测试工程师在预发布服务器上进行预发布验证,执行一些业务流程,确认系统没有问题才正式发布;

      预发布服务器是一种特殊的服务器,它和线上的正式服务器唯一的不同就是没有配置在负载均衡器上,外部用户无法访问

      此外在网站应用中强调一个处理错误的理念是快速失败,即如果系统在启动时发现问题就立刻抛出异常,停止启动让工程师介入排查错误,而不是启动执行错误的操作。

    • 代码控制:网站代码控制核心问题是如何进行代码管理,既能保证代码发布版本的稳定正确,又能保证不同团队的开发互不影响

      • 主干开发、分支发布:代码修改在主干上进行,需要发布的时候,从主干上拉一个分支发布,该分支即成为一个发布版本,如果该版本发现bug,继续在该分支上修改发布,并将修改合并回主干,直到下次主干发布;

      • 分支开发、主干发布:任何修改都不得在主干上直接进行,需要开发一个新功能或者改bug时,从主干拉一个分进行开发,开发完后合并回主干,然后从主干进行发布,主干上的代码永远是最新发布的版本;

        这两种方式各有优缺点,主干开发、分支发布方式,主干反应目前整个应用的状态,一目了然,便于管理和控制,也利于持续集成;分支开发,主干发布方式,各个分支独立进行,互不干扰,可以使不同发布周期的开发在同一个应用中进行。

    • 自动化发布:基于规则驱动的流程,可以实现自动化,开发一个自动化发布工具,根据响应驱动流程,自动构建代码分支,进行代码合并,执行发布脚本

    • 灰度发布:大型网站一般会采用灰度发布模式,将集群服务器分成若干部分,每天只发布一部分服务器,观察运行稳定没有故障,第二天继续发布一部分服务器,持续几天才把整个集群全部发布完毕,期间如果发现问题,只需要回滚已发布的一部分服务器即可。

      灰度发布也常用于用户测试。即部分服务器上发布新版本,其余服务器保持老版本,然后监控用户的操作行为,收集用户体验报告,比较用户对两个版本的满意度,以确定最终发布版本,这种手段也成为AB测试。

     

    网站运行监控

        不允许没有监控的系统上线,网站运行监控对于网站运维和架构设计优化来说至关重要,主要从数据采集和监控管理着手

    监控数据采集之后,除了用作系统性能评估,集群规模伸缩性预测,还可以根据监控数据进行风险预警,并对服务器进行失效转移,自动负载调整,最大化利用集群所有机器的资源

     

     

    • 监控数据采集:包括供数据分析师和产品设计师使用的网站用户行为日志、业务运行数据、以及系统性能数据

      此外,大型网站的日志数据比较大,数据存储与计算压力很大,可以使用基于实时计算框架的storm的日志统计分析工具。

      • 用户行为日志采集:指用户在浏览器上所做的操作及其所在的操作环境,包括用户操作系统与浏览器版本信息,IP地址,页面访问路径,页面停留时间等,这些数据对统计网站PV/UV指标、分析用户行为,优化网站设计、个性营销与推荐非常重要,具体用户行为日志收集有下面2种方式:

        • 服务器端日志收集:开启web服务器的日志记录即可;

        • 客户端浏览器日志收集:利用页面嵌入专门的js脚本可以收集用户真实操作行为,比服务器收集日志更加精准你,缺点是比较麻烦,需要在页面嵌入特定的脚本完成

      • 服务器性能监控:收集服务器性能指标,如系统load、内存占用。磁盘IO,网络IO;

      • 运行数据报告:除了服务器性能监控之外,网站还需要监控一些与具体业务相关的技术和业务指标,比如缓存命中率,平均响应延迟时间,待处理的任务总数,线程阻塞的数量等等;

    • 监控管理

      • 系统报警:可以设置一些监控指标的阈值和值班人员的联系方式,当超过阈值就需要联系相关人员进行报警,报警方式可以配置手机短信,语音报警等等

      • 失效转移:除了应用程序访问失败进行失效转移,监控系统还可以在发现故障的情况下,主动通知应用,进行失效转移

      • 自动优雅降级:优雅降级是指网站为了应付突然爆发的访问高峰,主动关闭部分功能,释放部分系统资源,保证网站核心功能能正常访问。

        网站在监控管理基础上实现自动优雅降级,是网站柔性架构的理想状态:监控系统实时监控所有服务器的运行状况,根据监控参数判断应用访问负载情况,如果发现部分应用负载过高,而部分应用负载过低,就会适当卸载低负载应用部分服务器,重新安装启动部分高负载应用,使应用负载总体均衡,如果所有应用负载都很高,而且负载压力还在继续增加,那就会自动关闭部分非重要功能,保证核心功能正常运行。

    展开全文
  • 5.1.2 网站可用性考核 5.2 高可用的网站架构 5.3 高可用的应用 5.3.1 通过负载均衡进行无状态服务的失效转移 5.3.2 应用服务器集群的Session管理 5.5 高可用的数据 ...

    5.1 网站可用性的度量与考核

    5.1.1 网站可用性度量

     

    5.1.2 网站可用性考核

    5.2 高可用的网站架构

    5.3 高可用的应用

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

         

    5.3.2 应用服务器集群的Session管理

         

      

       

       

    5.5  高可用的数据

      

       

    5.5.1 CAP原理

      

    5.5.2 数据备份

      

              

    5.5.3  失效转移

      

        

    5.6 高可用网站的软件质量保证

       

         

      

        

    5.6.5 自动化发布

        

    5.6.6 灰度发布

          

     

     

    参见:《网站技术架构:核心原理与案例分析》

     

    展开全文
  • 网站可用架构--一

    2016-05-10 09:50:00
    网站可用性考核  可用性指标是网站架构设计的重要指标。从管理层面,可用性指标是网站或者产品的整体考核指标,具体到每个工程师的考核,更多使用的是故障分。所谓故障分是指对网络故障进行分类加权计算故障...
  • 读书笔记:网站架构之可用性

    千次阅读 2013-12-09 21:32:41
    一、高可用网站架构 二、高可用的应用 三、高可用的服务 四、高可用的数据 五、网站的软件质量保证和运行监控 PS:本文为《大型网站技术架构 & 核心原理与案例分析(李智慧 著)》一书的读书笔记
  • 2. 可用性 3. 伸缩性 4. 扩展性 5. 安全性 瞬时响应:网站的高性能架构 1. 网站性能测试: 1). 不同视角下的网站性能 a. 用户视角的网站性能:用户计算机,网站服务器通信时间,网站服务器处理时间,用户...
  • 网站可用性考核 故障分=故障时间(分钟) x 故障权重 高可用的网站架构 高可用架构的主要手段是数据和服务的冗余备份及失效转移, 一旦某些服务器宕机, 就将服务切换到其他可用的服务器上, 如果磁盘损坏, 则从...
  • XX系统可用性易用性

    2017-03-16 20:10:00
    XX系统可用性易用性提高 网站不可用性也被称为网站故障,业界通常用多少个9来衡量网站的可用性。如:网站不可用时间(故障时间)=故障...网站可用性不同于其他架构指标,它更加看的见摸得着,跟技术运营、相关各...
  • 可用性可用性是啥子: ...就是网站能顺利运行,那么涉及DNS劫持 ...可用性考核度量 公司会把这个和升职加薪成为CEO挂钩滴。鼓励鞭策程序员做好可用性。 高可用性的架构: 买入好的设备。比如之前淘
  • 相比于网站的其他非功能特性,网站的可用性更牵动着人们的神经,大型网站的不可用事故直接影响公司形象和利益,许多互联网公司都将网站可用性列入了工程师的绩效考核,与奖金升迁等利益挂钩。  网站不可用也被称作...
  • 网站可用架构

    2021-02-08 08:53:37
    一、网站分层架构 二、高可用的应用 三、高可用的服务 四、高可用的数据 五、网站软件质量保证 六、网站运行监控 七、网站可用性度量与考核
  • 5.1网站可用性的度量和考核 通常用多少个9来衡量网站可用性,qq是4个9qq服务99.99%可用,twitter 不足2个9 5.2高可用的网站架构 由于硬件故障是常态,那么网站高可用主要目的是保证硬件故障的情况下服务依旧...
  • QQ的可用性 4个9 99.99% 2个9基本可用,88小时/年 3个9较高可用,9小时/年 4个9具有自动恢复能力的高可用,53分钟/年 5个9 极高可用,5分钟/年 考核 事故级 A类 B类 高可用架构(分层+分离+集群) 高可用服务...
  • 相比于网站的其他非功能特性,网站的可用性更牵动着人们的神经,大型网站的不可用事故直接影响公司形象和利益,许多互联网公司都将网站可用性列入了工程师的绩效考核,与奖金升迁等利益挂钩。  网站不可用也被称作...
  • 相比于网站的其他非功能特性,网站的可用性更牵动着人们的神经,大型网站的不可用事故直接影响公司形象和利益,许多互联网公司都将网站可用性列入了工程师的绩效考核,与奖金升迁等利益挂钩。  网站不可用也被称作...
  • 可用性考核:对外是服务承诺,对内是考核指标;(互联网公司,网站可用性与工程师、架构师的绩效关联); 高可用的应用:负载均衡 + 集群;集群中的用户上下文:单独的Session(也可以是redis)管理,利用redis...
  • 2、网站可用性考核 二、高可用性网站架构 1、应用层 位于应用层的服务器通常为了应对高并发的访问请求,会通过负载均衡设备将一组服务器组成一个集群对外提供服务,当负载均衡设备通过心跳检测等手段监控到某台 ...
  • ④5个9=极高可用->理想状态那么,可用性的9又是怎么计算出来的呢:①网站不可用时间=故障修复时间点-故障发现时间点②网站年度可用性指标=(1-网站不可用时间/年度总时间)*100%(2)如何考核网站可用性?...
  • 网站的可用性的度量和考核 可用性度量 网站不可用被称作网站故障,QQ的可用性是4个9,即QQ服务99.99%可用,...网站可用性考核 高可用的网站架构 高可用的架构设计主要目的就是保证服务器硬件故障时服务依然可...
  • 阅读《大型网站技术架构:核心原理与案例分析》第五、六、七章,结合我们的系统,分析如何...我们通过一个神奇的数字9来度量网站可用性,采用故障分来考核网站可用性。可用性指标是网站架构设计的重要指标,网站可用...
  • 1、网站可用性的度量与考核  网站不可用时间(故障时间)=故障修复时间点-故障发现(报告)时间点  网站年度不可用时间=(1-网站不可用时间/年度时间)× 100%  可用性指标时网站架构设计的重要指标...
  • 网站的可用性(Avaliability)描述网站可有效访问的特性。 1、网站可用性的度量与考核
  • 1、网站可用性的度量与考核  网站不可用时间(故障时间)=故障修复时间点-故障发现(报告)时间点  网站年度不可用时间=(1-网站不可用时间/年度时间)× 100%  可用性指标时网站架构设计的重要指标...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,913
精华内容 1,165
关键字:

网站可用性考核