首页 > 其他分享 >终于有人讲清楚什么是云计算的业务永续和多活

终于有人讲清楚什么是云计算的业务永续和多活

时间:2022-10-31 23:12:16浏览次数:50  
标签:讲清楚 永续 99.999% 业务 计算 多活 节点

从苹果供应链的业务永续说起,每次苹果出新机,全球各地旗舰店就大排长龙统一发售,堪称全球化的一景。有没有想过,iPhone 是怎么保障全球消费者能在一天内买到几百万部手机的?

终于有人讲清楚什么是云计算的业务永续和多活终于有人讲清楚什么是云计算的业务永续和多活

很简单:同时用多个供应商。苹果供应链非常发达,仅组装厂全球就有 18 家,如富士康 7 家、广达 3 家、和硕 2 家。而在每个零部件环节也都会有多个供应商支持(用了哪几家供应商都成了新闻)。并在产品层面采取了统一标准,确保哪怕地震、洪水也能按时交付同样质量的产品。

反过来说,一些较小的手机厂商经常因为“泰国洪水”、“日本地震”、“台湾断电”而无法正常发货。

用互联网行业的话来说,苹果做到了“业务永续”。而其它手机商出现了典型的“单点故障”导致的“停摆”。

小结:供应链出现问题就会影响到品牌形象。所以业务永续是你和客户之间的约定,“多个供应商”是你做到这个约定的手段之一。

而方法呢?业务永续首先是架构设计层的职责。尽可能消除单点故障风险,做好关键节点的冗余。换成人话就是:想好可能出现问题的地方,做好准备,比如说多备点存货,用多个供应商,避免出现一个天灾人祸你就跪了的局面。

云计算故障了,但为什么有的网站没挂

供应链不是制造业独有的,互联网行业也是如此。云计算可以看作是很多公司的供应商,当它宕机时,有很多公司也会受到影响。

比如说,去年 AWS 弗吉尼亚节点宕机,导致包括 Netflix、Airbnb、Product Hunt、Medium、SocialFlow、Buffer、GroupMe、Pocket、Viber 和亚马逊 Echo 等停摆。而国内云计算厂商也遭遇过雷击、挖掘机、断电等多种问题。

终于有人讲清楚什么是云计算的业务永续和多活终于有人讲清楚什么是云计算的业务永续和多活

云计算出现宕机当然是导致网站停摆的导火索,持续提高稳定性是云计算公司该承担的责任没跑。但大部分人没有看到的是,同样是这个节点故障,却还是有很多网站并没有挂掉。真正该问的问题是,为什么有的挂了而有的没挂!

“因为不仅仅是在弗吉尼亚有服务器,一出问题我就切到另一个节点了。”狡兔三窟的客户都是这么回答的。“云计算厂商只承诺全年 99.999% 的时间是可靠的,剩下的时间要看运气了。如果我只是依赖一个节点,它挂我就一定会挂掉,就会影响品牌形象。”

可能会出问题的就必然会出问题,这就是墨菲定律。除了自己应用层的可靠性,在基础资源上索性就在不同的“可用区”(AZ)、“地域节点”(Region)都做一些部署。一些大型的公司甚至是在不同的云计算厂商之间都做了准备。

云计算公司为什么不做“异地多活”

还有人好奇,为什么 AWS 和阿里云会出问题?云计算不也是“异地多活”吗?

这里有个致命的错误,云计算行业尤其是 IaaS 层一般会提供一个可用性指标(SLA),例如说 99.999%,即承诺全年有这个概率是可用的。而比如淘宝为了实现业务永续做了一个技术方案“异地多活”,这是它对于自己消费者的承诺(保证买买买不停)的实现手段。淘宝用了多个 99.999% 的节点同时运行,只要不是这些节点同时挂,它就不会挂。(不用说,难度很高也很贵)

它们之间的关系是:消费者——>亚马逊网站、淘宝——>(云计算 1 + 云计算 2 + 云计算 3)。云计算 1、2、3 随意挂掉一个都不会影响业务的稳定。

也就是说靠谱的云计算厂商会告诉你自己服务能力的边界和极限是什么,使用它们的时候要根据它们的能力来规划自己的业务设计,以达到自己的业务永续。

打个比方,你把女朋友的照片同时放在 iCloud、电脑、移动硬盘里,只要不是 3 个同时丢失,你女朋友的照片就不会丢。但如果只存了一个地方,不幸又丢失了,那你说该怪谁?

总结
  1. 业务永续是你和客户之间的约定,“高可用性”首先是架构设计层的职责
  2. 云计算行业不存在“异地多活”的说法,一般只承诺 99.999% 的可用性(SLA)
  3. 但你可以用多个云计算节点来设计出 100% 业务永续的方案

标签:讲清楚,永续,99.999%,业务,计算,多活,节点
From: https://www.cnblogs.com/cainiaoyige1/p/16846238.html

相关文章

  • 防抖--如何讲清楚函数防抖?
    首先函数为什么会抖呢?来列举一个实际的应用场景,例如百度的搜索提示:你可以看到,当你在输入框每输入一个字符的时候百度都会不断的根据当下的输入给予新的提示----那么,如......
  • RedisGraph多活设计方案功能测试
    该文档主要是针对RedisGraph多活设计方案的功能测试,来说明方案是可实施是可行的。该方案设计文档参见上一篇文章 ​​RedisGraph图形数据库多活设计方案​​功能测试准备条......
  • RedisGraph图形数据库多活设计方案
    目前CMDB使用RedisGraph存储各种关系映射数据,数据的重要性不言而喻,所以数据的防灾、高性能及高可用非常重要。目前现状RedisGraph是单节点运行,存在数据防灾、高可用、性能不......
  • 草图?不管黑猫白猫,能快速、有效把你的设计理念讲清楚才行
    下午我被叫去参加“合作服务商资金安全解决方案”项目的codereview。对程序实现逻辑上存疑。简单听他们了解了一下需求逻辑。然后,果然发现逻辑有疏漏。为了表达清楚我的意......
  • 4859字,609行,一次讲清楚JVM运行数据区
    大家好,我是狂野君,这篇文章咱们继续聊下JVM性能优化的问题这篇文章主要介绍下JVM的运行数据区相关的内容,包括:程序计数器虚拟机栈本地方法栈堆方法区案例和总结好了,开始干货......
  • 老掉牙的 synchronized 锁优化,一次给你讲清楚!
    我们都知道synchronized关键字能实现线程安全,但是你知道这背后的原理是什么吗?今天我们就来讲一讲synchronized实现线程同步背后的原因,以及相关的锁优化策略吧。synchron......
  • 运维思考:聊聊高可用的“异地多活”架构设计
    前言后台服务可以划分为两类,有状态和无状态。高可用对于无状态的应用来说是比较简单的,无状态的应用,只需要通过F5或者任何代理的方式就可以很好的解决。后文描述的主要是针......
  • 周年庆活动火热进行中!你想了解的都在这,点击即可查看更多活动详情!
    好消息!好消息!好消息!为迎接引迈信息三周年来临之际,我司特推出此次周年庆典活动,以此回馈这些年来一直支持着我们的客户与合作商们。这三年走来,引迈不断创新,不断突破,致力......
  • redis异地多活
    what:异地多活:简单来说,就是在不同地域建立数据中心,每个数据中心在日常使用中都需要正常接入业务流量,做业务支撑。异地多活,也属于分布式架构的系统。......