高可用的本质

简介: 无论是一个域,一个BG,还是一个站点,虽然范围有大有小,对象有所不同,但其高可用的理念都是相通的,今天将自己对高可用的一点点思考以及总结的【nPRT公式】分享给大家。

image.png

我是乐羊,一个热爱风险防控的人,之前参与过蚂蚁Glocal多个站点从0到1的建站和高可用建设,目前正在参与蚂蚁大安全的高可用建设。无论是一个域,一个BG,还是一个站点,虽然范围有大有小,对象有所不同,但其高可用的理念都是相通的,今天将自己对高可用的一点点思考以及总结的【nPRT公式】分享给大家。

本文采用“高可用是什么,为什么要高可用,怎么做高可用,为什么这么做,软件风险又在哪里”的逻辑来介绍。

一 高可用是一种控制风险的能力

高可用是一种面向风险设计,使系统具备控制风险,提供更高的可用性的能力。

二 为什么要高可用

对于一个公司而言,“为什么要高可用”可以完整理解为“公司为什么要(做系统)高可用”。以公司为对象,从内看包括:人,软件(物),硬件(物);从外看包括:客户,股东,社会;从自身看包括:公司。

image.png

高可用的大前提:所有事物都不是100%可靠的

  • 所有事物都是变化的(唯一不变的是变化)。
  • 所有变化的都不是100%可靠的。
  • 结论:所有事物都不是100%可靠的。

内因:人、物都不是100%可靠的

  • 从人的层面:人都是有可能犯错的。
  • 从软件层面:软件都是有可能有BUG的。
  • 从硬件层面:硬件都是有可能会坏的。

从概率学角度分析,凡是有可能会出错的,只要变化次数足够多,最终出错的概率会无限趋向于1。

外因:无高可用,对外影响面是很大的

  • 从客户角度:无高可用,客户服务可能会中断。
  • 从股东层面:无高可用,股价可能会下跌。
  • 从社会角度:无高可用,社会秩序可能受影响。

根因(本质):控制风险

从公司自身角度:控制风险,保障公司价值,避免伤及根本。

三 如何做高可用

如何做高可用,本质上就是:如何控制风险。

1 风险相关概念

  • 风险:指未来会发生危害的一种可能性,但实际未发生,记为r。
  • 故障:指已发生或正在发生危害的一种事实,是风险变现实的结果。
  • 风险概率:指一个风险变故障的概率。用它来表示风险触发为故障的难易程度,记为P(r)。
  • 故障影响范围:指在单位时间内,一个故障造成的危害影响,记为R(r)。
  • 故障影响时长:指一个故障持续的时间,记为T(r)。
  • 故障影响面:指一个故障影响范围乘以故障影响时长的总和。这里用故障影响面来表示故障总的危害程度,记为F(r)。
  • 风险期望:指每个风险变故障的概率乘以每个风险变故障后的故障影响面的总和。这里用风险期望来表示风险的潜在危害程度,记为E(r)。

2 风险期望的公式

根据上节的定义,可以推导出风险期望的公式如下:

image.png

r代表风险,风险期望会随着风险的数量n和每个风险的P、R、T下降而下降,简称nPRT公式。

注:如果要引用该公式请注明出处。

3 控制风险的4大因素(nPRT)

减少风险数量,n

从源头远离风险,做到与风险载体无连接,无关系;那么该风险概率就是0,也不关心该风险发生后的故障影响面是大是小,完全不关心。

  • 例如:重大节日活动,施行全站封网,变更的数量就会得到一个明显的下降,就是典型的减少风险数量。
  • 例如:系统A完全不依赖Oracle,那系统A就不用关心Oracle的任何风险,哪怕美国总统突然紧急宣布Oracle立即立刻禁止在中国使用,系统A也无所谓。
  • 例如:最近新冠大流行,人传人很可怕,如果你今天选择不上班不出门,那你今天就不用担心被外面的行人和同事传染。

降低风险变故障的概率(即:增加风险变故障的难度),P

