当前位置:首页 > 架构 > 正文内容

大型系统高可用的一般策略

phpmianshi2年前 (2019-05-26)架构240

负载均衡


首先是应用服务器的负载均衡。负载均衡核心要解决的就是通过一个负载均衡服务器,将用户的请求分发给多个应用服务器,将多个应用服务器构建成一个集群,共同对外提供服务。这样的架构可以提高系统的处理能力,以解决高并发用户请求下的系统性能问题。

事实上,负载均衡还可以实现系统的高可用。因为用户的请求是通过负载均衡服务器请求分发到不同的应用服务器上的。那么当某个应用服务器宕机的时候,负载均衡服务器可以通过响应超时或者其它的心跳策略,发现这个应用服务器不可用,就可以将请求转发给其它的服务器,保证用户的请求总是能够成功的,整个系统对外看起来是可用的。从而使某个应用的服务器宕机,不会影响到整个系统的可用性。


这里面需要注意的一个点是,当我们提到一个应用服务器不可用的时候,并不仅仅是指应用服务器的硬件故障,或者是系统故障导致的系统宕机,更多的可能是应用程序在发布,因为应用程序要发布,必须要关闭以前的应用程序进程,拷贝新的程序代码,重新启动应用程序,这个时间可能需要几分钟或者十几分钟的时间,那么这段时间这台应用服务器对外看起来就是不可用的。


而这样的发布在互联网场景中是非常频繁的,一周有几次,甚至一天都有几次这样的发布。应用服务器是需要频繁停机的。所以在架构设计的时候,你不光要考虑到真正的服务器硬件或者系统故障导致的宕级,还要考虑到应用程序发布导致的系统停机,而这个可能更加频繁。


负载均衡实现方法


    1.HTTP 重定向负载均衡

    2.DNS 负载均衡

    3.反向代理负载均衡

    4.IP 层负载均衡(四层负载均衡)

    5.数据链路层负载均衡


数据库复制与失效转移


数据库的高可用要比应用服务器复杂很多,因为应用服务器是无状态的,请求可以分发到任何一台服务器去处理,而数据库上必须存储有正确的数据才能将请求分发给它。对于数据库的高可用,通常是使用数据库复制与失效转移来完成的。

因为有数据复制,所以用户请求可以访问到不同的从服务器上,当某一台从服务器宕机的时候,系统的读操作不会受到影响,实现数据库读操作高可用。而如果实现了主主复制,那么当主服务器宕机的时候,写请求连接到另外一台主服务器上,实现数据库的写操作高可用,而数据库部署的时候,可以同时部署如下图所示这样的主主复制和主从复制,也就是实现数据库的读写都高可用。


消息队列隔离

系统高可用的另一种策略是使用消息队列实现异步解耦,即消息队列隔离。

一方面,消息的生产者和消费者通过消息队列进行隔离,那么如果消费者出现故障的时候,生产者可以继续向消息队列发送消息,而不会感知到消费者的故障,等消费者恢复正常以后再去到消息队列中消费消息,所以从用户处理的视角看,系统一直是可用的。

另一方面,由于分布式消息队列具有削峰填谷的作用,所以在高并发的时候,消息的生产者可以将消息缓存在分布式消息队列中,消费者可以慢慢地到消息队列中去处理,而不会将瞬时的高并发负载压力直接施加到整个系统上,导致系统崩溃。


限流和降级

系统高可用的另一个策略是限流和降级。主要针对的是,在高并发场景下,如果系统的访问量超过了系统的承受能力,如何对系统进行保护?


限流是指对进入系统的用户请求进行限流处理,如果访问量超过了系统的最大处理能力,就会丢弃一部分的用户请求,保证整个系统可用,保证大部分用户是可以访问系统的。这样虽然有一部分用户的请求被丢弃,产生了部分不可用,但还是好过整个系统崩溃,所有的用户都不可用要好。


