系统不可用的原因和解决方案
一、系统不可用的原因
硬件故障
软件bug
系统发布
并发压力
网络攻击
外部灾害
二、解决方案
解耦
高内聚、低耦合的组件设计原则
面向对象的基本设计原则
面向对象设计模式
领域驱动设计模型
隔离
业务与子系统隔离
微服务与中台架构
生产者消费者隔离
虚拟机与容器隔离
异步
多线程编程
反应式编程
异步通讯网络编程
事件驱动异步架构
备份
集群设计
数据库复制
Failover(失效转移)
数据库主主失效转移
负载均衡失效转移
如何确认失效,需要转移呢?设计无状态的服务
幂等
应用调用服务失败后,会将调用请求重新发送到其它服务器,但是这个失败可能是虚假的失败。比如服务器已经处理成功,但是因为网络故障引用没有收到响应,这是应用重新提交请求就导致服务重复调用,如果这个服务是一个转账操作,就会产生严重后果。
服务重复调用有时候是无法避免的,必须保证服务重复调用和调用一次产生的结果相同,即服务具有幂等性。有些服务天然具有幂等性,比如将用户性别设置为男性,不管这只多少次,结果都一样。但是对于交易操作,问题就会比较复杂,需要通过交易编号等信息进行服务低啊用有效性校验,具有有效的操作才继续执行。
事务补偿
传统的ACID
分布式事务的BASE
事务补偿:通过执行业务逻辑逆操作,是事务回滚到事务前状态
重试
远程服务可能会由于线程阻塞、垃圾回收或者网络抖动,而无法及时返还响应,调用者可以通过重试的方法修复单次调用的故障。
熔断
当某个服务出现故障,响应延迟或者失败率增加,继续调用这个服务会导致调用者请求阻塞,资源消耗增加,进而出现服务级联失效,这种情况下使用断路器阻断对故障服务的调用。
断路器的三种状态:关闭,打开,半开
Spring Cloud断路器是实现:Hystrix
限流
在高并发场景下,如果系统的访问量超过了系统的承受能力,可以通过限流对系统进行保护。
限流的几种算法:
计算器算法
令牌桶算法
漏桶算法
降级
在高并发的时候,比如说想淘宝双11的时候,当天可能整天系统都处于一种极限的高并发访问压力之下,这时候就可以将系统确认收货、评价这些非和兴的功能关闭,将宝贵的系统资源留下来,给正在购物的人,让他们去完成交易。
异地多活
如果整个数据中心都不可用,比如说数据中心所在的城市遭遇了地震,机房遭遇了火灾或者停电,这样的话,不管我们的设计和系统多么的高可用,系统依然是不可用的。
为了解决这个问题,同时为了提高系统的处理能力和改善用户体验,很多大型互联网应用都采用了异地多活的多机房架构策略,也就是说将数据中心分布在多个不同地点的机房里,这些机房都可以对外提供服务,用户可以连接任何一个机房进行访问,这样每个机房都可以提供完整的系统服务,即使某一个机房不可使用,系统也不会宕机,依然保持可用。 难点:数据一致性的问题。
评论