把风险当成一个对象看待,给它层层设卡,增加风险变故障的门槛和难度,不要再让“不小心多了一个空格或字符,系统就挂了”这种惨案轻易出现。

  • 例如:人员B要对系统C进行变更,可以对人员B增加变更认证考试,对变更内容要求线下(或仿真)测试,对变更内容进行CR,系统C提供变更效果预览能力(类似监控模式或试运行),万一人员B想恶意变更搞破坏,还可以增加非同人复核,系统C可以增加防错设计进行保护等等。
  • 例如:以新冠为例,带口罩,勤洗手,多通风等就可以降低染上新冠的概率。

减小故障影响范围,R

以大拆小,将一个整体拆分成N个小的个体,每个个体之间进行相互隔离,单个个体出问题仅影响单个个体,实现小而美。

  • 例如:分布式架构就是这个的典范,集中式一损俱损,分布式一损即N分之一损。
  • 例如:以新冠为例,网格化管理,各省或市间的流动进行限制,跨省必须核酸+隔离14天,有效控制新冠的传播范围。

缩短故障影响时长,T

故障影响时长由故障发现时间和故障止血时间决定,所以要早发现早止血。

发现方式分为:事前的预警,事后的告警。尽可能朝事前预警去做,给止血争取时间甚至将风险扼杀在摇篮中。

止血方式分为:切换,回滚,扩容,降级 or 限流,BUG修复等。故障出现时第一优先原则为快速止血(如切换、回滚、扩容),严禁去定位根因;当无法快速止血时以少流血为第二优先原则,如降级、限流。

止血效率:自动 vs 人工 ;一键化 vs 多步操作。尽可能用自动化去代替人工操作,若人工操作时尽量实现一键化,提升止血速度。

  • 例如:对于容量水位,可以在警戒线之前划一条预警线,提前预警,从容应对。
  • 例如:分布式应用集群,任何一台应用服务器有问题时,负载均衡会通过心跳检查自动把有问题的应用服务器剔除,将请求转发给其他(热)备份冗余的服务器上。
  • 例如:以新冠为例,但由于每个生命都是独一无二的,没有办法切换,也没有办法回滚,也不能降级(涉及人道主义),只能对症下药慢慢治疗。

4 高可用架构设计的7大核心原则

根据nPRT公式,在高可用架构设计时有以下7个核心原则:

少依赖原则:能不依赖的,尽可能不依赖,越少越好(n)

由于所有事物都不是100%可靠的,当2个事物之间有了关系,那么就会相互影响,就互为对方的一个风险,一个出问题可能会影响另外一个。我们统一用依赖来泛指这里的“关系”。

  • 例如:一个系统同时依赖Oracle,Mysql,OB三种关系型数据库,少依赖原则是改成仅依赖最成熟稳定的OB,不依赖Oracle和Mysql。

什么场景适合多依赖?

当引入依赖(n变大)可以减小PRT中的一个或多个,且使E(r)整体下降时。

  • 例如:为解决DB风险,引入分布式缓存,只要2者不同时挂的时候依然可用。

弱依赖原则:一定要依赖的,尽可能弱依赖,越弱越好(P)

事物a强依赖事物b,一旦b出问题时,那么a也会出问题,一损俱损。

所以任何强依赖都要尽可能的转化成弱依赖,可以直接降低出问题的概率。

  • 例如:交易核心链路在交易成功后要要给用户发放积分权益;交易核心系统需要依赖积分权益系统,好的方式是采用弱依赖,使用异步化的方式,这样积分权益系统不可用时,大概率不会影响交易核心链路。

分散原则:鸡蛋不要放一个篮子,分散风险(R)

image.png

打散拆分成N份;避免全局只有1份,否则一有问题影响范围就是100%。

  • 例如:所有交易数据都放在同一个库同一张表里面,万一这个库挂了,此时影响所有交易。
  • 例如:将自己所有的钱买了同一只股票,万一这只股票是乐视就惨了。

均衡原则:均匀分散风险,避免不均衡(R)

image.png

