大型网站技术架构(五)--网站高可用架构

大型网站技术架构(一)--大型网站架构演化

大型网站技术架构(二)--架构模式

大型网站技术架构(三)--架构核心要素

大型网站技术架构(四)--网站的高性能架构

网站的可用性(Avaliability)描述网站可有效访问的特性。

1、网站可用性的度量与考核

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

      网站年度不可用时间=(1-网站不可用时间/年度时间)× 100%

可用性指标时网站架构设计的重要指标,对外是服务承诺,对内是考核指标,具体到每个工程师,更多的是使用故障分。

所谓故障分是指对网站故障进行分类加权计算故障责任的方法。如下是个案例:


分类


描述


权重


事故级故障


严重故障,网站整体不可用


100


A类故障


网站访问不顺畅或核心功能不可用


20


B类故障


非核心功能不可用,或核心功能少数用户不能访问


5


C类故障


其他故障


1

故障分的计算公式为:

   故障分=故障时间(分钟)* 故障权重

2、网站的高可用架构

一个典型的网站设计通常遵循如下图所示的基本分层模型。

在负载的大型网站架构中,划分的粒度会更小,更详细,但通常还是能够把这些服务器划分到这三层中。

对于应用层的服务器通常为了应对高并发的访问请求,会通过负载均衡设备将一组服务器组成一个集群共同 对外提供服务,当负载均衡设备通过心跳检测到某台服务器不可用时,就将其从集群列表中提出,并将请求分发到集群中其他 可用的服务器上,是整个集群保存可用,从而实现应用高可用。

位于服务层的服务器情况和应用层类似,也是通过集群方式实现高可用,只是这些服务器被应用层通过分布式服务调用框架访问, 分布式服务调度框架会在应用层客户端中实现负载均衡功能。

位于数据层的服务器情况比较特殊,数据服务器上存储着数据,为了保证数据不丢失,数据访问服务不中断,需要在数据写入时进行数据同步复制,将数据写入多台服务器上,实现数据冗余备份。

网站升级的频率一般都非常高,每次网站发布都需要关闭服务,重新启动系统,相当于服务器宕机。因此网站的可用性架构还需要考虑到网站升级 发布引起的宕机。

3、高可用的应用

应用层主要处理网站应用的业务逻辑,也称为业务逻辑层,应用的一个显著特点就是应用的无状态行,因此实现负载均衡相对简单一点。

Web应用中将这些多次请求的上下文称为回话(Session),在单机情况下,session可部署在服务器上的Web容器上管理。在使用负载均衡 的集群环境中,由于负载均衡服务器可能会将请求分发到集群任何一台应用服务器上,所以保证每次请求依然能够获得正确的session比单机 时要复杂的多。在集群环境下,session管理主要有  以下手段。

1、Session复制

Session复制是早期企业应用系统使用较多的一种服务器集群Session管理机制。应用服务器开启Web容器的Session复制功能,在集群中几台服务器之间同步Session对象,是每台服务器上都保存所有用户的Session信息。

这种方案虽然简单,从本机读取Session信息也很快,但当集群规模比较大的时候会占用服务器和网站的大量资源,在大量用户访问的情况下,甚至会出现内存不够Session使用的情况。

2、Session绑定

Session绑定可以利用负载均衡的源地址Hash算法实现,负载均衡服务器总是将来源于同一IP的请求分发到同一台服务器上。这样在整个回话期间,用户所有的请求都在同一天服务器上处理,即Session绑定到某台特定的服务器上,保证Session总能在这台服务器上获取,这种方法有成为回话粘滞。

3、利用Cookie记录Session

一种管理Session的方式是将Session记录在客户端,每次请求服务器的时候,将Session放在请求中发送给服务器,服务器处理完请求后再将修改后的Session响应给客户端。

4、Session服务器

Session服务器,即把session的管理独立部署在某一台机器上,Web服务器不保存用户Session信息,每次都去Session服务器取数据。

这种解决方案事实上是将应用服务器的状态分离,分为无状态的应用服务器和有状态的Session服务器。对于有状态的Session服务器,一种比较简单的方式是利用分布式缓存、数据库等。

4、高可用的服务

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

除此之外,在实践中,还有一些几点高可用的服务策略。

1、分级管理

2、超时设置

3、异步调用

4、服务降级,网站高峰期间,可以关闭一些不重要的服务,如评论。

5、高可用的数据

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

CAP原理:即数据持久性、数据可访问性、数据一致性。

6、高可用的网站质量保证

这里主要说下网站发布流程吧。看图即可:

7、网站运行监控

不允许没有监控的系统上线”。网站运行监控对于网站运维和架构设计优化至关重要,运维没有监控的网站,犹如驾驶没有仪表的飞机。

