从阿里云全面崩溃看，真的需要「快速跨云迁移」

[Jianzs]

众所周知，前天（ 11.12 ）阿里云又双叒宕机了，影响面非常大。一个小时过后，仍然有很多服务还没有完全恢复。这场事故中，给你的产品带来怎样的影响呢？

从这可以看出来，云作为基础设施真的非常重要。但与水电在使用标准上统一，在管理上分布不同（很好地避免了单点），云目前还处于使用标准不统一，各个云服务提供商“各自为政”的情况。这就导致了，在你的服务出现问题后，你却没法及时将业务迁移到另外一家服务提供商。这或许就意味着云距离成为真正的基础设施还需要再进一步，我在之前一篇文章中提到，有效的接入标准或许是促进云成为真正基础设施的关键因素。

你想一下，如果一份代码能够同时适配阿里云、华为云、腾讯云，甚至 Kubernetes ，那么在某一家发生异常后，你就能在极短的时间完成业务服务的迁移。这算不算给自己的服务提供更高的可用性呢？

如何实现云与代码的适配？

这里，代码与云服务提供商的适配有两个方向：1 ）云适配代码：统一多云的接入标准使得相同代码能够在多云执行； 2 ）代码适配云：提供自动化工具实现代码自动对多云的封装适配。

“统一多云的接入标准”目前看来不可能，各家云服务提供商都还在“努力”提供更多的云服务，并且都希望提供独有的特性以构建自身的壁垒，保留自己的用户。

“工具自动化封装代码以适配多云“是一个可以尝试的途径，并且目前也有产品正在试足这个领域，例如 Winglang，也包括我自己 —— Plutolang。

自动化封装代码以适配多云：Plutolang

Plutolang 目标是：让用户仍使用常用的编程语言（如 TypeScript 、Python ），通过程序分析等手段完成业务代码对基础设施的依赖分析，最终，根据分析结果，以及对代码进行拆分，自动完成依赖组件的自动创建，和代码的自动发布。这样使得在保持现有生态便利性的情况下，降低上云的门槛，与多云迁移的负担。

感兴趣可以先看一个 Plutolang 的 Demo 视频，2 分钟，视频基于 TypeScript 实现一个多路由的 HTTP 服务在 AWS 与 K8s 的发布部署： 「 Pluto 云开发」。

Plutolang 目前基于 TypeScript 进行实现，能够完成上图所展示的能力，也是 Demo 视频所对应的内容。用户编写一段 TS 代码，可以包含多个路由，以及 KV 数据库、消息队列等 BaaS 组件，不需要去控制台操作，也不需要编写基础设施代码，执行 pluto deploy 后，就能自动创建依赖的 BaaS 组件，以及将各个路由分别发布成 FaaS 组件。

想要动手试试可以 Fork 这个在线开发环境： Plutolang | CodeSandbox。

回到文章的主题，从上图代码中可以看到，Plutolang 没有直接依赖于各个云平台的 SDK ，而是依赖于 @plutolang/pluto，为开发者屏蔽了底层不同云的异构性。这样，开发者开发时不与具体云服务提供商绑定，利用 Pluto 就能无缝地在多个云之间进行迁移部署。

当然，以上也只是完成计算服务的迁移，那么数据呢？还需要更多的工作去做，至少在计算上能够避免运营商锁定，在紧急时刻，可以及时将业务迁移到备份环境中。

想要进一步了解可以阅读：

• 思路：云真的成为基础设施了吗
• 案例：分享一种更简单的薅 AWS 羊毛姿势
• 实现：Plutolang | GitHub
• 上手试试： Plutolang | CodeSandbox。

同时，Plutolang 还处于非常早期的阶段，欢迎感兴趣的大佬们参与共建，如果你在使用 AWS 或者 K8s ，可以给我们提需求了。同时有任何想法或者建议，都非常欢迎，说出来，你的想法就会在后续版本实现。欢迎加入我们的 Slack 和 钉钉群：40015003990 。

[goodryb]

应用可以迁移，甚至可以提前部署，数据怎么办

[DefoliationM]

