全面 一文理解微服务高可用的常用手段

“

高可用并不是一套整体解决方案，而是由诸多环节组成，一环扣一环，鬼知道为了这些串联起来的环节，我得出多少张牌去应对，才能最终组成一个整个系统的高可用落地方案。

图片来自 Pexels

什么是高可用

在定义什么是高可用，可以先定义下什么是不可用，一个网站的内容最终呈现在用户面前需要经过若干个环节，而其中只要任何一个环节出现了故障，都可能导致网站页面不可访问，这个也就是网站不可用的情况。

参考维基百科，看看维基怎么定义高可用：

系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。

这个难点或是重点在于“无中断”，要做到 7x24 小时无中断无异常的服务提供。

为什么需要高可用

一套对外提供服务的系统是需要硬件，软件相结合，但是我们的硬件总是会出故障，软件会有 Bug，硬件会慢慢老化，网络总是不稳定，软件会越来越复杂和庞大。

除了硬件软件在本质上无法做到“无中断”，外部环境也可能导致服务的中断，例如断电，地震，火灾，光纤被挖掘机挖断，这些影响的程度可能更大。

高可用的评价纬度

在业界有一套比较出名的评定网站可用性的指标，常用 N 个 9 来量化可用性，可以直接映射到网站正常运行时间的百分比上：

之前就职的一家互联网公司也是按照这个指标去界定可用性，不过在执行的过程中也碰到了一些问题。

例如，有一些服务的升级或数据迁移明明可以在深夜停机或停服务进行，然而考虑到以后的报告要显示出我们的系统达到了多少个 9 的高可用，而放弃停服务这种简单的解决方案，例如停机 2 个小时，就永远也达不到 4 个 9。

然而在一些高并发的场合，例如在秒杀或拼团，虽然服务停止了几分钟，但是这个对整个公司业务的影响可能是非常重大的，分分钟丢失的订单可能是一个庞大的数量。

所以 N 个 9 来量化可用性其实也得考虑业务的情况。

微服务高可用设计手段

高可用是一个比较复杂的命题，基本上在所有的处理中都会涉及到高可用，所有在设计高可用方案也涉及到了方方面面。

这中间将会出现的细节是多种多样的，所以我们需要对这样一个微服务高可用方案进行一个顶层的设计，围绕服务高可用，先检查下我们手里有多少张牌。

服务冗余

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LgwgRMDd-1655542140468)(https://upload-images.jianshu.io/upload_images/27867710-67ca3ea0183873a9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]

①冗余策略

每一个访问可能都会有多个服务组合而成，每个机器每个服务都可能出现问题，所以第一个考虑到的就是每个服务必须不止一份可以是多份。

所谓多份一致的服务就是服务的冗余，这里说的服务泛指了机器的服务，容器的服务，还有微服务本身的服务。

在机器服务层面需要考虑，各个机器间的冗余是否有在物理空间进行隔离冗余。

例如是否所有机器分别部署在不同机房，如果在同一个机房是否做到了部署在不同的机柜，如果是 Docker 容器是否部署在分别不同的物理机上面。

采取的策略其实也还是根据服务的业务而定，所以需要对服务进行分级评分，从而采取不同的策略。

不同的策略安全程度不同，伴随着的成本也是不同，安全等级更高的服务可能还不止考虑不同机房，还需要把各个机房所处的区域考虑进行。

例如，两个机房不要处在同一个地震带上等等。

②无状态化

服务的冗余会要求我们可以随时对服务进行扩容或者缩容，有可能我们会从 2 台机器变成 3 台机器。

想要对服务进行随时随地的扩缩容，就要求我们的服务是一个无状态化，所谓无状态化就是每个服务的服务内容和数据都是一致的。

例如，从我们的微服务架构来看，我们总共分水平划分了好几个层，正因为我们每个层都做到了无状态，所以在这个水平架构的扩张是非常的简单。

假设，我们需要对网关进行扩容，我们只需要增加服务就可以，而不需要去考虑网关是否存储了一个额外的数据。

网关不保存任何的 Session 数据，不提供会造成一致性的服务，将不一致的数据进行几种存储，借助更加擅长数据同步的中间件来完成。

这个是目前主流的方案，服务本身尽可能提供逻辑的服务，将数据的一致性保证集中式处理，这样就可以把“状态”抽取出来，让网关保持一个“无状态”。

这里仅仅是举了网关的例子，在微服务基本所有的服务，都应该按照这种思路去做。

如果服务中有状态，就应该把状态抽取出来，让更加擅长处理数据的组件来处理，而不是在微服务中去兼容有数据的状态。

数据存储高可用

之前上面说的服务冗余，可以简单的理解为计算的高可用，计算高可用只需要做到无状