具体到监控哪些数据,主要有:

    1、用户行为日志收集(服务器端和浏览器端)

      2、服务器性能监控(CPU、内存等)

      3、运行数据监控(缓存命中率、平均响应延迟时间、每分钟发送邮件数目、待处理的任务总数等

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

大型网站技术架构(五)--网站高可用架构

时间: 2024-10-19 12:05:51

大型网站技术架构(五)--网站高可用架构的相关文章

数据库高可用架构(MySQL、Oracle、MongoDB、Redis)

一.MySQL MySQL小型高可用架构 方案:MySQL双主.主从 + Keepalived主从自动切换 服务器资源:两台PC Server 优点:架构简单,节省资源 缺点:无法线性扩展,主从失败之后需要手动恢复主从架构 MySQL中型高可用架构 方案:MMM + MySQL双主 + 多从高可用方案 服务器资源: 1.至少五台PC Server,2台MySQL主库,2台MySQL从库,1台MMM Monitor: 2.1台MMM Monitor选择低配: 3.如果不采用F5作为从库的负载均衡器

高可用架构设计与实践

第一课:高可用架构知识原理篇 什么架构的高可用? 架构高可用的重要性? 架构高可用的常用手段都有哪些? 架构高可用评价维度是什么? 架构高可用的考核如何分级? 架构高可用的涉及环节都有哪些? 第二课:高可用架构设计之总体架构篇 高可用架构为什么需要分层? 高可用架构分层设计原则是什么?如何架构分层? 高可用架构分层最佳实践: 我们的实践案例: 第三课:高可用架构设计之硬件篇 如何选择硬件?选择什么样的硬件? 高可用架构硬件层面如何保证? 硬件层面高可用架构保证的最佳实践是什么? 我们的实践案例:

[转]数据库高可用架构(MySQL、Oracle、MongoDB、Redis)

一.MySQL MySQL小型高可用架构 方案:MySQL双主.主从 + Keepalived主从自动切换 服务器资源:两台PC Server 优点:架构简单,节省资源 缺点:无法线性扩展,主从失败之后需要手动恢复主从架构 MySQL中型高可用架构 方案:MMM + MySQL双主 + 多从高可用方案 服务器资源: 1.至少五台PC Server,2台MySQL主库,2台MySQL从库,1台MMM Monitor: 2.1台MMM Monitor选择低配: 3.如果不采用F5作为从库的负载均衡器

企业中MySQL主流高可用架构实战三部曲之MHA

老张最近两天有些忙,一些老铁一直问,啥时更新博文,我可能做不到天天更新啊,但保证以后一有空就写一些干货知识分享给大家. 我们如果想要做好技术这项工作,一定要做到理论与实践先结合.我一个曾经被数据库虐得体无完肤的过来人给大家一些建议:就是只看书,背理论真的行不通,到时遇到棘手的问题,你还是一样抓瞎.一定要在理论理清的基础上多做实验. 给自己定个目标,3个月做够100-500个实验.然后整理在做实验过程中的各种报错,认真解读分析报错原理,做好笔记.最后再拿起书,重新阅读之前有些可能理解不了的理论知识

mysql复制(高可用架构方案的基础)

mysql复制:把一个数据库实例上所有改变复制到另外一个数据库库服务器实例的过程特点:1.没有改变就无所谓复制 ;改变是复制的根本与数据源2.所有的改变:是指可以复制全部改变,也可以复制部分改变 可以在全部改变中根据业务需求选择部分库和部分表的复制复制的场景: 1.数据库容灾 2.需求:创建一个从数据服务器,做数据的测试和分析 3.负载均衡 4.复制时高可用架构方案的基础 mysql高可用架构特点1.数据库故障的检测与排除2.主从数据库的切换3.数据的备份和保护 mysql高可用架构常用方案1.

大型网站技术架构(五)--网站高可用架构(转)

网站的可用性(Avaliability)描述网站可有效访问的特性. 1.网站可用性的度量与考核       网站不可用时间(故障时间)=故障修复时间点-故障发现(报告)时间点       网站年度不可用时间=(1-网站不可用时间/年度时间)× 100% 可用性指标时网站架构设计的重要指标,对外是服务承诺,对内是考核指标,具体到每个工程师,更多的是使用故障分.      所谓故障分是指对网站故障进行分类加权计算故障责任的方法.如下是个案例: 分类 描述 权重 事故级故障 严重故障,网站整体不可用

大型网站技术架构 读书笔记4 高可用架构

说句掏心窝的话,高可用甚至比高性能更重要.为什么? 因为你把系统的性能优化10倍,你的老板可能会说:小董呀,干的不错. 可是,如果你负责的模块,三天两头就宕掉了,嘿嘿,你懂得. 可用性度量 99%-----网站年度不可用时间小于88个小时 99.9%---网站年度不可用时间小于9个小时 99.99%---网站年度不可用时间小于53分钟 高可用架构 一般的互联网公司大多采用pc级服务器,开源的数据库和操作系统,这样来说,当然节省成本,不过另一方面来说,服务器宕机就是一个大概率事件了. 所以,高可用

读书笔记5大型网站的高可用架构

一.网站实现高可用的手段 实现高可用架构的主要手段是数据和服务的冗余备份和失效转移,一旦某些服务器宕机,就将服务切换到其他可用的服务器上,如果磁盘损坏,则从备份的磁盘读取数据 二.可用性度量与考核 首先,不得不说:要保证一个网站永远完全可用几乎是一件不可能完成的任务(Mission Impossible,是不是有点碟中谍的感觉). (1)如何度量网站可用性? 一个神奇的数字—9!你有几个9,就代表了你的可用性.例如QQ可用性达到了4个9:99.99% ①2个9=基本可用 ②3个9=较高可用 ③4

五、网站的高可用架构

5.1 网站可用性的度量与考核 网站的可用性描述网站可有效访问的特性. 网站的页面能完整呈现在用户面前,需要经过很多环节,任何一个环节出问题,都会导致网站页面不可访问. DNS会被劫持.CDN服务可能会挂掉.网站服务器可能会宕机.网站交换机可能会失效.硬盘会损坏.网卡会松掉.机房会停电.空调会失灵.程序会有Bug.黑客会攻击.促销引来大量的访问.第三方合作伙伴的服务不可用..... 5.2  高可用的网站架构 网站高可用架构设计的主要目的就是保证服务器硬件故障时服务依然可用.数据依然保存并能够被