云原生服务高可用性保持的简单思考

本文探讨了云原生技术发展中的高可靠性和高可用性挑战,尤其是微服务架构带来的复杂性。强调了底座服务的重要性及其对整体高可用性的影响,提出了混沌工程、监控和去中心化架构作为应对策略,同时提及了阿里云RAM故障引发的问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

从云计算到云原生,从IaaS到PaaS,从资源层到服务层,当前整个云平台的高可靠、高可用性本质上是越来越复杂的。

同样的,随着云原生的深入,从传统的单体应用到目前主流的微服务架构,总体服务的高可靠、高可用的维持也越发艰难。
从本质上来说,单体服务拆分为一个个微服务是云原生阶段的重要特征,但这种拆分往往带来的是可扩展性方面的提升:

  • 从某种程度上来说,高可靠与高扩展是相互矛盾的,类似于CAP理论中的不可能三角。

虽然在微服务架构下,由于容灾降级等方案的存在,某一个微服务出现故障宕机时不会影响其他的微服务,但随着云原生技术的不断发展演进,业界也更加强调平台+应用、强调云原生技术底座、强调各种共性技术服务能力的共享——诸如消息中间件与缓存(DMS)、安全(SEC)、数据库(RDS)、认证系统(IAM)、网关(APIG)等等。

我们可以看到,即使我们做了微服务拆分,但其底层所依赖的底座却越来越重、依赖性也越来越高。
一旦底座服务出现影响,那么上层所有的微服务均会收到影响。因此,对于我们整个底座的高可用性要求就会越来越高。

针对这种风险,除了实践混沌工程模拟可能出现的现网故障、完善监控等手段外,在去中心化架构下强调控制面与数据面进行分离也是方法之一,但也未必保险:

正如最近阿里云发生的P0级别故障,本质上来说是RAM(Resource Access Management,访问控制)出现了故障,虽然其本质上属于控制面,但长时间故障+高实时性要求,同样会引发大规模的数据面问题。

当然了,时代不能回头、技术也不能退化,这一切都只会“驰骋”在云原生的战车一路狂奔。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值