谈到高并发和高可用往往引起很多人的兴趣, 有时候成为框架选择的噱头. 实际上, 它们往往和框架关系不大, 而是跟架构息息相关. 在很多时候, 老码农会直面一个问题:
"系统的服务可用性是多少? 是怎么得来?"
但在思考这个问题之前, 先要澄清一个概念, 那就是 --
什么是服务可用性
可用性就是一个系统处在可工作状态的时间的比例, 这通常被描述为任务可行率. 数学上来讲, 相当于 1 减去不可用性.--wiki 百科
相应的, 我们的软件系统处于可工作的时间比例, 就是服务的可用性, 也就是说, 服务可用性可以描述为一个百分比的数值. 我们经常用这个 SLO(service-level objective , 服务级目标)来代表服务可用性, 至于 SLO,SLA,SLI 等概念之间的差异, 这里暂不做深入讨论.
SLO 用数字来定义可用性对于特定服务的意义, 来表示服务几乎总是活着, 总是处于可以快速运行的状态. 制定 SLO 是根据如下:
绝大多数软件服务和系统的目标应该是近乎完美的可用性, 而不是完美的可用性. 服务可用性一般是 99.999% 或 99.99% , 而不是 100%, 因为用户无法区分服务是 100% 可用和不 "完美" 可用之间的区别. 在用户和服务之间还有许多其他的系统, 例如笔记本电脑, 家庭 Wi-Fi, 互联网等等 , 这些系统的可用性远远低于 100% . 因此, 99.99% 和 100% 之间的边际差异在其他不可用性的噪音中丢失了, 并且, 即使为增加最后一部分可用性付出了巨大努力, 用户也可能没有从中获得任何好处.
很多云服务的目标是向用户提供 99.99% 的可用性(就是我们常说的 "四个 9"). 一些服务在外部承诺较低的数字, 但在内部可能设定了 99.99% 的目标. 作为 SLA, 这个严格的目标描述了用户在违反合同之前对服务性能不满意的情况, 因为软件服务的首要目标是让用户满意. 对于许多服务, 99.99% 的内部目标代表了平衡成本, 复杂性和可用性的最佳位置.
服务可用性解读
服务可用性是中断频率和持续时间的函数. 它是通过以下方式衡量的: * 停机频率, 或者是它的倒数: MTTF (平均停机时间).* 持续时间, 使用 MTTR (平均修复时间). 持续时间根据用户的经历定义: 从故障开始持续到正常行为恢复.
因此, 可用性在数学上定义为使用适当单位的 MTTF / (MTTF + MTTR).
来源: http://zhuanlan.51cto.com/art/202003/612119.htm