Cool带你学治理体系
高可用设计
什么是高可用?
在定义什么是高可用,可以先定义下什么是不可用,一个网站的内容最终呈现在用户面前需要经过若干个环节,而其中只要任何一个环节出现了故障,都可能导致网站页面不可访问,这个也就是网站不可用的情况。
参考维基百科,看看维基怎么定义高可用:系统无中断地执行其功能的能力,代表系统的可用性程度,是进行系统设计时的准则之一
。
这个难点或是重点在于“无中断”,要做到 7 x 24 小时无中断无异常的服务提供。
为什么需要高可用?
一套对外提供服务的系统是需要硬件,软件相结合,但是我们的软件会有bug,硬件会慢慢老化,网络总是不稳定,软件会越来越复杂和庞大,除了硬件软件在本质上无法做到“无中断”,外部环境也可能导致服务的中断,例如断电,地震,火灾,光纤被挖掘机挖断,这些影响的程度可能更大。
高可用的评价纬度
在业界有一套比较出名的评定网站可用性的指标,常用N个9来量化可用性,可以直接映射到网站正常运行时间的百分比上
描述 | N个9 | 可用性级别 | 年度停机时间 |
---|---|---|---|
基本可用 | 2个9 | 99% | 87.6小时 |
较高可用 | 3个9 | 99% | 8.8小时 |
具备故障自动恢复能力可用 | 4个9 | 99.99% | 53分钟 |
极高可用 | 5个9 | 99.999% | 5分钟 |
一般互联网公司也是按照这个指标去界定可用性,不过在执行的过程中也碰到了一些问题,例如,有一些服务的升级或数据迁移明明可以在深夜停机或停服务进行,然而考虑到以后的报告要显示出我们的系统达到了多少个9的高可用,而放弃停服务这种简单的解决方案,例如停机2个小时,就永远也达不到4个9。然而在一些高并发的场合,例如在秒杀或拼团,虽然服务停止了几分钟,但是这个对整个公司业务的影响可能是非常重大的,分分钟丢失的订单可能是一个庞大的数量。所以N个9来量化可用性其实也得考虑业务的情况。
服务冗余
冗余策略
每一个访问可能都会有多个服务组成而成,每个机器每个服务都可能出现问题,所以第一个考虑到的就是每个服务必须不止一份可以是多份,所谓多份一致的服务就是服务的冗余,这里说的服务泛指了机器的服务,容器的服务,还有微服务本身的服务。
在机器服务层面需要考虑,各个机器间的冗余是否有在物理空间进行隔离冗余 ,例如是否所有机器是否有分别部署在不同机房,如果在同一个机房是否做到了部署在不同的机柜,如果是docker容器是否部署在分别不同的物理机上面。 采取的策略其实也还是根据服务的业务而定,所以需要对服务进行分级评分,从而采取不同的策略,不同的策略安全程度不同,伴随这的成本也是不同,安全等级更高的服务可能还不止考虑不同机房,还需要把各个机房所处的区域考虑进行,例如,两个机房不要处在同一个地震带上等等。
无状态化
服务的冗余会要求我们可以随时对服务进行扩容或者缩容,有可能我们会从2台机器变成3台机器,想要对服务进行随时随地的扩缩容,就要求我们的服务是一个无状态化,所谓无状态化就是每个服务的服务内容和数据都是一致的。
例如,从我们的微服务架构来看,我们总共分水平划分了好几个层,正因为我们每个层都做到了无状态,所以在这个水平架构的扩张是非常的简单。假设,我们需要对网关进行扩容,我们只需要增加服务就可以,而不需要去考虑网关是否存储了一个额外的数据。
网关不保存任何的session数据,不提供会造成一致性的服务,将不一致的数据进行几种存储,借助更加擅长数据同步的中间件来完成。这个是目前主流的方案,服务本身尽可能提供逻辑的服务,将数据的一致性保证集中式处理,这样就可以把“状态”抽取出来,让网关保持一个“无状态”
这里仅仅是举了网关的例子,在微服务只基本所有的服务,都应该按照这种思路去做,如果服务中有状态,就应该把状态抽取出来,让更加擅长处理数据的组件来处理,而不是在微服务中去兼容有数据的状态。
- 点赞
- 收藏
- 关注作者
评论(0)