高并发系统高可用设计方案(一)

本文详细探讨了互联网应用的高可用性,包括了解耦、隔离、异步、备份、多活等核心设计方案。通过降低组件耦合、实现物理隔离、采用异步处理和备份冗余,系统可以提升服务的可用性和稳定性。微服务、消息队列、负载均衡和异地多活等技术在提高高可用性中扮演了重要角色,确保服务在面对故障时仍能保持高效运行。
摘要由CSDN通过智能技术生成

什么是高可用

互联网应用是面向大众的应用系统,他们可能会随时会被使用,那么应用就必须要保持随时可用,也就是我们常说的7x24小时可用,但是互联网应用有可能会遇到硬件故障,软件故障等多种问题,可能导致服务的不可用,所以要想保证服务100%可用是一件几乎不可能实现的事情。所以业界通常用多少个9来说明互联网应用的可用性,比如说某宝的可用性4个9,4个9是说服务可用性是99.99%可用,也就是说某宝的服务可以实现在运行时间内只有0.01%不可用,换句话说,当遇到上述的故障后,可在0.01%的时间内解决。如果以年为运行时间单位的化,那么不可用时间就是53分钟(3652460*0.01%)不同应用的可用性差别主要就体现在面对各种故障时,高可用设计做的是否足够好。

目前系统架构设计方面常用的高可用设计方案主要有以下几种:解耦,隔离,异步,备份,重试,熔断,补偿,降级,限流,多活等。下面我们逐一讨论以下。

解耦

我们都知道系统耦合度过高时软件设计的万恶之源,也是造成系统可用性的罪魁祸首,以为一个高度耦合的系统,牵一发动全身,任何微小的改动都可能导致意想不到的bug和系统崩溃,连最基本的功能维护都很吃力,更别提什么高可用了。

看整个软件的进化史,就是一部软件开发解耦的历史,各种编程框架的出现也几乎都是为了同一个目标,使公用的基础技术开发和业务功能开发进行解耦,以Web服务器为例,它是HTTP协议处理与业务开发解耦,开发者不用关系网络通信协议的处理,只需要关注请求处理和相应对象构建即可。而我们常用的MVC框架进一步将视图逻辑和业务逻辑解耦,使前后端进一步分离。

常用的低耦合原则原则主要有两种:
组件的低耦合原则:无循环依赖原则,即技术组件之间不能循环依赖,不能 A 依赖 B,B 又依赖 A;稳定依赖原则,即被依赖的组件尽量稳定,尽量少因为业务变化而变化;稳定抽象原则,即要想使组件稳定,组件就要更加抽象。

面向对象的低耦合原则:开闭原则,即对修改封闭、对扩展开放,对象可以扩展新功能,但是不能修改代码;依赖倒置原则,即高层对象不能依赖低层对象,而是要依赖抽象接口,而抽象接口属于高层;接口隔离原则,不要强迫使用者依赖它们不需要的方法,要用接口对方法进行隔离。

隔离

如果说解耦是逻辑上的分割,那么隔离就是物理上的分割。即将低耦合的组件进行独立部署,将不同组件在物理上隔离开来。每个组件有自己独立的代码仓库;每个组件可以独立发布,互不影响;每个组件有自己独立的容器进行部署,互不干扰。所以,隔离就是分布式技术在业务上的应用,最常见的就是我们前面案例中也多次使用的微服务技术方案。微服务将一个复杂的大应用(单体架构系统)进行拆解,拆分成若干更细粒度的微服务,这些微服务之间互相依赖,实现原来大应用的功能逻辑。然后将这些微服务独立开发和发布,独立部署,微服务之间通过 RPC(远程过程调用)进行依赖调用,就是微服务架构。隔离使得系统间关系更加清晰,故障可以更加隔离开来,问题的发现与解决也更加快速,系统的可用性也更高。不过,还要强调一下,隔离必须在低耦合的基础上进行才有意义。如果组件之间的耦合关系千头万绪、混乱不堪,隔离只会让这种混乱更雪上加霜。

异步

异步可以认为是在隔离的基础上进一步解耦,将物理上已经分割的组件之间的依赖关系进一步切断,使故障无法扩散,提高系统可用性。异步在架构上的实现手段主要是使用消息队列。比如用户注册的场景。新用户提交注册请求后,需要给用户发送邮件,发送短信,保存数据库,还要将注册消息同步给其他产品等等。如果用微服务调用的方式,那么后续操作任何一个故障,都会导致业务处理失败,用户无法完成注册。使用消息队列的异步架构,新用户注册消息发送给消息队列就立即返回,后续的操作通过消费消息来完成,即使某个操作发生故障也不会影响用户注册成功。如下图:
在这里插入图片描述

备份

备份冗余,是解决高可用的最基本的手段,即一个服务部署在多个服务器上,一份数据冗余备份多份,当一个服务出现故障或者一份数据丢失,还有其他服务可以提供,还有其他数据提供支持。但是这里有一个比较重要的机制,就是故障转移,也就是,能够感知到服务故障,数据丢失后,将请求转发到其他服务上,访问访问其他数据。
常用的故障转移的手段是负载均衡,其实负载均衡不仅可以实现高可用,还是实现呢高性能的主要手段。在一个多备份的服务集群中,当一个服务出现故障后,通过负载均衡,可以将请求转移到其他健康的服务上,具体如下图:
在这里插入图片描述

由于应用服务器上只运行服务,不存储数据,通常来说这些服务都是无状态的,请求转发到集群中其他服务器上,处理结果是相同,对于存储数据的服务器,如数据库。互相备份的服务器之间要能通过数据同步保证数据的一致性。主从同步的示意图:
在这里插入图片描述

多活

多活,即异地多活,在多个地区建立数据中心,并都可以对用户提供服务,任何地区级的灾难都不会影响系统的可用。异地多活最极端的案例,是某应用准备将自己的服务器发射到太空,即使地球毁灭也能保证系统可用。异地多活的架构需要考虑的重点是,用户请求如何分发到不同的机房去。这个主要可以在域名解析的时候完成,也就是用户进行域名解析的时候,会根据就近原则或者其他一些策略,完成用户请求的分发。另一个至关重要的技术点是,因为是多个机房都可以独立对外提供服务,所以也就意味着每个机房都要有完整的数据记录。用户在任何一个机房完成的数据操作,都必须同步传输给其他的机房,进行数据实时同步。数据库实时同步最需要关注的就是数据冲突问题。同一条数据,同时在两个数据中心被修改了,该如何解决?某些容易引起数据冲突的服务采用类似 MySQL 的主主模式,也就是说多个机房在某个时刻是有一个主机房的,某些请求只能到达主机房才能被处理,其他的机房不处理这一类请求,以此来避免关键数据的冲突。

总结

上文介绍了高可用方案,在系统架构设计过程中的使用,对于高可用系统中,服务间交互过程中的高可用手段,我们放在下一篇文章高并发系统高可用设计方案(二)中讨论。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值