写点什么

多云一定会起到容灾作用吗?

2020 年 3 月 17 日

多云一定会起到容灾作用吗?

前面两篇讲了容灾建设的一些概念,没看过的朋友可以看一下:



在二、三篇中,在容灾建设上,我们已经讲得差不多了,一个很显著的结论就是:


容灾这个事情,跟多不多云没有任何关系,单个云厂商的公有云里照样可以保障容灾,复杂度还要比多云低一些,也更具备可操作性。


既然结论有了,那为什么还要讲多云呢?


只是想从另一个角度看看,如果选择多云,实施层面会有哪些问题和难点,后面再看方案的时候,也可以更务实一些。


分几个场景讲:


第一,如果只用到了公有云的 IAAS 层。


也就是只用到了虚拟机这样产品,上层的任何数据库、缓存、消息以及应用,都是自己在虚拟机上部署的,没有用到云上的 PAAS 的产品。


如果是这样,其实 A 云、Q 云,还是 M 云,只是基础设施 IAAS 提供方不一样而已,本质上并没有什么差别。


所以,这种仅 IaaS 应用的场景下,多云方案完全可以退化成不同 IDC 或不同 AZ 间的高可用解决方案。


之前我们提到过,如果是同城不同 AZ,在物理距离上足够远,电力和网络设施也完全是独立的,并不会因为单个 AZ 故障,导致另一个 AZ 故障。


这种情况下,两个 AZ 同时故障的概率是非常小的,但是如果非要说,来个大范围地震、海啸,或者整个城市被黄浦江淹了,让原子弹给炸了,那也没招,但是实际概率有多大,算算就知道了。


所以,多云不是不行,但是这里隐含的前提条件是,业务只使用了云上的 IAAS 层。


多云的必要性大不大,是不是单云的不同 AZ 方案更划算,其实评估下就清楚了。


况且,这里多云之间跨云厂商的专线拉通,这里面又是很灰色的意识事情,成本高,各方利益博弈,而且出了问题,到底算哪头的也不知道,最后就是不了了之。


第二,如果业务不仅仅用了 IAAS 层,还用到了 PaaS 层的产品,比如数据库、缓存、消息、云通信等等。


业务一旦跟这些产品耦合,那这种场景就复杂了,就目前情况看,多云基本不太可能。


因为目前从各大云厂商的 PaaS 产品来说,并没有统一的标准,也不太可能有统一标准,所以提供的 API 也好,还是 SDK 也好,基本都是根据自己的产品设计封装出来的,即使是原生 API,实际使用的时候,也会有大大小小的差别。


所以这种情况下,对于用户就要有大量的兼容类开发工作要做,甚至有些场景会对业务逻辑有侵入。


从管理维度来说,也增加了复杂性,因为一台阿里云的 RDS 和一台腾讯云的 CDB 性能指标、所处网络环境、处理能力等,也没法完全标准,定价也不一样,等等等等,各种不同。


管理复杂度也会增大很多,复杂度上升,必然带来成本上升,是不是划算,不知道。


所以,从这两个角度讲,业务一旦依赖了一个云厂商的 PaaS 产品,基本也就跟这家云厂商绑定了,基本就不具备做多云的条件了。


第三,未来会是什么走向?


其实 IaaS 层跟业务基本没有耦合,这个不会太大的障碍。


前面说的,主要问题还是在 PaaS 层,各厂商无法统一。那怎么办呢?可能这么几条路:


  • 期望云计算这个行业有个大一统的标准出来,所有云厂商都按这个标准来做,但是这个很难。

  • 有一类公司出来,专门做兼容各大云厂商PaaS产品的中间层SDK出来,对于企业和客户来说,也算是一种统一,但是这个也很难,因为这样的产品做起来不难,但是很麻烦,而且有多大市场也不好说,所以有点费力不讨好。

  • 期待面向应用的云产品能力越来越强大,比如现在的Spring,在AWS上就有Spring for AWS的版本,什么意思呢,就是我们如果用的是AWS的服务,不管我们用EC2,S3,还是什么ElasticCache或者RDS等等,通过Spring的API直接访问,对业务来说,这些产品组件就是一个对象而已,直接new出来,直接用。不过现在spring也只有for aws,并没有for其它云。如果按照这个模式,spring家族融入到整个云计算生态中,成为应用层云化实时上的标准,这个问题也会有一个不错的解决方案,不知道会不会有朝一日有大一统的机会。