保护系统的另一种手段就是降级。有一些系统功能是非核心的,但是实际它也给系统产生了非常大的压力,比如说在电商系统中有“确认收货”这个功能,对于大多数互联网电商应用,我们即使是不去确认收货,超时它会自动确认收货。


但实际上确认收货这个操作是一个非常重的操作,因为它要更改订单状态,完成支付确认,并进行评价等一系列操作。这些操作都是一些非常重的、对数据库压力很大的操作。如果在系统高并发的时候去完成这些操作,那么会对系统雪上加霜,使系统的处理能力更加恶化。解决办法就是在系统高并发的时候,比如说像淘宝“双11“这样的时候,当天可能整天系统都处于一种极限的高并发访问压力之下,这一天就可以将确认收货、评价这些非核心的功能关闭,将宝贵的系统资源留下来,给正在购物的人,让他们去完成交易。


异地多活机房架构

系统高可用的另一个策略是异地多活的架构。我们前面提到的各种高可用策略,都还是针对一个机房内的系统架构,但是如果整个机房都不可用,比如说机房所在城市遭遇了地震,机房遭遇了火灾或者停电,这样的话,不管我们前面的设计和系统多么的高可用,整个机房都不可访问,看起来系统依然是不可用的。


为了解决这个问题,同时也为了提高系统的处理能力和改善用户体验。很多大型互联网应用都采用了异地多活的多机房架构策略,也就是说将数据中心分布在多个不同地点的机房里,这些机房都可以对外提供服务,用户可以连接任何一个机房进行访问。这样每个机房都可以提供完整的系统服务,即使某一个机房不可使用,系统也不会宕机,依然保持可用。


异地多活的架构考虑的一个重点是,用户请求如何分发到不同的机房去。这个主要可以在域名解析的时候完成,也就是用户进行域名解析的时候,会根据就近原则或者其它一些策略,完成用户请求的分发。


另一个至关重要的技术点是,因为是多个机房都可以独立对外提供服务,所以也就意味着每个机房都要有完整的数据记录,所以用户在任何一个机房完成的数据操作,都必须要同步传输给其它的机房,需要进行数据实时同步。


目前远程数据库同步的解决方法有很多,最需要关注的是数据冲突问题。同一条数据,同时在两个数据中心被修改了,该如何解决?为了解决这种数据冲突的问题,很多异地多活的多机房架构实际上采用的是类似 MySQL 的主主模式,也就是说多个机房在某个时刻是有一个主机房的,某些请求只能到达主机房才能被处理,其它的机房不处理这一类请求,以此来避免关键数据的冲突。


自动化测试

其中一种高可用的运维是自动化测试。对于一个成熟的互联网系统,任何一次代码变更,都可能需要执行大量的回归测试,才能够保证系统没有 bug,而这种更新又是非常频繁的,如果依赖手工操作,测试效率和测试资源都难以满足如此大量的回归测试需求。所以对于成熟的互联网产品,很多时候采用自动化测试,通过自动化脚本自动对 APP 或者是服务接口进行测试。


一开始的时候要写自动化的测试脚本,工作量会比较大,投入也会比较大。但是随着脚本的不断的积累,自动化测试的成本会比手工测试的成本要更低。一般说来,在实践中,对于比较成熟的互联网产品,也就是说每次变更相对影响比较小的互联网产品,使用自动化测试是比较划算的。


自动化监控

还有一种是自动化监控。系统在线上运行的时候,必须要实时的监控系统的各项指标,包括业务指标和技术指标。业务指标包括用户访问量、订单量、查询量这些主要的业务指标,技术指标包括 CPU、磁盘、内存的使用率等。通过这些指标可以实时监控业务是否正常,系统是否正常。如果指标不正常,通过监控报警的手段,通知相关的人员,还可以在自动化监控的基础上去,触发自动化的运维工具,进行自动化的系统修复。


预发布