最好N份中的每份都是均衡的;避免某个份额过大,否则过大的那份一有问题就影响范围过大了。

  • 例如:xx应用集群有1000台,但由于引流组件BUG,导致所有流量引到了其中100台上面,导致负载严重不均衡,最后因负载无法扛着全面崩溃。类似重大故障已经发生了多次。
  • 例如:将自己所有的钱买了10只股票,其中一只占比99%,万一这只股票是乐视就惨了。

隔离原则:控制风险不扩散,不放大(R)

image.png

每份之间是相互隔离的;避免一份有问题影响其他的也有问题,传播扩散了影响范围。

  • 例如:交易数据拆分成10库100表,但是部署在同一台物理机上;万一某张表有一条大SQL把网卡打满了,那10库100表都会受影响。
  • 例如:将自己所有的钱均分买了10只股票,每只都占10%,但10只都是乐视系的。
  • 例如:古代赤壁之战就是一个典型的反面例子,铁锁连船导致隔离性被破坏,一把大火烧了80w大军。

隔离是有级别的,隔离级别越高,风险传播扩散的难度就越大,容灾能力越强。

  • 例如:一个应用集群由N台服务器组成,部署在同一台物理机上,或同一个机房的不同物理机上,或同一个城市的不同机房里,或不同城市里,不同的部署代表不同的容灾能力。
  • 例如:人类由无数人组成,生活在同一个地球的不同洲上,这意味着人类不具备星球级别的隔离能力,当地球出现毁灭性影响时,人类是不具备容灾的。

隔离原则是一个极其重要的原则,它是前面4个原则的前提。没有做好隔离,前面4个原则都是脆弱的,风险很容易传播扩散开,破坏前面4个原则的效果。大量真实系统故障是因为隔离性做得不好导致的,如:线下影响线上,离线影响在线,预发影响生产,一条烂SQL影响整个库(或整个集群)等等。

分散,均衡,隔离是控制风险影响范围的3个核心原则。打散拆分成N份,每一份都是均衡的,且相互隔离,一份有问题,影响范围为1/N。

无单点原则:要有冗余或其他版本,做到有路可退(T)

快速止血的方式是切换,回滚,扩容等;回滚和扩容属于特殊的切换,回滚指的是切换到某个版本,扩容指的是将流量切换到新扩容的机器上。

切换得有地方可切才行,所以不能有单点(这里特指强依赖的单点,弱依赖的可以降级),要有冗余备份或其他版本;单点会限制整体的可靠性。

假设单点的可靠性假设是99.99%,它要提升到99.999%是非常困难的,但是如果无单点而是依赖2个(1个挂掉没有关系,只要不同时挂就行),那整体可靠性就是99.999999% 会有质的提升。

单点故障会导致无法快速止血,拉长整个止血时间,去单点至关重要。这里的单点不仅仅指的是系统节点,也包含人员,如订阅告警的人,应急的人等等。

对于(重要)数据节点,必须满足无单点原则,否则极端情况下可能造成数据永久丢失,永远无法恢复;(重要)数据节点满足无单点原则后,保障数据一致性比可用性要求更重要。

  • 例如:一个商户仅支持一个支付渠道,就是典型的单点,万一这个支付渠道挂了就不能支付了。
  • 例如:一个家庭的所有收入仅依赖父亲一个的薪资收入,万一这个父亲病了,就没有收入了。

无单点原则和分散原则的区别:

  • 当节点无状态的情况下,打散拆分成N份,每份都是相同的功能,互为冗余,即:节点无状态情况下,分散原则和无单点原则等价,满足一个即可。
  • 当节点有状态的情况下,打散拆分成N份,每份都是不相同的,每份都没有冗余,需要针对每份再做冗余,即:节点有状态情况下,既要满足分散原则又要满足单点原则。

自我保护原则:少流血,牺牲一部分,保护另外一部分(P&R&T)

外部的输入都不是100%可靠的,有时候是无意的错误,有时候甚至是恶意的破坏,因此针对外部输入要有防错设计,给自己多一些保护。