不用这么麻烦，直接多个云组 k8s ，一个挂了自动切换到其他的上面去

[jimages]

无状态的应用可以迁移，也很方便，那几个 T 的数据呢？

[Perry]

那么在某一家发生异常后，你就能在极短的时间完成业务服务的迁移。

直觉上感觉迁移所需要的时间一般会大于故障修复所需要的时间。

[salmon5]

你这所谓的迁移，只是迁移几个“集装箱”而已，这个难度不大。
实际的云迁移，业务无中断、客户无感知、XXXXPB 数据、XXXX 亿数据，所谓的迁移工具就是玩具

[salmon5]

“那么在某一家发生异常后，你就能在极短的时间完成业务服务的迁移。”
异想天开、痴人说梦

[salmon5]

@salmon5 #5
实际的云迁移，业务无中断、客户无感知、XXXXPB 数据、XXXX 亿数据，所谓的迁移工具就是玩具
===============================================================
还有成千上万条的屎山业务配置中心配置文件（硬编码的、无效的等等）

[hongfs]

@salmon5 #6 那应该是 多云 来共同提供服务了，不管方案怎么样，数据的同步都是一个问题。

[hallDrawnel]

实现厂商容灾的方案是一开始就将业务多活到多个云服务厂商上。

因为硬盘会坏，提高安全性的方法不是搞一个快速拷贝工具。

[mooyo]

资源能迁，数据呢？

[gamexg]

>可以包含多个路由，以及 KV 数据库、消息队列等 BaaS 组件

这都是小事,
甚至配置之类的都是还能解决,
最大的麻烦是数据迁移.

别说无感知迁移,
停机迁移,数据库导入导出、用户文件传输都需要消耗挺长时间.
另外一个云崩掉已经影响业务时,大概率数据库导出也同样故障了.

我觉得只能考虑跨多云的多活集群了.
不过还真没实际测试过跨机房的数据库,不知道那几个称可以跨机房的数据库方案靠谱不.

[Jianzs]

@DefoliationM 的确是一种解决方案，但是成本可能更高一点

[yinmin]

能切换到“仅使用 Aliyun 的云服务器 ECS”的模式，不依赖 aliyun 的其他服务，可靠性提升一个数量级。

[mightybruce]

一看是 typescript ，好了，可以关掉了。

[joyanhui]

云厂商故障，DDOS,还有域名被莫名其妙暂停解析...

目前我们：

核心数据，核心业务跨云部署。非核心剥离出去。

如果是 app 、物联网之类非 web 项目，单独做一个服务器查询接口反馈给客户端可用的后端地址，多地区多域名多 dns 多厂商部署。

[Jianzs]

@mightybruce 能说说为啥不？采用 TypeScript 的主要原因是目前 Nodejs 的 FaaS 比较成熟

[Jianzs]

@joyanhui 牛，Pluto 可能更希望面向中小企业或者个人开发者这个群体吧，的确有一定体量的企业估计也都在做这方面的准备

[atonganan]

别倦了，再卷这行业就干不下去了

[mightybruce]

首先请先了解一下平台工程 和 gitops 先， 云原生这块众多工具都是 golang 为主， 并且方便对接 kubernetes 。
我就不说各种迁移还有自动化 CICD 的开发了。
你这个是前端的玩具吧。

[Jianzs]

@atonganan Pluto 是解放开发者呀 😉 不用自己去创建部署各种数据库啥的，写个代码一切就都完事了。开发自己玩具的话，利用 FaaS 还可以降低成本

[Jianzs]

@mightybruce #19 感谢！

对接平台的话，我是接入了 Pulumi ，可以对接 K8s 和云，后续还会继续支持 Terraform ，生态更丰富些。

迁移和自动化 CICD 这些，目前是利用 npm 就能安装，还比较轻松，后续再继续优化，的确还没考虑完全，感谢建议！

TypeScript 更多的是给用户提供一个熟悉、简单的界面，本身 TS 编译也比较灵活，还能比较容易对接后面的云平台。如果思路验证可行的话，还会在 Python 等更多的语言上尝试。

[mightybruce]

