该文章转自： 搜狐文章 链接
 
谈到高并发和高可用往往引起很多人的兴趣，有时候成为框架选择的噱头。实际上，它们往往和框架关系不大，而是跟架构息息相关。在很多时候，老码农会直面一个问题：
 
“系统的服务可用性是多少?是怎么得来?”
 
 
但在思考这个问题之前，先要澄清一个概念，那就是——
 
什么是服务可用性
 
可用性就是一个系统处在可工作状态的时间的比例,这通常被描述为任务可行率。数学上来讲，相当于1减去不可用性。——wiki 百科
 
相应的，我们的软件系统处于可工作的时间比例，就是服务的可用性，也就是说，服务可用性可以描述为一个百分比的数值。我们经常用这个SLO(service-level objective ，服务级目标)来代表服务可用性，至于SLO，SLA，SLI 等概念之间的差异，这里暂不做深入讨论。
 
SLO用数字来定义可用性对于特定服务的意义，来表示服务几乎总是活着，总是处于可以快速运行的状态。制定SLO是根据如下:
 
绝大多数软件服务和系统的目标应该是近乎完美的可用性，而不是完美的可用性。服务可用性一般是99.999% 或99.99% ，而不是100%，因为用户无法区分服务是100% 可用和不“完美”可用之间的区别。在用户和服务之间还有许多其他的系统，例如笔记本电脑、家庭 WiFi、互联网等等 ，这些系统的可用性远远低于100% 。因此，99.99% 和100% 之间的边际差异在其他不可用性的噪音中丢失了，并且，即使为增加最后一部分可用性付出了巨大努力，用户也可能没有从中获得任何好处。
 
很多云服务的目标是向用户提供99.99% 的可用性(就是我们常说的“四个9”)。一些服务在外部承诺较低的数字，但在内部可能设定了99.99% 的目标。作为SLA，这个严格的目标描述了用户在违反合同之前对服务性能不满意的情况，因为软件服务的首要目标是让用户满意。对于许多服务，99.99% 的内部目标代表了平衡成本、复杂性和可用性的最佳位置。
 
服务可用性解读
 
服务可用性是中断频率和持续时间的函数。它是通过以下方式衡量的: * 停机频率，或者是它的倒数: MTTF (平均停机时间)。* 持续时间，使用 MTTR (平均修复时间)。持续时间根据用户的经历定义: 从故障开始持续到正常行为恢复。
 
因此，可用性在数学上定义为使用适当单位的 MTTF / (MTTF + MTTR)。
 
四个9的服务可用性可能是很多软件系统的目标，如何达到这一目标呢?需要先明确一下导致服务不可用的来源。服务不可用有两个主要来源: 服务本身的问题和服务的关键依赖的问题。关键依赖是指如果出现故障，就会导致服务相应故障的依赖项。
 
关键依赖
 
服务的可用性不能超过其所有关键依赖关系的交集。如果服务的目标是提供99.99% 的可用性，那么所有的关键依赖项必须远远超过99.99% 的可用性。据说在谷歌内部，使用这样一个经验法则: 因为任何服务都有几个关键依赖项，以及自身的特殊问题，关键依赖必须提供一个与服务相关的额外9% 的可用性(这里为99.999%) 。
 
如果有一个关键依赖，一个相对常见的挑战是没有提供足够的可用性，就必须采取措施来增加依赖项的有效可用性(例如，通过缓存、限流、优雅降级等等)。
 
降低期望
 
从数学上看，服务的可用性不能超过其事件频率乘以其检测和恢复时间。例如，每年有4次完全宕机，每次持续15分钟，结果总共是60分钟。即使该服务在这一年中剩下的时间里都运行良好，99.99% 的可用性(每年停机时间不超过53分钟)也是没有达的。
 
如果服务被依赖于无法提供相应水平的可用性级别，那么就应该努力纠正这种情况，可以通过增加自身服务的可用性等级，或者如前所述的增加缓解措施。降低期望值(即公布的可用性)也是一种选择，而且往往是正确的选择: 向相关服务明确表示，它应该重新设计系统以弥补我们服务可用性，或者降低自己的目标。如果不纠正或解决这种差异，可用性将无法达到要求。
 
服务可用性的计算
 