极端情况下可能无法(快速)止血,可以考虑少流血,牺牲一部分保护另外一部分。例如:限流,降级等。

  • 例如:大促峰值期间,一般会提前降级掉很多功能,同时限流,主要是为了保护峰值绝大部分人的交易支付体验。
  • 例如:人体在失血过多或疼痛过度时就会触发休克现象,这也是一种典型的自我保护机制。

四 软件风险在何方

前面介绍了控制风险的方法,回到软件系统这个领域,它的风险又在哪里?

以软件系统为对象,从内看包括:计算系统和存储系统;从外看包括:人员,硬件,上游系统,下游系统;以及(隐含的)时间。

image.png

由于每个对象都是由其他对象组成的,因此每个对象还可以继续往细分解(理论上可以无限分解下去),上面的分解方式主要是为了简化理解。

1 软件系统风险的来源

风险源于(有危害的)变化,一个对象的风险来源于所有跟它有关系的对象的(有危害的)变化。因此,软件系统风险的来源,分为以下7大类:

计算系统变化:运行变慢,运行错误

系统运行所依赖的服务器资源(如CPU,MEM,IO等),应用资源(RPC线程数,DB连接数等),业务资源(业务ID满了,余额不足,业务额度不够等)的负载等都会影响系统运行的风险期望。

存储系统变化:运行变慢,运行错误,数据错误

系统运行所依赖的服务器资源(如CPU,MEM,IO等),存储资源(并发数等),数据资源(单库容量,单表容量等)的负载和数据一致性等都会影响存储系统运行的风险期望。

人的变化:变更出错

变更人员的数量,安全生产意识,熟练程度,变更的数量,变更的方式等都会影响变更的风险期望。

由于变更的人多,变更的次数也多,导致变更成为蚂蚁所有故障来源里的TOP1,这也是为什么“变更三板斧”这么出名的原因。

“变更三板斧”正确的排序应该是“可灰度,可监控,可应急”;可灰度代表的是R,可监控和可应急代表的是T。

思考:如果变更三板斧让你再加一板斧,你觉得应该是什么?

硬件变化:损坏

硬件的数量,质量,使用年限,保养等都会影响硬件的风险期望,硬件损坏会影响上层软件系统不可用。

上游变化:请求变大

请求分为3个维度:(由无数API汇集而成的)网络流量,(由无数KEY请求组成的)API,KEY。

  • 网络流量过大会造成网络堵塞,影响网络通道中的所有网络流量请求。
  • API请求过大会造成对应服务集群过载,影响整个服务机器上的所有API请求,甚至往外传播。
  • KEY请求过大(俗称“热点KEY”)会造成单机过载,影响单机上所有KEY请求,甚至往外传播。

所以大促保障的时候,不仅仅是关注核心API的容量保障,还需要考虑网络流量和热点KEY。

下游变化:响应变慢,响应错误

下游服务的数量,服务等级,服务可用率等影响下游服务的风险期望。下游响应变慢可能会拖慢上游,下游响应错误可能会影响上游运行结果。

时间变化:时间到期

时间到期往往被人忽视,但它往往具有突然性和全局破坏性,一旦时间到期触发故障会导致非常被动,所以要提前识别,尽早预警,如:秘钥到期,证书到期,费用到期,跨时区,跨年,跨月,跨日等。

  • 例如:2019年日本运营商软银因证书到期引发3000w用户长达4小时通信中断。
以上每一大类风险都可以基于nPRT公式进行逐一分析处理。

2 风险的数量:一生三,三生万物

任何一个事物既是由其他事物组成的又是其他事物的组成部分,无限循环下去;一生三,三生万物,风险的数量是无穷无尽的。

向内看,内含内,可以无限小下去;当原子粒度的问题传播开时,也可能影响软件系统的可用性,就像100纳米的新冠病毒就可以影响人体的可用性一样。

向外看,外有外,可以无限大下去;当太阳系毁灭,软件系统的可用性自然就不复存在。

虽然风险无穷无尽,但是只要我们对风险多一些了解,根据控制风险的一些理念和原则,还是可以更好的降低风险期望。