你说的这些，在云原生社区并不新， 很多大公司都有考虑不能被运营商锁云， 各种开发多得很，光各种集群联邦和魔改方案就很多

[kingjpa]

其实你说的这些难度并不大，只是大部分业务又不是微 X 支付保，停了也没啥，云服务宕机概率极低，
为了这极低的概率，付出的代价太大，人们不愿意做而已。

[Jianzs]

@mightybruce #22 是的，但是对中小企业或者个人开发者，这方面成本还是比较高的（可能这个群体对快速迁移的需求不强

让个人开发者用云的门槛更低，让没有云背景的人也能很好地用上云，其实这是要去做的。目标的话，Pluto 作为一个自动化工具，让开发者还是 **像写单机程序代码一样** ，写出来的程序就能直接部署到云上。

[lindt99cocoa]

++成本;
--性能;

[mytsing520]

按照工信部的要求，目前 ICP 备案是锁接入商的，只做了备案没做接入，ISP 有义务拦截请求。这是合规要求。
就此，一句话，如果是 web 服务，你告诉我怎么解决备案接入的问题。
不要说什么提前多接入，对于中小企业或开发者那都是成本。

[joyanhui]

@mytsing520 我们算 是小微企业，备案先做了腾讯的那边的， 弄完一家就可以上线了这步骤是必须要做的，后面的几家备案慢慢申请就行。 华为那边因为不需要接入就可以使用，暂时没弄，不过经你这么一说，还是要去接入一下。
不过一般跨云部署 2-3 家就足够了。一个是风险规避，一个看厂商的促销活动

不过备案信息和域名实名都会泄露主体下所有的域名，会暴露一些业务出来。当然这个小问题了。

[joyanhui]

其实 跨云迁移 最麻烦的 还是 数据的转移 和 部分有状态服务 真的头疼。

[Jianzs]

@joyanhui 请教一下，你们是用云的 ec2 虚拟机么？还是容器托管？ faas ？多云的适配是咋做的？

[Maboroshii]

数据不丢失，那都是万幸！

[xuanbg]

1 、成本翻倍
2 、你能确定迁移所需要的时间比故障恢复的时间短？

所以，看起来很好的东西不见得是有价值的

[keepRun]

直接混合使用多个云，不同的业务用不同的云，省的一次性全挂了。至于迁移，海量数据迁移才是最麻烦的，数据在迁移中错了就麻烦大了，以及业务还是得运行，不可能客户等你迁移完。
感觉这种应该再初始架构设计时就应该避免风险，而不是事发时迁移，事发时迁移就是个伪需求。

[germain]

你们不知道 DR 吗？

[1145148964]

工程学上有相关的论证：这种增加系统复杂度的行为只会导致成本增加。更容易出现故障。
比如四个发动机的飞机看起来更可靠，实际上成本飙升，故障率更高。

[murmur]

多云同步用的是宝贵的公网带宽，至少云内是局域网暂时还不要钱

[Hyvi]

很需要，对于国内外部署的也是非常需要

[guyanyouyou]

数据可以迁，服务可以迁移，但是备案咋办

[nothingistrue]

云服务不容易挂，你这个单点的「替代人工的自动化程序」，那可是非常容易出 bug ，非常频繁的因为水土不服而失效。

[wyy]

得多云多活把？
出故障后才迁移，先不说你自己的服务和数据能不能快速迁移走，你想迁到哪，对方也得有相应的资源能快速提供出来把

[version]

这明明是广告贴啊...阿里云崩溃和这个有啥关系...

[kuituosi]

这方向都是错的

[evilmiracle]

不需要多云迁移，想要解决单云故障带来的单点问题，只需要把同样的应用和数据部署到多套云上即可；所有的应用和数据保持一致，部署在阿里云，腾讯云，天翼云，AWS ，GoogleCloud ，Azure ；所有数据库和配置文件，走专线完成同步，所有应用在发版的时候，每个云单独部署，云前走负载均衡，流量平均分摊到各个云上。

这样可以保证当某个云挂掉之后，可以实现秒切，用户无感知，因为部署在其他云上的应用和数据是实时同步的，当然前提是数据和配置文件的同步没有问题

