(五)–网站高可用架构

最后更新于:2022-04-01 15:52:06

    网站的可用性(Avaliability)描述网站可有效访问的特性。 ### 1、网站可用性的度量与考核      网站不可用时间(故障时间)=故障修复时间点-故障发现(报告)时间点      网站年度不可用时间=(1-网站不可用时间/年度时间)× 100%      可用性指标时网站架构设计的重要指标,对外是服务承诺,对内是考核指标,具体到每个工程师,更多的是使用故障分。      所谓**故障分**是指对网站故障进行分类加权计算故障责任的方法。如下是个案例: <table border="1" cellspacing="0" cellpadding="0"><tbody><tr><td valign="top"><p><span style="font-size:14px">分类</span></p></td><td valign="top"><p><span style="font-size:14px">描述</span></p></td><td valign="top"><p><span style="font-size:14px">权重</span></p></td></tr><tr><td valign="top"><p><span style="font-size:14px">事故级故障</span></p></td><td valign="top"><p><span style="font-size:14px">严重故障,网站整体不可用</span></p></td><td valign="top"><p><span style="font-family:Calibri; font-size:14px">100</span></p></td></tr><tr><td valign="top"><p><span style="font-family:Calibri; font-size:14px">A</span>类故障</p></td><td valign="top"><p><span style="font-size:14px">网站访问不顺畅或核心功能不可用</span></p></td><td valign="top"><p><span style="font-family:Calibri; font-size:14px">20</span></p></td></tr><tr><td valign="top"><p><span style="font-family:Calibri; font-size:14px">B</span>类故障</p></td><td valign="top"><p><span style="font-size:14px">非核心功能不可用,或核心功能少数用户不能访问</span></p></td><td valign="top"><p><span style="font-family:Calibri; font-size:14px">5</span></p></td></tr><tr><td valign="top"><p><span style="font-family:Calibri; font-size:14px">C</span>类故障</p></td><td valign="top"><p><span style="font-size:14px">其他故障</span></p></td><td valign="top"><p><span style="font-family:Calibri; font-size:14px">1</span></p></td></tr></tbody></table>     故障分的计算公式为:    故障分=故障时间(分钟)* 故障权重 ### 2、网站的高可用架构 一个典型的网站设计通常遵循如下图所示的基本分层模型。 ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-06-23_576bad6059b1b.jpg) 在负载的大型网站架构中,划分的粒度会更小,更详细,但通常还是能够把这些服务器划分到这三层中。 ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-06-23_576bad606f537.jpg)           对于应用层的服务器通常为了应对高并发的访问请求,会通过负载均衡设备将一组服务器组成一个集群共同 对外提供服务,当负载均衡设备通过心跳检测到某台服务器不可用时,就将其从集群列表中提出,并将请求分发到集群中其他 可用的服务器上,是整个集群保存可用,从而实现应用高可用。        位于服务层的服务器情况和应用层类似,也是通过集群方式实现高可用,只是这些服务器被应用层通过分布式服务调用框架访问, 分布式服务调度框架会在应用层客户端中实现负载均衡功能。        位于数据层的服务器情况比较特殊,数据服务器上存储着数据,为了保证数据不丢失,数据访问服务不中断,需要在数据写入时进行数据同步复制,将数据写入多台服务器上,实现数据冗余备份。        网站升级的频率一般都非常高,每次网站发布都需要关闭服务,重新启动系统,相当于服务器宕机。因此网站的可用性架构还需要考虑到网站升级 发布引起的宕机。 ### 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、高可用的网站质量保证    这里主要说下网站发布流程吧。看图即可: ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-06-23_576bad60881a1.jpg) ###  7、网站运行监控    “**不允许没有监控的系统上线”**。网站运行监控对于网站运维和架构设计优化至关重要,运维没有监控的网站,犹如驾驶没有仪表的飞机。    具体到监控哪些数据,主要有:   1、用户行为日志收集(服务器端和浏览器端)   2、服务器性能监控(CPU、内存等)   3、运行数据监控(缓存命中率、平均响应延迟时间、每分钟发送邮件数目、待处理的任务总数等)   监控数据采集后,除了用作系统性能评估、集群规模伸缩性预测等,还可以根据实时监控数据进行风险预警,并对服务器进行失效转移,自动负载调整,最大化利用集群所有机器的资源。
';