架构师速成8.3-可用性

标签：

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

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

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

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

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

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

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

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

1. 分布式
2. 负载均衡

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

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

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

架构师速成8.3-可用性

标签：

原文地址：http://blog.csdn.net/for5million/article/details/47333981