考虑一个目标可用性为99.99% 的示例服务，并处理依赖项和停机响应的需求。
 
一个例子
 
假设这个99.99% 的可用服务具有以下特征:
 
每年一次大停机和三次小停机。这些数字听起来很高，但是99.99% 的可用性目标确实意味着每年有20到30分钟的大范围停机和几次短暂的部分停机。这里的假设是: 单个分片的失败并不被认为是整个系统的失败，总体可用性是根据分片可用性的加权和来计算的。
有五个独立关键依赖， 服务可用性为99.999%。
这五个相互独立的碎片，不能相互转移。
所有变更逐个进行，每次一个分片。
那么，本年度服务中断的总预算为每年525,600分钟的的0.01%或53分钟(以每年365天为基础)。分配给关键依赖的服务中断预算是5个525,600分钟的0.001%，即525,600分钟的0.005% 或26分钟。考虑到关键依赖的服务中断，该服务的中断时间预算为53-26=27分钟。
 
进一步，预计停机次数为4次(1次完全停机，3次停机仅影响一个分片)， 预期服务中断的总影响: (1 x 100%) + (3 x 20%)= 1.6。那么，可用于检测和从中断恢复的时间为27 / 1.6 = 17分钟。如果监控和告警的时间是2分钟，值班人员调查警报的时间为5分钟的话，则有效解决问题的剩余时间是 10分钟。
 
提高可用性的方向
 
仔细研究这些数字，有三个主要的因素可以使服务更可靠。
 
透过流程、测试、设计review等手段，减少宕机的次数。
通过分片、地理隔离、优雅降级或客户隔离，缩小停机范围。
缩短恢复时间ーー透过监控、一键式回滚等。
可以在这三个方向之间进行权衡，以便实现更加容易。例如，如果17分钟的 MTTR 很难实现，那么应该将精力集中在减少平均停用的范围上。
 
服务可用性之依赖嵌套
 
一个不经意的推断，依赖链中的每个额外链接都需要增加额外的可用性等级么?例如，二级依赖需要两个额外的9，三级依赖需要三个额外的9，以此类推。
 
这种推论是不正确的，它基于依赖关系层次结构，即在每个级别上具有常量扇出的树 具有许多独立关键依赖的高可用性服务系统显然是不现实的。
 
无论在依赖项树中出现在哪里，关键依赖项本身都可能导致整个服务(或服务分片)失败。因此，如果给定的组件A表现为几个服务的依赖项，那么 A应该只计算一次，因为无论有多少中间的服务受到影响，A的故障终将导致服务的故障。
 
正确的依赖计算可能是这样的:
 
如果一个服务具有N个唯一的关键依赖项，那么每个依赖对服务导致的不可用性贡献1 / N，而不管它在层次结构中的深度如何。
即使它在依赖项层次结构中出现多次，每个依赖也只计算一次。
例如，假设服务b 的故障预算为0.01% 。服务拥有者愿意花一半的预算在他们自己的 bug 和损失上，另一半花在关键依赖上。如果服务有 N个这样的依赖项，每个依赖项接收剩余故障预算的1 / N。典型的服务通常有5到10个关键依赖项，因此每个服务的失败率只有服务b 的十分之一或二十分之一。因此，根据一般经验，服务的关键依赖项必须增加额外的可用性。
 
服务可用性之故障预算
 
一般地，使用故障预算来平衡可用性和创新速度。这个预算定义了在一段时间内(通常是一个月)服务可接受的故障水平。故障预算只是1减去服务的 SLO，因此，99.99% 可用的服务是故障为0.01% 的“预算”。只要服务没有花费当月的故障预算，开发团队就可以在合理范围内自由地发布新特性、更新等等。
 
如果使用了故障预算，除了紧急安全修复和解决最初导致违规的更改之外，服务可能将冻结变更。直到服务在预算中赢得了空间，或者时间重置。使用 SLOs 滑动窗口，因此故障预算逐渐增加。对于 SLO 大于99.99% 的成熟服务，每季度重置预算是适当的，因为允许的停机时间很小。
 
故障预算提供了一个共同的、数据驱动的机制来评估发布风险，从而消除了可能在运维团队和产品开发团队之间产生的结构性紧张。故障预算还提供了一个共同的目标，在不“超出预算”的情况下实现更快的创新和更多的发布。
 
