架构师速成8.3-可用性-阿里云开发者社区

开发者社区> 开发与运维> 正文

架构师速成8.3-可用性

简介: 作为一个软件系统可用性是第一位的,如果一个系统不可用,你其他的地方做的再怎么好,然并卵。 一般什么情况下软件会不可用: 我方发生故障,导致系统不可用,当然会出现单机的不可用及n多机器群的全部不可用。 程序故障 功能错误、程序退出 系统故障 CPU超负荷、内存超负荷、网络超负荷 物理故障  机器死机 断电 断网 不可恢复故障 地震、海啸等等 客户方也会发生相同故障,

作为一个软件系统可用性是第一位的,如果一个系统不可用,你其他的地方做的再怎么好,然并卵。

一般什么情况下软件会不可用:

我方发生故障,导致系统不可用,当然会出现单机的不可用及n多机器群的全部不可用。

  1. 程序故障 功能错误、程序退出
  2. 系统故障 CPU超负荷、内存超负荷、网络超负荷
  3. 物理故障  机器死机 断电 断网
  4. 不可恢复故障 地震、海啸等等

客户方也会发生相同故障,导致系统不可用,当然会出现个别用户的不可用及区域性用户均不可用。

对于我方发生的问题,我们必须通过架构的方式进行解决,对于客户方发生的问题,我们尽量找方法解决,先解决区域性问题,再解决个别用户问题。解决方案必须要考虑到成本及战略来进行取舍,比如创业初期,根本没有大量资金,要解决不可恢复故障基本不太可能。

我们先试图从架构的方式来解决我方发生的故障,这种解决方案类似于设计模式,故称之为架构模式。

针对单机的不可用,有一个专业术语叫做单点故障,最好的方式就是部署多机器,通过多机器负载均衡,来规避单点故障。

  1. 分布式
  2. 负载均衡

针对多机的不可用,我们需要分类看如何解决:

  1. 程序故障 功能错误、程序退出,这种错误有同学说,可以加单元测试、功能测试,让测试来发现问题。是的,但是那是开发流程,我们先不讨论那个,我们从架构的角度讨论,主要的解决方案如下:
    • 分批自动化发布
    • 灰度发布
    • 异常监控
  2. 系统故障 CPU超负荷、内存超负荷、网络超负荷
    • 流量控制
    • 功能降级
    • 动态扩容
    • 异常监控
  3. 物理故障  机器死机 断电 断网
    • 异地多活
    • 异地热备or冷备
    • 异地数据同步
  4. 不可恢复故障 地震、海啸等等
    • 同上

后面我会针对每个专题跟大家仔细讲解。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章