另一种手段是预发布。虽然在系统上线之前,系统在代码更新以后,要经过测试才会上线,但是还有一些情况在测试环境是无法复现的。比如对第三方服务的调用,数据库结构的变更,以及一些线上的配置参数变更等等,只有线上才能够发现。


但是一旦发布到线上以后,如果有这些问题,就会导致系统不可用,解决方法就是进行预发布。在线上的服务器集群里面有一台服务器,是专门的预发布服务器,这台服务器不配置在负载均衡服务器,也就是说外部的用户是无法访问到这台服务器的,但是这台服务器跟其它的应用服务器,使用的配置、连接的数据库、连接的第三方服务都是完全一样的,它是一个完全线上的一个服务器,而这个服务器只有内部的工程师才可以访问到。


在系统发布的时候,先发布到这台预发布服务器上,然后工程师通过域名绑定的方式,直接访问这台服务器,进行一些关键的业务操作,看系统是否正常。如果正常,那么就将代码同步到其它的服务器上,这时候外部服务器才能够访问到最新的代码。如果发现问题,那么就可以重新进行修复。这个问题虽然是线上的,但是并不会影响到外部用户的使用。


灰度发布

对于大型互联网系统,虽然有前面的各种保障措施,但还是可能发生上线以后用户报告出现故障,对于用户报告的故障或者监控到的故障,就需要对系统进行回滚到原来的代码,系统退回到前一个版本。但是对于大型互联网系统而言,它的服务器特别多,可能有数万台服务器,这个时候即使是进行系统回滚,也可能要花很长的时间。这段时间系统一直处于某种不可用的故障状态。


为了避免上述情况,大型互联网系统,会使用一种灰度发布的手段,也就是说每天都只发布一部分服务器,如果出现问题,那么只需要回滚这一部分服务器就可以。发布以后观察一天,第二天再发布一部分服务器。如果没有故障报告,那么就继续发布,如果有故障报告就进行回滚,减少故障的影响力和影响时间。


版权声明:本文由PHP面试资料网发布,如需转载请注明出处。
分享给朋友:

相关文章

系统架构的演进之路-单体到SOA到微服务

单体系统的困难在微服务出现之前,互联网应用系统主要是单体系统,也就是说一个网站的整个系统由一个应用构成。如果是 Java,就打包成一个 war 包,一个 war 包包含整个应用系统,系统更新的时候,即...

如何写出漂亮的代码-代码整洁之道

如何写出漂亮的代码-代码整洁之道

背景代码本就该是直接简单的,横就是横,纵就是纵,架构原本也本是清晰明了的,模块是模块,过程是过程。可随着项目生命周期的变长,随着需求不断的被实现,面对不同思想的人,不同场景的要求,不同技能水平的实施,...

单台服务器并发TCP连接数到底可以有多少

常识一:文件句柄限制在linux下编写网络服务器程序的朋友肯定都知道每一个tcp连接都要占一个文件描述符,一旦这个文件描述符使用完了,新的连接到来返回给我们的错误是“Socket/File:Can&#...

如何应对网站流量暴增

如何应对网站流量暴增

按照经验大概出问题地方是DB,磁盘io、CPU、带宽、连接数、内存其中的一个或几个。不同的业务,不同的系统设计,出问题的地方会有所不同。如果流量增大数倍,势必某个资源会在瞬间被榨干,然后所有的服务都会...

基于rebase的Git工作流

使用Git在多人协作的过程中,我们也会面临如何运用好Git的问题。这种情况下,就出现了各种各样的Git Workflow,而本文将介绍一种基于rebase的工作流,这种工作流也是目前开源社区所比较推崇...

秒杀如何设计

秒杀难点:1、突发流量、数据热点2、数据一致性、短暂混沌态如果采用传统的数据库进行数据存储,对同一资源的争抢,就会面临严重的锁冲突问题。一般是通过一个前置的,速度更快的存储顶在前面,这就涉及到源库和目...

发表评论

访客

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。