提高服务可用性：减少关键依赖
 
现在，可以重点讨论服务的依赖关系，如何进行设计以减少并最小化关键依赖。
 
关于关键依赖
 
一般的，任何关键部件的可用性必须是整个系统目标的10倍。因此，在一个理想的世界中，目标是使尽可能多的组件成为非依赖的。这样做意味着组件可以坚持较低的可靠性标准，获得创新和承担风险的自由。
 
减少关键依赖性的最基本和最明显的策略是尽可能消除 SPOFs (单点故障)。较大的系统应该能够在没有任何非关键依赖项或 SPOF 的给定组件的情况下可以可接受地运行。
 
实际上，您可能无法摆脱所有关键的依赖关系，但是您可以遵循一些围绕系统设计的最佳实践来优化可靠性。虽然这样做并不总是可行的，但是如果你在设计和规划阶段计划可靠性，而不是在系统运行并影响实际用户之后，那么实现系统可靠性就会更容易和更有效。
 
当考虑一个新的系统或服务时，当重构或改进一个现有系统或服务时，一个架构/设计评审可以识别出内部与外部的依赖。如果服务使用的是共享基础设施(例如，多个用户可见产品使用的基础数据库服务) ，要考虑该基础设施是否得到正确使用。明确地将共享基础结构的所有者确定为附加的利益相关者。另外，要注意不要让依赖关系超载，小心地与这些依赖关系的所有者协调工作。
 
有时，产品或服务取决于公司无法控制的因素，例如，代码库、第三方提供的服务或数据，要识别这些因素可以减少它们带来的不可预测性。
 
冗余和隔离
 
通过将依赖设计为具有多个独立实例来减轻对关键依赖的依赖。例如，如果在一个实例中存储的数据提供了该数据99.9% 的可用性，那么在三个分布的实例中存储三个副本提供了9个9的理论可用性级别。
 
在现实世界中，相关性永远不会为零，因此实际可用性不会接近9个9，而是远远高于3个9。如果一个系统或服务是“广泛分布的” ，地理上的分离并不总是不相关的。在邻近地点使用多个系统，可能比在较远地点使用同一个系统更好。
 
类似地，向一个集群中的一个服务器池发送 RPC可以提供99.9% 的可用性，但是向三个不同的服务器池发送三个并发 RPC 并接受到达的第一个响应，这样有助于将可用性提高到远远超过三个9的级别。如果服务器池与 RPC 发送方的距离大致相等，那么这种策略还可以减少延迟。
 
故障切换与回滚
 
一个的基本经验是，当必须人工在线引发故障切换时，可能已经超出了故障预算。最好进行故障的安全切换，如果出现问题，这些软件可以自动隔离。在无法实现的情况下，可以执行自动脚本。同样，如果问题依赖于某一个人来检查，那么满足SLO 的机会会很小。
 
将人引入缓解计划大大增加了 SLO 的风险，需要构建方便、快速而可靠回滚的系统。随着系统逐渐成熟，并且对检测问题的监视获得了信心，就可以通过设计系统自动触发安全回滚来降低 MTTR。
 
在可能的情况下，将依赖项设计为异步的，而不是同步的，这样它们就不会意外地变得非常重要。如果服务等待来自其非关键依赖项之一的 RPC 响应，并且该依赖项的延迟会大大增加，那么这种延迟将不必要地影响父服务的延迟。通过将 RPC 调用设置为非关键的异步依赖项，可以将父服务的延迟与依赖项的延迟解耦。虽然异步性可能会使代码和基础结构复杂化，但这种权衡可能是值得的。
 
检查所有可能的失效模式
 
检查每个组件和依赖项，并确定其故障的影响。以下问题可能是一些方向:
 
如果其中一个依赖项失败，服务能否继续以降级模式提供服务?换句话说，为优雅的降级而设计。
如何处理在不同情况下依赖项不可用的问题?在服务启动时?在运行期间?
设计和实现一个健壮的测试环境，确保每个依赖项都有自己的测试覆盖率，并且使用专门针对环境的用例进行测试。以下是一些推荐的测试策略:
 