[gimp]

像阿里云这次这么大的故障，躺平就完事儿了。

[salmon5]

@evilmiracle #42 不切实际，多部署 1 个云，成本翻 1 倍，你这成本 6 倍。工程复杂度指数上升。更容易出故障。
假如你的小区物业门禁坏了 1-2 小时，5-10 年碰到了一次，你会一怒之下再买几套房，来防范这种风险？

[chendy]

@Livid 推广内容

[salmon5]

@evilmiracle #42 完全是纸上谈兵。

[salmon5]

@gimp #43 ，大部分公司只能躺平，这样成本是最低的。

[salmon5]

躺平不代表不追究阿里云的责任，可以要求给出故障报告、上门解释道歉、后续的改进措施、赔偿等。

[Masoud2023]

那你来从这个方案的角度来讲一下怎么处理阿里云 OSS 这样级别的问题？

[coolcoffee]

本来云服务就已经很贵了，然后再来个费用 x2 、x3 ，云厂商做梦都要笑醒。

[vanityfairn]

推广自己的东西就就推广呗。当个标题党干啥呢？提升容灾能力，不做多套云部署？就是做一个拷贝工具么？
云服务商这么大的故障，中小公司遇到就是躺平好了。要求服务商出报告，谈赔偿就好了

[mightybruce]

大家散了吧， 楼主很明显不是做基础设施开发或运维开发， 前端还是和基础设施中间件团队多交流吧， 增加一些知识了解先。

[pkoukk]

业内公司都是多云融合，一套服务会同时布在几个不同的云服务商那里，然后做内网打通
不需要迁移
了解下业内行情再做东西吧，别闭门造车

[pkoukk]

@salmon5 #44 我司就是云备胎，有不少公司就这么干了。成本根本不会翻倍，原本你需要 100 台机器，100 台全在阿里云。现在 50 台阿里，50 台腾讯，20 台备胎小厂就行了，谁说非要全套都在一个厂了？多云混合网络互通的方案各家都有，还有专门做多云运维管理工具的，这行已经很成熟了，不是纸上谈兵。

[bthulu]

我司就租了一架 B2 轰炸机装了个机房在里面, 哪里崩溃了就飞哪里去.
目前存在的问题是, 当同时多地崩溃时, 一架 B2 不太够用.
现在公司正在讨论全球每百万平方公里配一架 B2, 就是费用有点大, 最近正在寻求新的全球全天候战略合作伙伴.

[cnkuner]

多云多活不是做不到，但是成本直接爆炸，这不是个技术问题啊。

[shuson]

cloud exit is coming

[Jianzs]

@Hyvi 的确，国内外部署是挺适合的场景，V 友有这方面的需要么？

[Jianzs]

很多 V 友都提到多云多活，但我个人感觉，这只能依赖于每个云都提供，且使用方式相同的计算组件吧，比如容器托管或 Kubernetes ，但是随着 Function as a Service 等能力的增强，其实利用好这些能力是有助于降低以往部署方式的成本的，而 FaaS 的适配方式各个云有显著的不同，这种情况下是不是就比较难做到多云多活了？

个人观点，欢迎来喷。

[Jianzs]

@mightybruce #52
@pkoukk #53 感谢建议，经验欠缺，会持续了解学习

[evilmiracle]

我知道肯定有老哥说成本问题，我的意思是，没钱，没钱你玩什么云，我们都是开劳斯莱斯，都是奔驰，你没钱，没钱你自建机房吧，买个 nas 当服务器就行

@salmon5

[salmon5]

@pkoukk #54 这种不是多云多活。伪多云。OSS/COS 数据要 2 份、DB 热数据要 2 份，还有数据同步的专线费。成本增加 30-40%左右。

[fly2never]

多云管理 CMP

[salmon5]

@evilmiracle 劳斯莱斯？我还湾流 G700 。
几台服务器可以随便折腾。正常的公司都要考虑成本问题。

[mightybruce]