谈一谈敬畏之心:

  • 我们对世界的认知是有限的,这也让我们少了许多恐惧,同时也让我们少了一些敬畏之心。
  • 我们真正要敬畏的不是处罚条例,而是我们不知道的,以及我们不知道我们不知道。

五 结束语

  • 所有事物都是变化的。
  • 所有事物都不是100%可靠的。
  • 因此才有了风险,风险是不可见的,可见的是故障。
  • 风险是不能消灭光的,但是可以远离,可以减少。
  • 故障是不可避免的,但是可以推迟,可以缩小影响范围,缩短影响时间。

nPRT公式不仅仅适用于软件系统风险,也适用于其他风险领域,希望对大家有用。

作者:开发者小助手_LS

原文链接

本文为阿里云原创内容,未经允许不得转载

 

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/514230.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

技术干货 | 深度解构 Android 应用面临紧急发版时的救星方案:mPaaS 热修复——DexPatch

简介: 关于 Android 热修复方案——DexPatch 的介绍与使用说明 方案介绍 为了解决 Native 模块上线后的问题,mPaaS 提供了热修复功能,实现不发布客户端 apk 场景下的热修复。目前 Android 端热修复主要包括 andfix 和 dexpatch,考…

李飞飞:阿里云数据库已做好全面服务政企市场的准备

“政企市场是检验云数据库产品竞争力的黄金标准。”9月3日,阿里云智能数据库事业部总负责人李飞飞在北京举办的媒体沟通会上表示,阿里云已经做好全面服务政企数据库市场的准备,并已成功助力多家大型组织实现核心系统对传统商业数据库的替换。…

技术改变生活 浅谈阿里云混合云的探索与实践

简介: 也许你并不了解“阿里云混合云”,甚至没有听说过“混合云”,然而它却在幕后“默默”改变着人们的生活。 也许你并不了解“阿里云混合云”,甚至没有听说过“混合云”,然而它却在幕后“默默”改变着人们的生活。大…

公网访问_一文读懂阿里云访问公网的实现方式

NAT网关与EIP作为公有云服务商,提供互联网的访问和接入是必备的条件,阿里云也不例外。和AWS类似,阿里云访问公网的组件为NAT网关和弹性IP,对于刚刚接触云的童鞋,今天这篇文章带你彻底了解这两个组件的使用场景。弹性IP…

阿里巴巴云原生应用安全防护实践与 OpenKruise 的新领域

简介: 得益于 Kubernetes 面向终态的理念,云原生架构天然具备高度自动化的能力。然而,面向终态的自动化是一把“双刃剑”,它既为应用带来了声明式的部署能力,同时也潜在地会将一些误操作行为被终态化放大。 因此&#…

什么是微内核架构设计?

简介: 作为一名Java程序员,相信同学们都听说过微内核架构设计,也有自己的理解。那么微内核是如何被提出来的?微内核在操作系统内核的设计中又有什么作用?本文从插件化(Plug-in)架构的角度来诠释微内核架构设计&#xf…

给力!斩获 GitHub 14000 Star,两周创办开源公司获数百万美元融资

上世纪 90 年代初,21 岁大学生 Linus Torvalds 开源 Linux 操作系统,自此掀起全球开源浪潮。随后“中国 Linux 第一人”宫敏博士用手提肩背的方式将 20 盒磁带背回中国,磁带里装着 80G 容量的自由软件,组建起中国第一个自由软件库…

函数计算镜像加速:从分钟到秒的跨越

简介: 函数计算 FC 正式发布容器镜像加速,通过按需读取和更高效的解压技术在不同场景下加速 50%-80%,即使 GB 级别的镜像也可以在几秒内完成端到端启动。 FaaS 和容器 容器镜像因其颠覆式创新成为云原生时代应用部署格式的事实标准。头部云厂…

阿里云CDN产品经理陈章炜:边缘创新技术和落地实践

简介: CDN除了加速外,不断被赋予更多价值。在阿里云CDN推出的《极速奔跑吧 2021》首场直播中,阿里云架构师和产品经理不仅对近期阿里云发布的CDN产品最佳实践图进行了详细解读,还对CDN产品和客户的场景如何更高效地匹配、形成最优…