使用集成测试执行故障注入ーー验证系统能否在任何依赖关系发生故障时幸存下来。
进行灾难测试以识别弱点或隐藏的依赖关系。记录后续行动，以纠正发现的bug。
故意让系统过载，看看它是如何退化的。无论如何，系统对负载的响应都将被测试; 最好是自己执行这些测试，而不是将负载测试留给用户。
容量规划
 
确保每个依赖项都得到了正确的供给，如果成本可以接受，就过度供给。如果可能，将依赖项的配置标准化，以限制子系统之间的不一致性，并避免一次性的故障模式。
 
检测、故障排除和诊断问题要尽可能简单，有效的监测是能够及时发现问题的关键组成部分。诊断具有严重依赖关系的系统是困难的，但总是有一个不需要操作员就可以减轻故障的方案。
 
期待随着规模而来的变化，当在一台机器上以二进制文件开始的服务在更大的规模上部署时，可能会有许多明显或不明显的依赖关系。每一个规模的数量级都会暴露出新的瓶颈， 不仅仅是自己服务，还有所依赖的服务。考虑一下，如果依赖项不能像所需要的那样快速扩展，将会发生什么。
 
还要注意，系统依赖关系会随着时间的推移而发展，并且依赖关系的列表可能会随着时间的推移而增长。在基础设施方面，一个典型的设计是建立一个不需要重大变更就可以扩展到初始目标负载10倍的系统。
 
结束语
 
服务的可用性并不高深莫测，它只是一个百分比的数字。服务可用性的指标(例如99.99%)往往令人不安，但并非不可实现。提供超过四个9的服务可用性，不是通过超出常人的智慧，而是通过不断地完善规则形成最佳实践，并且全面应用。

 
可用性99.9 内容精选
 
换一换
 

 
云数据库 RDS服务支持切换主备实例的可用性策略，以满足不同业务需求。可选择 “可靠性优先”或者“可用性优先”两种策略。调用接口前，您需要了解API 认证鉴权。该接口仅支持MySQL引擎。仅支持主备实例，即：HA实例。实例在创建、数据库升级、创建用户、删除用户状态下不能进行此操作。URI格式PUT /v3/{project_id}/ins
 
指标项名称：KerberosAdmin服务可用性指标项含义：系统对KerberosAdmin服务状态进行检查，如果检查结果不正常，则KerberosAdmin服务不可用。恢复指导：如果该指标项检查结果不正常，原因可能是KerberosAdmin服务所在节点故障，或者SlapdServer服务不可用。操作人员进行KerberosAdmin服
 
可用性99.9 相关内容
 
分析云上业务的资源分布情况，识别云服务高可用、云服务部署实践、云服务使用限制3个方面的风险，提供针对性的优化建议。云服务高可用：聚焦云服务可用区(AZ)内高可用设计，业务设计为主备、集群等方式。云服务部署实践：侧重云服务部署，包括云服务资源规格选型、云服务使用方式等。云服务使用限制：列举云服务使用限制，包括云服务资源配额、带宽限速等。包年
 
虚拟IP(Virtual IP Address，简称VIP)是一个未分配给真实弹性云服务器网卡的IP地址。弹性云服务器除了拥有私有IP地址外，还可以拥有虚拟IP地址，用户可以通过其中任意一个IP(私有IP/虚拟IP)访问此弹性云服务器。同时，虚拟IP地址拥有私有IP地址同样的网络接入能力，包括VPC内二三层通信、VPC之间对等连接访问，以
 