第三部分简单总结一下,是想表达什么意思呢,就是未来短期貌似还看不到在应用层讲各大云厂商 PaaS 产品统一的希望。


第四,目前业界的多云现状。


这里仅说我调研和了解到的情况,目前业界大多数公司所谓的多云,是将一些无状态的应用或接入层分几个云部署一下,只是容量上的冗余建设,但实际并起不到容灾作用。


这么做无非两个原因:


  • 通过多云的引入,带来的竞争,从而带来成本上价格比拼,以及云厂商服务质量的提升。像前面说的,如果一旦跟一家云的PaaS绑定,只能选择一家云厂商,没有了竞争,在很多方面就少了博弈的筹码。

  • 单云的节点分布问题,比如在海外,早期AWS的节点质量明显会好一些,服务也完善,所以有些海外接入层的需求就选择AWS,但是国内有可能还是腾讯云、阿里云等等。当然现在国内的云在海外的布局也已经做的很不错了。


最后,总结一下


多云跟容灾和高可用完全两码事,不要扯在一起,多云也解决不了容灾和高可用问题,最终还是得自己的技术体系支持才可以。


多云不解决整体容灾,但是可以考虑局部高可用,案例见上面。


多云模式其实是一个管理复杂度很高的事情,甚至在业务与云的耦合层面,就已经决定了一个系统压根不具备多云建设模式。


但是业务所在的主要的云厂商故障,多云一样还是没用,比如前面阿里云分布式存储 IO HANG 导致的大面积故障,即使有腾讯云、AWS 或者其他人做备份,会真的有用吗?


本文转载自成哥的世界公众号。


原文链接:https://mp.weixin.qq.com/s/NDEzUt3nL0NfnlKy61V2PQ


2020 年 3 月 17 日 22:13351

评论

发布
暂无评论
发现更多内容

架构师训练营 - 第 9 周课后作业(1 期)

阿甘

架构 2 期 - 第五周作业(1)

浮生一梦

极客大学架构师训练营 第五周 2组

设计一个秒杀系统,主要的挑战和问题有哪些?核心的架构方案或者思路有哪些?

Jacky.Chen

技术选型 - 学习总结笔记

Xuenqlve

JVM

ROOT

java实现一致性 hash 算法

Mars

一致性Hash算法

第九周作业

TheSRE

极客大学架构师训练营

架构师训练营第九周作业

Shunyi

极客大学架构师训练营

第5周作业-一致性hash算法实现

Rocky·Chen

一致性Hash算法

架构师训练营第九周作业

听夜雨

极客大学架构师训练营

第九周总结

Geek_ac4080

架构师训练营week09

FG佳

极客大学架构师训练营

架构师训练营第九周课后作业

Gosling

极客大学架构师训练营

架构师训练营第九周学习总结

文智

极客大学架构师训练营

架构师训练营第五周作业

张浩

第五周学习总结

Mr_No爱学习

c语言只是总结大全,干货收藏

C语言与CPP编程

面试 编程语言 C语言

架构师训练营第 1 期 week9

张建亮

极客大学架构师训练营

架构师训练营第五周总结

张浩

架构2期第5周作业

supersky6

架构师训练营week09总结

FG佳

极客大学架构师训练营

架构师训练营——week09

睁眼看世界

极客大学架构师训练营

第九周总结

睁眼看世界

极客大学架构师训练营

第五周笔记

willson

极客大学架构师训练营

第 5 周作业

Steven

极客大学架构师训练营

架构师训练营第九周作业

月殇

极客大学架构师训练营

架构师训练营第 5 周课后练习

菜青虫

极客大学架构师训练营

请简述 JVM 垃圾回收原理。

博古通今小虾米

架构师训练营第 5 周学习总结

菜青虫

极客大学架构师训练营

第九周作业

Geek_ac4080

架构师训练营第九周总结

月殇

极客大学架构师训练营

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

多云一定会起到容灾作用吗?-InfoQ