极狐GitLab:从硅谷到中国,远程办公背后的挑战与创新

编辑 | 宋 慧 供稿 | 极狐(GitLab) 头图 | 付费下载于视觉中国 最近,海外的互联网巨头们纷纷开启了远程办公的政策,谷歌允许员工提出更换办公地点的要求或申请成为永久远程办公者,目前已经批准了近 8000 名员工在家办公…

E百科 | 基于MEC的边缘AI服务

简介: 阿里云边缘计算团队付哲解读5G下热门场景:边缘AI。作者:阿里云付哲,计算机科学与技术专业博士后,在流量检测、资源调度领域有深入研究,其论文《Astraea: Deploy AI Services at the Edge in Elegant …

网速dns怎么调快_怎么设置dns?教你快速解决网速慢的问题

体内惊人荒之力很的洪,设置速解速慢设置速解速慢了一但其大批企业高成中中隐藏优质长的,复活,一旦。特斯提高金拉2的第度为的产大量的资7年能投入了三季,教决网仅生0辆产了,理想并不其效果却,交付2辆只有实…

“凡尔赛”式晒校园生活?移动云 9.9 风暴手把手教你!

快开学了卧虎藏龙的校园当然也少不了“凡尔赛大师”看看普通版和进阶版的凡尔赛学霸学神们如何用最低调的话炫最高调的耀LETS GO!考/试/篇假/期/篇生/活/费/篇看完学霸与学神的凡尔赛较量除了羡慕他们能够凡尔赛的资本更重要的是了解到移动云校园套餐原来如!此&…

开源微服务运行时 Dapr 发布 1.0 版本

简介: Dapr 是 2019 年 10 月开源的分布式运行时。早在 Dapr 开源初期,阿里云就开始参与 Dapr 社区建设和代码开发,目前已有两位 Dapr 成员,是 Dapr 项目中除微软之外代码贡献最多的公司。作为 Dapr 项目的早期采用者,…

如何应用数据模型

简介: 数据模型对于常规的数据查询或填写数据提交,是否有使用场景或者价值?数据模型这条路走的是否有问题? 一 前言 Vmo 是我在 18 年发布的一个工具库,用于快速创建数据模型,当时我写了一篇文章《Vmo 前端…

一行代码,揭开 CPU 执行原理!

作者 | 轩辕之风O来源 | 编程宇宙技术计算机如何执行你的代码?知乎上有人提问:电脑怎样执行编程语言的?很多刚刚入坑的小白可能对此完全没有概念,或者模模糊糊知道个大概,我们写下的一行行代码,计算机到底是…

有赞 Flink 实时任务资源优化探索与实践

简介: 目前有赞实时计算平台对于 Flink 任务资源优化探索已经走出第一步。 随着 Flink K8s 化以及实时集群迁移完成,有赞越来越多的 Flink 实时任务运行在 K8s 集群上,Flink K8s 化提升了实时集群在大促时弹性扩缩容能力,更好的降…

mysql怎么看端口号_mysql端口号(怎么查看mysql的端口号)

mysql端口号(怎么查看mysql的端口号)2020-05-07 21:54:58共10个回答如何查看mysql的端口号1使用命令showglobalvariableslikeport;查看端口号2修改端口,编辑/etc/my.cnf文件,早期版本有可能是my.conf文件名,增加端口参数,并且设定端口,注意该端口未被使用,保存退出.总结:注意修…

Serverless 如何在阿里巴巴实现规模化落地?

简介: 2020 年,我们在 Serverless 底层基建上做了非常大的升级,比如计算升级到了第四代神龙架构,存储上升级到了盘古 2.0,网络上进入了百 G 洛神网络,整体升级之后性能提升两倍;BaaS 层面也进行…

php验证mysql内数据_MySQL中数据类型的验证_MySQL

CHARchar (M) M字符,长度是M*字符编码长度,M最大255。验证如下:mysql> create table t1(name char(256)) default charsetutf8;ERROR 1074 (42000): Column length too big for column name (max 255); use BLOB or TEXT insteadmysql>…