可用性99.9 更多内容
 

 
NAT网关后台已通过双机热备实现自动容灾，同时为用户提供云监控和告警服务，降低风险提高可用性。
 

 
指标项名称：KerberosAdmin服务可用性指标项含义：系统对KerberosAdmin服务状态进行检查，如果检查结果不正常，则KerberosAdmin服务不可用。恢复指导：如果该指标项检查结果不正常，原因可能是KerberosAdmin服务所在节点故障，或者SlapdServer服务不可用。操作人员进行KerberosAdmin服
 

 
本章节指导用户如何查看站点的监控数据，从可用性、响应时间、可用探测点等趋势来展示当前站点的访问情况。登录管理控制台。单击“服务列表 > 云监控服务”。单击左侧导航栏的“站点监控”。进入“站点监控”界面。系统展示用户当前所有站点概况。包括站点名称、站点地址、探测类型、监控频率、可用探测点百分比、平均响应时间等。进入“站点监控”界面。系统展示
 

 
许多企业已经在公有云上部署了SAP HANA系统来运行它们的业务，为了保障SAP业务的连续性，SAP解决方案所提供的高可用(HA)和容灾(DR)方案是这些企业选择云上部署的重要因素。除了SAP软件本身提供的高可用机制外，公有云自身的高可用与容灾方案进一步加强了包括SAP在内的许多应用程序的高可用性，云端高可用跟传统高可用相比，有如下的优点
 

 
许多企业已经在公有云上部署了SAP HANA系统来运行它们的业务，为了保障SAP业务的连续性，SAP解决方案所提供的高可用(HA)和容灾(DR)方案是这些企业选择云上部署的重要因素。除了SAP软件本身提供的高可用机制外，公有云自身的高可用与容灾方案进一步加强了包括SAP在内的许多应用程序的高可用性，云端高可用跟传统高可用相比，有如下的优点
 

 
虚拟IP(Virtual IP Address，简称VIP)是一个未分配给真实弹性云服务器网卡的IP地址。弹性云服务器除了拥有私有IP地址外，还可以拥有虚拟IP地址，用户可以通过其中任意一个IP(私有IP/虚拟IP)访问此弹性云服务器。同时，虚拟IP地址拥有私有IP地址同样的网络接入能力，包括VPC内二三层通信、VPC之间对等连接访问，以
 

 
CSE采用的是ETCD和golang自研的API-Server层服务管理中心。与仅仅管理路由动态数据的Eureka不同，CSE的服务管理中心提供了对静态元数据丰富的管理能力，例如提供了“应用-服务-实例”的整体元数据管理，基于服务的不同版本管理和Tag管理以支持灰度发布功能，根据服务发现的动作记录服务依赖关系等等。在Eureka仅仅管理动
 

 
应用原理：在一个高并发的复杂事务型系统中，当写事务占的比例相对读事务较小时，DM提供的独具创新的方案读写分离集群方案(DMRWC)，可通过客户端驱动程序来实现读、写事务的自动分离，读事务在备机执行，写事务在主机执行，减轻主机的负载。可配置多台备机，通过增加备机节点资源，提高系统的并发能力，增强系统性能。场景典型参考架构：场景特点：具有复杂
 

 
通过该功能查看网点报告，包括总览、网点统计、告警统计信息。
 

 
Kudu是专为Apache Hadoop平台开发的列式存储管理器，具有Hadoop生态系统应用程序的共同技术特性：在通用的商用硬件上运行，可水平扩展，提供高可用性。Kudu的设计具有以下优点：能够快速处理OLAP工作负载支持与MapReduce，Spark和其他Hadoop生态系统组件集成与Apache Impala的紧密集成，使其成为将
 

 
YARN中的ResourceManager负责整个集群的资源管理和任务调度，在Hadoop2.4版本之前，ResourceManager在YARN集群中存在单点故障的问题。YARN高可用性方案通过引入冗余的ResourceManager节点的方式，解决了这个基础服务的可靠性和容错性问题。ResourceManager的高可用性方案是通过设

SLA：服务等级协议（简称：SLA，全称：service level agreement）。是在一定开销下为保障服务的性能和可用性，服务提供商与用户间定义的一种双方认可的协定。通常这个开销是驱动提供服务质量的主要因素。
 
SLA的定义来源百度，这到底是什么意思呢？
 
 
 
我们平常经常看到互联网公司喊口号，我们今年一定要做到3个9、4个9，即99.9%、99.99%，甚至还有5个9，即99.999%。
 
 
这么多9代表什么意思呢？
 
首先，SLA的概念，对互联网公司来说就是网站服务可用性的一个保证。9越多代表全年服务可用时间越长服务更可靠，停机时间越短，反之亦然。
 
这么多9是怎么计算的呢？
 
全年拿365天做计算吧，看看几个9要停机多久时间做能才能达到！
 
1年 = 365天 = 8760小时

99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小时

99.99 = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟

99.999 = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟
 
从以上看来，全年停机5.26分钟才能做到99.999%，即5个9。依此类推，要达到6个9及更多9，可说是非常难了吧。
 
