网站的核心要素之高可用篇

网站的可用性(Availability)描述网站有效访问的特性(不同于网站的运营的指标:Usability,通常也翻译为可用性,这个可用性更多的是对用户产生的价值),相比于其他非功能的特性,网站的可用性更能牵动人的神经,因为网站的可用性直接影响公司的形象和公司的利益,许多互联网公司都将网站的可用性列为工程师的一项考核指标。

一、网站高可用的度量

网站不可用也被称为网站故障,业界通常用X个9表示网站的可用性,如QQ的可用性就是4个9,即QQ99.99%的时间都是可用的。

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

 对于大多数网站而言,2个9代表网站基本可用,3个9代表具备较高可用性,4个9是具备恢复能力的可用,5个9具备极高的可用性。由于可用性的影响因素很多,想达到4个9或5个9,除了过硬的技术团队实力外,还要有工程师的高度责任感,外加不错的运气。实际上,推特系统的可用性不足2个9。

二、高可用的应用

应用的高可用,其实就是“业务逻辑”的高可用。应用的一个显著特点就是“无状态”。所谓无状态就是应用服务器不保存业务上下文的状态信息。而是根据每次提交的请求进行对应的业务处理,多个服务器之间完全对等,请求提交到任意服务器,处理结果都是一样。其目的是“负载均衡达到失效无状态转移”。其手段主要两点:

1、通过负载均衡进行无状态失效转移

2、session的管理:a、在集群中避免使用session,可以使用cookie代替session。c、非要使用session,建议独立session服务器或者根据IP的hash计算后在负载。

三、高可用的服务

高可用的服务和高可用的应用其目的差不多“负载均衡达到失效无状态转移”。除此之外,还有一些策略手段:

1、服务分级

核心服务使用好的服务器,非核心的服务可以使用相对差一点的服务器。高流量的服务使用好的服务器,普通的服务可以使用相对差一点的服务器。等等。

2、服务超时

由于服务端宕机、线程死锁等等原因,可能会导致应用程序对服务的调用失去响应。继而导致应用对服务的调用长时间得不到响应却始终占有服务资源。

3、异步处理

通过消息队列等异步方式完成“一系列服务”,避免因为个别服务出现故障而导致整个服务体系全部不能使用。例如:注册后发邮件/短信等。

4、服务降级

a、关闭功能:早期的淘宝双11的时候,常常关闭评论功能。

b、拒绝服务:推特经常随机拒绝一些服务,经常有人看到服务故障的页面,但问下其他人,别人却能正常使用。

5、幂等性设计

比如TCC分布式事务,confirm和cancel的实现要具有幂等性。

四、高可用的数据

不同于高可用的服务和应用,不同的数据存储服务器保存的数据可能不相同。保证数据的高可用手段主要是“数据备份”和“失效转移”。

1、关系型数据库,以mysql的innodb为例,数据备份主要包含:主从复制(三种手段,同步,异步、半同步)+keepalived,MGR。

2、非关系型数据库,以redis为例,主从模式、哨兵模式、集群模式。其他还有es的集群,等等。

五、高可用的软件质量

1、代码管理

比如svn,主干发布、分支开发

2、自动化测试

代码发布到线上服务器需要经过严格的测试,虽然有可能新功能只是一个小小的功能点,修改可能很少,但是为了保证系统没有引入意料之外的BUG,还是要对网站进行回归测试。目前大部分网站都实现了自动化测试,使用自动化测试工具或脚本对网站进行测试,比较流行的比如selenium。可以对网站进行功能测试以及浏览器兼容性测试。

3、预发布验证

把网站发布到“预发布服务器”上,他和正式服务器的区别是“没有使用负债均衡”和“外部不能访问”。需要注意的是,“预发布验证”所操作的数据都是真实数据,他可能会引来不可预期的问题,比如测试发布一个商品,可能会真有用户来买这个商品,所以在测试的时候,一定要注意区分。

4、网站发布

不管网站发布的功能多么小,都需要停掉原有功能,换上新的功能。整个过程为了保证网站的可用性,就像对飞机换个发动机,但是飞机还不能停飞,不能摇晃。好多大型网站每周都要发布一两次,一些网站也有可能一天发布好多次。网站的每一次发布几乎都和宕机差不多。区别是,网站发布是一次可以预测的服务器宕机,为了提高网站的高可用性,咱们可以使用更柔和、影响更小的手段:

5、自动化发布

对有固定发布日期的网站,比如每周四发布(前三天准备、留一天解决出现的问题)。国外的一个CTO提出了一个“火车发布模型”,即把等待发布的每一个功能看做是火车的每一节车厢,把每一个验证看做是每一个经过的站点,不通过的项目下车,剩下的项目继续进行下一站,直到终点。其流程图如下:

当然了,这种模型也会照成“空车”抵达的情况。还有可能会遇到“达官贵人”,比如某个功能是领导指名本次发布必须要的,他要是不通过,其他过了也没有意义,都得下车回来。

正因为这种模型是“基于规则驱动”的模型,所以流程可以自动化。开发一个自动化发布工具实现发布过程自动化。根据响应驱动流程:自动化代码构造分支,进行代码合并、执行发布脚本。

6、灰度发布

大型网站的业务集群规模非常庞大,在国内不少公司服务器规模超过上万台。一旦发布出现故障,想要发布回滚也是很困难的。为了应付这种局面,大型网站引入了“灰度发布”的模式。将集群分成若干部分,每天只发布一部分服务器,然后观察有没有问题,第二天继续发布一部分...持续多天,直到集群发布完毕,如果中间出现故障,只需要回滚一部分服务器就行了。

添加评论

Loading