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

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

我方发生问题。导致系统不可用。当然会出现单机的不可用及n多机器群的所有不可用。

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

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

对于我方发生的问题，我们必须通过架构的方式进行解决。对于客户方发生的问题。我们尽量找方法解决。先解决区域性问题。再解决个别用户问题。

解决方式必需要考虑到成本及战略来进行取舍。比方创业初期。根本没有大量资金，要解决不可恢复故障基本不太可能。

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

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

1. 分布式
2. 负载均衡

针对多机的不可用，我们须要分类看怎样解决：

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

后面我会针对每一个专题跟大家细致解说。