怎么做到更多的9
 
每个公司对几个9的定义都不一样，互联网公司至少都是99.99吧。像一些政府网站，如社保公积金等，经常故障服务不可用，能做到99.9就不错了。
 
如果我们提供的服务可用性越低，意味着造成的损失也越大，别的不说，如果是特别重要的时刻，或许就在某一分钟，你可能就会因服务不可用而丢掉一笔大的订单，这都是始料未及的。所以，只要尽可能的提升SLA可用性才能最大化的提高企业生产力。
 
要做到更多的9，就要不断的监控自己的服务，服务挂掉能及时恢复服务。就像开车出远门，首先得检查轮胎，同时还得准备一个备胎一样的道理。

 
简单区分
 
从事故、稳定方面简单理解如下：
 
名词
 
简单理解
 
可靠性
 
不出事故
 
可用性
 
不出事故 出事故后，快速止损
 
ddd-
 
-
 
稳定性
 
解决故障问题基础上 服务持续稳定、性能稳定
 
总体对比
 
可用性
 
可靠性
 
稳定性
 
英文
 
Availability
 
Reliability
 
Stability
 
关注点
 
关注的是服务总体的持续时间。
 
系统在给定时间内总体的运行时间越长，可用性越高。
 
关注系统可以无故障地持续运行的概率，关注的是故障率。
 
故障的频率越高，可靠性越低。
 
影响可靠性的因素就是能够引起故障的所有因素，包括软件设计错误，编码错误，硬件故障等等。
 
指软件在一个运行周期内、在一定的压力条件下，在持续操作时间内出错的概率，性能劣化趋势等等。
 
如果一个系统的性能时好时坏，它一定是不稳定的，而不一定是不可靠的。
 
稳定性更关注系统在给定条件下的响应是否一致，行为是否稳定。
 
可靠是可用的前提，稳定是可靠的进一步提升。
 
对比
 
在《分布式系统原理与范型》中提到的下面例子中比较准确的解释了两者的区别：
 
如果系统在每小时崩溃1ms，那么它的可用性就超过99.9999%，但是它还是高度不可靠。
 
与之类似，如果一个系统从来不崩溃，但是每年要停机两星期，那么它是高度可靠的，但是可用性只有96%。
 
作为系统的响应，首要目标是先降低故障的次数，频率要低，从而提高可靠性；
 
同时在故障出现后，要提高故障的恢复时间，速度要快，从而提高业务的可用性。
 
对比
 
对于电力系统而言，
 
稳定性就是“人民用电不要忽明忽暗忽快忽慢”，可靠性就是”不要用着用着突然没有啦“。
 
-知乎盛夏白日梦
 
故障与出错的差别
 
可用性
 
可用性指系统在给定时间内可以正常工作的概率，通常用SLA(服务等级协议，service level agreement)指标来表示。
 
这是这段时间的总体的可用性指标。
 
通俗叫法
 
可用性级别
 
年度宕机时间
 
每天宕机时间
 
1个9
 
90%
 
36.5天
 
2.4小时
 
2个9
 
99%
 
87.6小时
 
14分钟
 
3个9
 
99.9%
 
8.76小时
 
86秒
 
4个9
 
99.99%
 
52.6分钟
 
8.6秒
 
5个9
 
99.999%
 
5.26分钟，315.36秒
 
0.86秒
 
可靠性
 
可靠性相关的几个指标如下：
 
MTBF(Mean Time Between Failure)
 
即平均无故障时间，是指从新的产品在规定的工作环境条件下开始工作到出现第一个故障的时间的平均值。
 
MTBF越长表示可靠性越高，正确工作能力越强 。
 
MTTR(Mean Time To Repair)
 
即平均修复时间，是指可修复产品的平均修复时间，就是从出现故障到修复中间的这段时间。
 
MTTR越短表示易恢复性越好。
 
MTTF(Mean Time To Failure)
 
即平均失效时间。系统平均能够正常运行多长时间，才发生一次故障。
 
系统的可靠性越高，平均无故障时间越长。
 
这些指标跟可用性关系
 
稳定性
 
Stackoverflow 看到这样一段代码来表示稳定性和可靠性的区别，甚为有趣：
 
参考：