咳咳，从这篇文章开始，我正式开启分布式系统的关注点，我认为第二重要的内容——“高可用”。本文的主要观点是厘清“高可用”的定义，理解分布式系统中哪些环节应该是“高可用”，为后面要讲的策略和方法打下基础。如果你有超过1年的分布式系统实践经验，可以酌情选择跳过本文。Tips：“highXX”中的“high”其实是相对的，越符合预期，就越“high”。1、“高可用”的作用是什么？首先，统一对“高可用”的理解。打个通俗的比方：独生子女时代的孩子就是“单体应用”。万一出了什么事，父母就会“失去独生子女”，整个家族的传承也就断了，“没法用”了。而二胎政策就是通过分配（冗余）来降低出现这个问题的概率，从而提高“可用性”。对于“高可用性”，专业的解释是：“高可用性”是指通过最大限度地减少日常维护操作（计划内）和系统突然崩溃（计划外）导致的停机时间，来提高系统和应用程序的安全性。可用性。——百度百科总之，无论发生什么情况（即使是地震、洪水），用户尽可能没有感觉的情况下，仍然可以正常使用系统，也就是越“高可用”。为什么要在“数据一致性”之后再谈“高可用”？我的理解是，分布式系统的关键是冗余，而冗余的最大敌人是“数据一致性”。我们通过裁员打破了原来的瓶颈，开辟了一些新的渠道。例如，您可以争取更高的可用性、更高的性能等。但其中又以“高可用”最为重要。从上面引文中的解释也可以看出，为了尽可能减少宕机时间，单体应用的天花板总是会来得更快。这就像让一台电脑永远运行是很困难的。这期间，操作系统要更新好几次，硬件故障也突然发生好几次，连机房的光纤都被剪断了！那么此时就处于“不可用”状态。因此，我认为“高可用性”的价值或意义一定是在我们做分布式系统所获得的其他好处之上，比如“高性能”。因为，在一定范围内，所谓的“高性能”实际上可能通过对单个应用的优化来达到一定的预期值，但“高可用”则必须依靠分布式系统来实现。2、如何衡量“高可用性”一般我们谈得最多的就是用ServiceLevelAgreement来衡量高可用性指标，简称SLA。但其本义是指网络服务提供商与客户之间的合同，其中定义了服务类型、服务质量和客户付款等条款，其中还包括除“有效工作时间”之外的其他概念，如带宽、时间到服务就绪（RFSD）、平均无故障时间（MTBF）、平均恢复服务时间（MTRS）、平均修复时间（MTTR）等。最初，SLA主要用于电信运营商等基础设施提供的服务，以就用户可以享受的级别和带宽服务达成一致，等等。SLA的完整定义要复杂得多。在软件系统中，主要取“有效工作时间”部分。只要系统能够提供服务，我们就可以说系统的可用性是100%，但这只是一种理想状态。如果系统每运行100个时间单位，就会有1个时间单位不能提供服务，我们说系统的可用性是99%。贴一张常见的表图：如今，我们的生活越来越依赖于移动互联网的一些应用。假设支付宝挂了几个小时。付不起了，你慌了吗？不过相对来说，也可以想当然的理解，只要你用的时候我能保证系统可用，那么对外宣传也可以“高可用”。这也是为什么很多企业内部的C/S结构的信息系统在Internet普及之前还能正常使用的原因。例如，银行会在非营业时间更新系统，所以对于服务窗口的营业员来说，系统是不可用的，因为我当时不需要使用它。3、“高可用”的本质做“高可用”可以用一句话来概括：更快地发现故障，更快地隔离故障。任何对这两点有帮助的工作都是我们所做的。做任何事情都有主次之分，高可用的“主要”是“负载均衡”。在之前的文章中多次提到，分布式系统的关键是冗余，那么让这些冗余发挥“高可用”作用的就是“负载均衡”。因此，这是最基本的，也是迈向“高可用”的第一步。其他措施基于“负载平衡”。“负载均衡”的作用是一个“连接器”，让上下游按照我期望的方式“连接”起来。因此，有必要了解这些上下游的全貌，找出哪些地方需要做“负载均衡”。分布式系统有各种各样的架构，但本质上都是像上图这样的分层架构。图中红点标记的地方就是我们需要做“负载均衡”的地方。可以看到，就是每两层之间的连接。当这些连接真正在做“负载均衡”的时候，需要结合它们所在的网络层级。因为不同的网络层级有不同的做法。如下所示。一般主流的四层负载均衡和七层负载均衡，前者指的是传输层，涉及的主要协议有TCP、UDP等，后者指的是应用层，涉及的主要协议有Http、Https和FTP等。实现“负载均衡”的方案有很多，分为基于硬件的或者基于软件的，比较成熟的如：F5（支持四层、七层）、LVS（支持四层）layers),Nginx(支持七层)等近年来，随着ServiceMesh的兴起，涌现出一大批新一代“负载均衡”解决方案，如Envoy、Istio、Linkerd、Ribbon等。有兴趣合作伙伴可以自己做研究。4.结语本文先开篇，下一篇讲“负载均衡”的策略，用图说话。
