工作十年，谈谈我的高可用架构和系统设计经验

,可用性是一个可以量化的指标，计算的公式在维基百科中是这样描述的：根据系统损害、无法使用的时间，以及由无法运作恢复到可运作状况的时间，与系统总运作时间的比较。行业内一般用几个9表示可用性指标，对应用的可用性程度一般衡量标准有三个9到五个9；一般我们的系统至少要到 4 个 9（99.99%）的可用性才能谈得上高可用。,高可用（High Availability）的定义：（From 维基百科）是 IT 术语，指系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。服务不可能 100% 可用，因此要提高我们的高可用设计，就要尽最大可能的去增加我们服务的可用性，提高可用性指标。一句话来表述就是：高可用就是让我们的服务在任何情况下都尽最大可能能够对外提供服务。,高可用系统的设计，需要有一套比较科学的工程管理套路，要从产品、开发、运维、基建等全方位去考量和设计，高可用系统的设计思想包括但不限于：,研发规范层面这个是大家容易忽视的一个点，但是，我们所有的设计，都是研发人员来完成的，包括从设计文档到编码到发布上线，因此，研发层面也是有一个规范流程和套路，来让我们更好的去研发和维护一个高可用的系统：,规范好相关方案设计文档的模板和提纲，让团队内部保持统一，可以参考我的文章《​​技术方案设计模板​​》,方案设计后一定要进行评审，在我们团队中，新项目一定要评审，重构项目一定要评审，大的系统优化或者升级一定要评审，其他的一般研发工作量超过一周的建议要评审的。,不要随便打日志,要接入远程日志,要能够分布式链路追踪,代码编写完需要有一定的单测来保证代码的健壮性，同时也能保障我们后续调整逻辑或者优化的时候可以保证代码的稳定,包括增量覆盖率、全量覆盖率，具体的覆盖率要达到多少可以根据团队内部的实际情况来定，在我们团队，定的规则是 50% 的覆盖率。,工程的 layout 目录结构规范，团队内部保持统一，尽量简洁,遵循团队内部的代码规范，一般公司都有对应语言的规范，如果没有则参考官方的规范，代码规范可以大大减少 bug 并且提高可用性。,执行代码规范,单测覆盖率,日志规范,容量评估，是指我们需要评估好，我们这个系统，是为了应对一个什么体量的业务，这个业务请求量的平均值、高峰的峰值大概都在一个什么级别。如果是新系统，那么就需要根据产品和运营同学对业务有一个大体的预估，然后开发同学根据产品给的数据再进行详细的评估。如果是老系统，那么就可以根据历史数据来评估。评估的时候，要从一个整体角度来看全局的量级，然后再细化到每个子业务模块要承载的量级。,容量规划，是指我们系统在设计的时候，就要能够初步规划好我们的系统大致能够抗多少的量级，比如是十万还是百万级别的请求量，或者更多。不同的量级对应的系统架构的设计会完全不一样，尤其到了千万、亿级别的量级的时候，架构的设计会有很多的考量。当然这里需要注意的是，我们不需要一上来就设计出远超于我们当前业务真实流量的系统，要根据业务实际情况来设计。同时，容量规划还涉及到，我们系统上下游的各个模块、依赖的存储、依赖的三方服务，分别需要多少资源，需要有一个相对可以量化的数据出来。容量规划阶段，更多是要依靠自身和团队的经验，比如要了解我们的 log 的性能、redis 的性能、rpc 接口的性能、服务化框架的性能等等，然后根据各种组件的性能来综合评估自己设计的系统的整体性能情况。,容量评估和容量规划之后，我们还需要做一件事情，就是性能压测，最好是能够做到全链路压测。性能压测的目的是为了确保你的容量规划是准确的，比如我设计的这个系统，我规划的是能够抗千万级别的请求，那么实际上，真的能够抗住吗 ？这个在上线之前，首先要根据经验来判断，然后是一定要经过性能压测得出准确结论的。性能压测要关注的指标很多，但是重点要关注是两个指标，一个是 QPS、一个是响应耗时，要确保压测的结果符合预期。压测的步骤可以先分模块单独压测，最后如果情况允许，那么最好执行全链路压测。,QPS 预估（漏斗型），指的是一个真实的请求过来后，从接入层开始，分别经过了我们整个系统的哪些层级、哪些模块，然后每一个层级的 QPS 的量级分别有多少，从请求链路上来看，层级越往下，那么下游层级的量级应该会逐步减少的，因为每经过一个层级，都有可能会被各种条件过滤掉的一部分请求。比如说进入活动页后查看商品详情然后下单这个例子，首先进入活动页，所有的请求都会进入访问；然后只会有部分用户查询商品详情；最后查看商品详情的这些用户又只会有部分用户会下单，因此这里就会有一个漏斗，从上层模块到下层模块的量级一定是逐步减少的。,QPS 预估（漏斗型）就是需要我们按照请求的层面和模块来构建我们的预估漏斗模型，然后预估好每一个层级的量级，包括但不限于从服务、接口、分布式缓存等各个层面来预估，最后构成我们完整的 QPS 漏斗模型。,一般要做到系统的高可用，我们的应用服务的常规设计都是无状态的，这也就意味着，我们可以部署多个实例来提高我们系统的可用性，而这多个实例之间的流量分配，就需要依赖我们的负载均衡能力。无状态 + 负载均衡 既可以让我们的系统提高并发能力，也可以提高我们系统的可用性。,如果我们的业务服务使用的是各种微服务框架来开发的，那么大概率在这个微服务框架里面就会包含了服务发现和负载均衡的能力。这是一整套流程，包括服务注册和发现、负载均衡、健康状态检查和自动剔除。当我们的任何一个服务实例出现故障后会被自动剔除掉，当我们有新增一个服务实例后会自动添加进来提供服务。,如果我们不是使用的微服务框架来开发的，那么就需要依赖负载均衡的代理服务，比如 LVS、Nginx 来帮我们实现负载均衡。,弹性扩缩容设计是应对突峰流量的非常有效的手段之一，同时也是保障我们服务可用性的必要手段。弹性扩缩容针对的是我们的无状态的应用服务而言的，因为服务是无状态的，因此可以随时根据请求量的大小来进行扩缩容，流量大就扩容来应对大量请求，流量小的时候就缩容减少资源占用。,怎么实现弹性扩缩容呢？现阶段都是云原生时代，大部分的公司都是采用容器化（K8s）部署，那么基于这个情况的话，弹性扩缩容就非常容易了，只需要配置好 K8s 的弹性条件就能自动根据 CPU 的使用率来实现。,如果不是容器化部署，是物理机部署的方式，那么要做到弹性扩缩容，必须要有一个公司内部的基础建设能力，能够在运营平台上针对服务的 CPU 或者 QPS 进行监控，如果超过一定的比例就自动扩缩容，和 K8s 的弹性原理是一样的，只是需要自行实现。,要想我们的系统能够高可用，那么从架构层面来说，要做到分层、分模块来设计，而分层分模块之后，那么各个模块之间，还可以进行异步处理、解耦处理。目的是为了不相互影响，通过异步和解耦可以使我们的架构大大的提升可用性。,架构层面的异步解耦的方式就是采用消息队列（比如常见的 Kafka），并且同时消息队列还有削峰的作用，这两者都可以提高我们的架构可用性：,任何服务，一定会存在失败的情况，不可能有 100% 的可用，服务在线上运行过程中，总会遇到各种各样意想不到的问题会让你的服务出现状况，因此业界来评价可用性 SLA 都是说多少个 9，比如 4 个 9(99.99%)的可用性。,为此，我们的设计建议遵循”design for failure”的设计原则，设计出一套可容错的系统，需要做到尽早返回、自动修复，细节如下,系统无法高可用的一个重要原因就在于，我们的系统经常会有突发的流量过来，导致我们的服务超载运行，这个时候，首先要做的当然是快速扩容，并且我们事先就要预留好一定的冗余。另外一个情况下，就算我们扩容了，但是还是会超载，比如超过了下游依赖的存储的最大容量、或者超过了下游依赖的三方服务的最大容量。那么这个时候，我们就需要执行我们的过载保护策略了，主要包括限流、熔断、降级，过载保护是为了保证服务部分可用从而不至于整个服务完全不可用。,在当前的互联网时代，应用服务基本都是无状态的，因此应用服务的高可用相对会比较简单，但是对于数据存储的高可用，相对来说，会复杂很多，因为数据是有状态的，那具体我们要怎么保障数据存储的高可用，我们来分析下。,存储层面的高可用方案的本质都是通过通过数据冗余的方式来实现高可用，将数据复制到多个存储介质里面，可以有效的避免数据丢失，同时还可以提高并发能力，因为数据是有状态的，因此，这里会比服务的高可用要复杂很多，主要体现在如下几个方面,常见的解决存储高可用的方案有两种：集群存储和分布式存储。业界大多是围绕这些来构建，或者是做相关衍生和扩展。,集群就是逻辑上处理同一任务的机器集合，可以属于同一机房，也可分属不同的机房。集群存储，就是把多台机器上的存储数据组合在一起对外形成一套统一的系统。集群存储适合业务存储量规模一般的场景，常规的业务数据存储一般都是集群存储方式就足够了。现在我们一般对于业务数据存储的使用，默认都是集群方式，比如 Redis、MySQL 等存储类型，一般中大型互联网公司，默认肯定都是集群存储的方式。,集群存储就是我们常说的 1 主多备或者 1 主多从的架构，写数据通过主机，读数据一般通过从机。集群存储主要需要考虑如下几个问题：,数据的写入都是通过主机，因此数据同步到备机（从机），就是要通过主机进行数据复制到备机（从机）。,还需要考虑主备同步的时间延迟问题。,主从架构中，如果主机故障，可直接将备机（从机）切换为主机,1.主备复制,主备复制是最常见也是最简单的一种存储高可用方案，几乎所有的存储系统都提供了主备复制的功能，例如 MySQL、Redis、MongoDB 等。,主备架构中的“备机”主要还是起到一个备份作用，并不承担实际的业务读写操作，如果要把备机改为主机，需要人工操作。因此一般使用场景都是在一些内部的后台管理系统中使用。,2.主从复制,主从复制和主备复制虽然只有一字之差，但是两者是不一样的设计思路，“从”意思是“随从、仆从”，“备”的意思是备份。”从“ 的机制是要干活的，因此是承担数据的“读”操作的，一般就是主机负责读写操作，从机只负责读操作，不负责写操作。,3.主从切换,主备复制和主从复制方案存在两个共性的问题：,主从切换（主备切换）就是为了解决这两个问题而产生的，具体的设计就是在原有方案的基础上增加“自动切换”的能力，当主机异常后，经过系统检测并且自动将备机或者从机切换为主机。这个是实际应用中比较多的一个方案之一，因为我们一定能够有机制保证主机异常后从机能够自动切换为主机。,4.主主复制,主主复制指的是两台机器都是主机，互相将数据复制给对方，客户端可以任意挑选其中一台机器进行读写操作，如果采取主主复制架构，必须保证数据能够双向复制。这个相对来说，要求较高。,集群指的是将几台服务器集中在一起，实现同一业务。而分布式是指将不同的业务分布在不同的地方，分布式中的每一个节点，都可以做集群。,分布式存储就是通过网络使用企业中的每台机器上的磁盘空间，并将这些分散的存储资源构成一个虚拟的存储设备，数据分散的存储在企业的各个角落。分布式存储中的每台服务器都可以处理读写请求，因此不存在集中式存储中负责写的主机那样的角色。但在分布式存储中，必须有一个角色来负责执行数据分配算法，这个角色可以是独立的一台服务器，也可以是集群自己选举出的一台服务器。分布式存储适合非常大规模的数据存储，业务数据量巨大的场景可以采用这种方式。常见的分布式存储比如 Hadoop(HDFS)、HBase、Elasticsearch 等。,产品层面的高可用架构解决方案，基本上就是指我们的兜底产品策略。降级/限流的策略，更多的是从后端的业务服务和架构上的设计来考虑相关解决方案。这里说的兜底策略，也可叫做柔性降级策略，更多则是通过产品层面上来考虑。,灰度发布、接口测试、接口拨测系列设计包括但不限于：,灰度发布和接口测试，一般在大公司里面会有相关的 DevOps 流程来保证。,监控告警的设计，在大公司来说，根本不是问题，因为一定会有比较专门一拨人去做这种基础能力的建设，会有对应的配套系统，业务开发的同学只需要配置或使用即可。那如果说公司内部没有相关基础建设，那么就需要自己分别来接入对应的系统了。,监控系统,一般在监控系统这方面的开源解决方案包括但不限于这些：,我们的日志记录不能都本地存储，因为微服务化后，日志散落在很多机器上，因此必须要有一个远程日志记录的系统，ELK 是不二人选,可以监控各种系统层面的指标，包括自定义的一些业务指标, 一个请求的上下游这么多服务，怎么能够把一个请求的上下游全部串起来，那么就要依靠 OpenTracing，可以把一个请求下的所有链路都串起来并且有详细的记录,最新的标准，大一统，集合了跟踪数据（Traces），指标数据（Metrics），日志数据（Logs）来观测分布式系统状态的能力,我们会依托开源系统进行自建或者扩展，甚至直接使用都行，然后我们的监控的指标一般会包括：,告警系统,这些系统接入完了之后，还只是做到监控和统计，当出现问题的时候，还需要进行实时告警，因此还要有一个实时告警系统，如果没有实时报警，系统运行异常后我们就无法快速感知，这样就无法快速处理，就会给我们的业务带来重大故障和灾难。告警设计需要包括：,安全性、防攻击设计的目的是为了防刷、防黑产、防黑客，避免被外部恶意攻击，这个一般有几个策略：,一般的高可用策略，都是针对一个机房内来服务层面来设计的，但是如果整个机房都不可用了，比如地震、火灾、光纤挖断等。。。。那么这个情况怎么办？这就需要我们的服务和存储都能够进行容灾了，容灾的一个常见方案就是多机房部署了。,条件不允许的情况下，我们保证多机房部署业务服务就可以了。,故障演练在大公司是一个常见的手段；在业界，Netflix 早在 2010 年就构建了混沌实验工具 Chaos Monkey，混沌实验工程对于提升复杂分布式系统的健壮性和可靠性发挥了重要作用。,简单的故障演练就是模拟机房断电、断网、服务挂掉等场景，然后看我们的整个系统运行是否正常。系统的就要参考混沌实验工程来进行详细的规划和设计，这个是一个相对比较大的工程，效果挺好，但是需要有大量人力去开发这种基础建设。,接口拨测，和巡检类似，就是服务上线后，每隔一个固定时间（比如 5s）调用后端的各种接口，如果接口异常则进行告警,针对接口拨测，一般也会有相关配套设施来提供相关的能力去实现，如果没有提供，那么我们可以自己写一个接口拨测（巡检）的服务，定期去调用重要的接口。,前面做了这么多保障，但是终究架不住线上的各种异常情况，如果真出问题了，让我们的服务异常，无法提供服务后，我们还需要最后一根救命稻草，那就是应急预案，将服务异常的损失降低到最小。,应急预案就是我们需要事先规划好，我们业务系统在各个层级出现问题后，我们需要第一时间怎么恢复，制定好相关规则和流程，当出现异常状况后可以按照既有的流程去执行，这样避免出现问题后手忙脚乱导致事态扩大。