FaaS 本身有很多缺陷，已经不是云计算的主要兴趣所在。一般来说 faas 和 baas 一起使用。faas 是不通用的，每个云厂商必须要做相当多的基础设施开发兼容自身的下层设施才能让 faas 可用，另外 faas 抽象层次更高， 虽然方便，但是对于资源管理和服务控制反而更差，其次 faas 有状态服务并不好、冷加载时间长，做些无状态计算还行。 开源的 faas 是不足以 直接拿来用的，大厂都是在开源基础上的魔改
常见几个 serverless 开发 knative 、openfunciton 、kubbeless 、openfaas 可以去了解了解先。
FaaS 基本是基于服务网格之上结合这些 knative 、openfunctions 上的开发 ，

[salmon5]

两地三中心、多云多活本来就是老掉牙的架构了。公司有钱就折腾呗。反正这玩意大概率是忽悠，多少年可能用到一次。等用到的时候，当年干活领 KPI 的早跑路了。

[salmon5]

@pkoukk #54
这种大部分是基于商务考虑的，这个云消费一点、那个云消费一点，能有更好的议价权。防止价格上被 1 个云吃定了。
实际多云 K8S 要多云、LB 负载均衡要多云、RDS 要多云、OSS 要多云等等一大堆设施要多云，这个要自己造很多轮子。
更不靠谱。

[Felldeadbird]

备案怎样解决？嘿嘿。

[txhsj]

大家考虑跨云多活的时候都不考虑跨云带宽么，带宽太太太太贵，已经成为我司做跨云多活的阻塞点了

[txhsj]

都不考虑成本吗

[OneMan]

不要当国内这些云什么兼容胶水，没有前途。
听着很美好，现实超骨干。换个方向吧。

[opengps]

把云做大都这么难了，你再把多云做好，难上加难，你需要的根本不应该是多云迁移，而是异地多活，这方面有成熟案例可参考，不用自己另外找更费成本的方案

[unco020511]

绝大部分服务宕机都没啥大事,而且宕机也是小概率事件

[sumarker]

把数据异地容灾备份做一下，避开业务高峰升级，云服务挂了损失还能稍微小点，如果业务高峰期服务器挂了，那就只能去买彩票了

[evilmiracle]

下云，真正的异地多活才是最靠谱的，自建数据中心，租机柜，运营商签专线做数据一致性，这些东西做下来比多云成本低很多

[sampeng]

如果只是代码。。
argocd 只需要改一个配置提交。就全过去了。。
那么我就算 100T 数据在 oss 上吧，我就算你光纤聚合。100G 通道。需要 2.8 个小时。。黄花菜都凉了

[sampeng]

说句不客气的话。LZ 不要想着发现一个华点就想当然的解决一锤子问题。这不仅仅是技术问题，还要涉及商务，基础数据，全局架构，公司多部门协同，安全，权限划分等等一系列技术/人力/资金等等方面问题。你只看到把代码迁移走。。光 object 数据对于运维团队要做多云融合都是要折腾一段时间的。你就想靠一个程序解决企业级的多云一键迁移？真不是打击你积极性，好高骛远，信息茧房严重。

[Jianzs]

@OneMan
@sampeng #77
@opengps

感谢 V 友，会继续明确目标群体，说清楚解决的问题。目前想的是，不想做个大事，只是想降低一点云的使用门槛，让没有云背景的开发者也能用上云。

[opengps]

@Jianzs 不如换个思维，云的概念过于先进，实际对于个人用户的使用场景，是配置更低的虚拟机而已。优势是更廉价，云虚拟机，稳定性比 vps 好点，价格比 vps 低点，网络质量直接上升为 bgp 而不是多线，后台支持功能多了点，直接体会仅此而已

[joyanhui]

@Jianzs
一部分在云服务器里面 这部分不需要专门适配。
一部分用各家的函数计算 华为 阿里 腾讯 aws 都支持自定义运行时，不需要专门适配 只有少数业务需要微调。

需要和云厂商的交互的功能，单独一个接口，由这一个接口转发后统一调度各家云厂商。

跨云部署，一般 2 家就够了，适配没那么难。难的依旧是管理和公网通讯的延迟和带宽占用。