大家好，又见面了，我是你们的朋友全栈君。
系统高可用面临的挑战有哪些?
1.资源不可用
在实际业务中,出现资源不可用的原因种类可能很多,有的概率很低,比如网线被挖断了,机房失火,地震等等导致网络不可用,有的概率相对来说很高比如服务器硬件资源不足,服务器故障等等。这些问题都可能会导致对应的资源不可用。
2.资源不均衡
由于系统架构设计的时候没有针对高并发和大流量进行可伸缩设计,导致无法应对并发很大的场景,出现系统瘫痪甚至崩溃。
3.节点功能异常
这种情况是最常见的,由于代码是人写的,bug和漏洞都是难免的,所以在实际业务中大概率会出现功能节点异常的问题。同时系统引入的一些第三方库或者中间件当中也有可能包含一些问题,会导致节点功能异常。
解决问题的思路和策略
1.尽可能避免问题发生
避免问题发生是最直接的解决思路,比如我们可以通过UPS(Uninterruptible Power System)来避免服务器断电。可以引入移动、电信两条网线,来避免由于运营商网络问题导致的服务器不可用。通过实现机房异地部署,防止由于地震等自然灾害导致的服务器不可用。增加冗余的机器,避免在特殊场景下资源不足的问题。
2.发生问题之后能实现故障迁移
通过实现服务和服务器的冗余部署,确保在某个节点出现问题之后,能够实现功能的平滑过渡,不会由于某个服务或者节点故障导致系统不可用。
3.降低故障对业务的影响
如果故障无法以正面的方式解决，我们就要努力降低故障带来的影响。流量太大的时候，我们可以通过限流，来保证部分用户可以正常使用,或者说通过对一些非核心业务进行降级处理,保证核心业务的可用性。
4.发生故障之后能够实现快速恢复
可以通过监控系统快速定位到故障节点，然后修复故障节点，使系统恢复到正常状态。
高可用方案的架构原则和方案
1.系统冗余无单点
确保系统的各个服务节点都是有冗余的,当一个节点出现问题的时候能切换到备用节点,保障系统的可用性。保障网络的可用性,也可以引入多条线路(如接入移动和联通两条线路),一条线路出问题的时候切换到备用线路。很多直播软件为了保障运行,就会接入多条线路。数据库也可以通过主库和从库的设计,实现数据库的冗余,提升可靠性。对于一些对可用性要求高的软件,会实现机房的异地冗余部署,避免由于地震等自然灾害导致的服务不可用。
2.支持水平扩展,可伸缩
为了应对大流量和高并发的出现,系统的各个节点需要是可伸缩的,支持水平扩展。可以通过Ngnix,将请求和压力分流到多台机器上,实现硬件机器的扩展。同时可以在每台机器上运行更多的服务实例,应对海量请求。也可以引入CDN,将部分静态资源放到CDN上,降低服务端的带宽压力。
3.系统可以进行降级操作
在服务器资源不够用的时候,为了保障运行,通常采用的手段有降级、限流和熔断。
降级: 比如双11的时候为了应对短时间内的高并发,淘宝就会暂时关闭部分非核心功能比如评论、返积分等来保障核心业务的正常运行。
限流:我们也可以通过设置Ngnix的并发数,进行限流操作,保障部分用户的正常业务,拒绝其它的请求,防止由于短时间的高并发引起系统瘫痪。
熔断: 当某个服务出现异常的时候,直接关闭该服务,在请求链路中绕过该服务,在后续服务正常之后再进行补偿操作。
4.允许出现状态差异的中间态
在高并发的场景下,很多时候为了提高系统可用性,会出现状态不一致的问题,比如修改状态保存到了缓存中而并没有落到数据库里,此时读取数据库的时候会出现状态不一致。系统应该允许出现暂时的状态不一致,只要能保证状态最终一致即可
5.完善的系统监控体系
完善的监控体系对于系统提前预警和问题排查定位以及修复问题之后的快速恢复都是很关键的。通过监控系统,我们可以实时诊断当前系统的运行状态怎么样。
高可用架构的落地实践
1.通过引入两条网络线路,一主一备保障网络的高可用
2.负载均衡层进行双节点和Keepalived部署,当一个节点出问题的时候,切换到另一个节点上保障负载均衡的高可用。
3.负载均衡层通过设置并发数进行限流设置。
4.Web应用节点多节点部署,可根据需求进行伸缩扩展。同时负载均衡层通过路由切换对应的Web应用,当一个节点出问题的时候,快速切换到正常的节点上。
5.后台业务服务是无状态的可以进行多节点部署,可以根据需要进行伸缩扩展。并且当某个节点出问题之后,可以进行熔断操作,在调用链路中绕过对应的节点。
6.数据库通过读写分离分库分表,降低数据库的访问压力。
7.通过对数据库进行主从配置,当主库出问题的时候,从库马上顶上,确保数据访问的高可用。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/158684.html原文链接：https://javaforall.cn
