这是一个创建于 165 天前的主题，其中的信息可能已经有所发展或是发生改变。
众所周知，前天（ 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 。
 |
1
goodryb 165 天前
应用可以迁移，甚至可以提前部署，数据怎么办
|
 |
2
DefoliationM 165 天前 via Android  1
不用这么麻烦，直接多个云组 k8s ，一个挂了自动切换到其他的上面去
|
 |
3
jimages 165 天前
无状态的应用可以迁移，也很方便，那几个 T 的数据呢？
|
 |
4
Perry 165 天前 via iPhone
那么在某一家发生异常后，你就能在极短的时间完成业务服务的迁移。
直觉上感觉迁移所需要的时间一般会大于故障修复所需要的时间。 |
 |
5
salmon5 165 天前 6
你这所谓的迁移，只是迁移几个“集装箱”而已，这个难度不大。
实际的云迁移，业务无中断、客户无感知、XXXXPB 数据、XXXX 亿数据，所谓的迁移工具就是玩具 |
|
6
salmon5 165 天前 17
“那么在某一家发生异常后，你就能在极短的时间完成业务服务的迁移。”
异想天开、痴人说梦 |
|
7
salmon5 165 天前
@salmon5 #5
实际的云迁移，业务无中断、客户无感知、XXXXPB 数据、XXXX 亿数据，所谓的迁移工具就是玩具 =============================================================== 还有成千上万条的屎山业务配置中心配置文件（硬编码的、无效的等等） |
 |
9
hallDrawnel 165 天前
实现厂商容灾的方案是一开始就将业务多活到多个云服务厂商上。
因为硬盘会坏，提高安全性的方法不是搞一个快速拷贝工具。 |
 |
10
mooyo 165 天前
资源能迁，数据呢？
|
 |
11
gamexg 165 天前
>可以包含多个路由，以及 KV 数据库、消息队列等 BaaS 组件
这都是小事, 甚至配置之类的都是还能解决, 最大的麻烦是数据迁移. 别说无感知迁移, 停机迁移,数据库导入导出、用户文件传输都需要消耗挺长时间. 另外一个云崩掉已经影响业务时,大概率数据库导出也同样故障了. 我觉得只能考虑跨多云的多活集群了. 不过还真没实际测试过跨机房的数据库,不知道那几个称可以跨机房的数据库方案靠谱不. |
 |
12
Jianzs OP @DefoliationM 的确是一种解决方案，但是成本可能更高一点
|
 |
13
yinmin 165 天前
能切换到“仅使用 Aliyun 的云服务器 ECS”的模式，不依赖 aliyun 的其他服务，可靠性提升一个数量级。
|
 |
14
mightybruce 165 天前 5
一看是 typescript ，好了，可以关掉了。
|
 |
15
joyanhui 165 天前 1
云厂商故障，DDOS,还有域名被莫名其妙暂停解析...
目前我们： 核心数据，核心业务跨云部署。非核心剥离出去。 如果是 app 、物联网之类非 web 项目，单独做一个服务器查询接口反馈给客户端可用的后端地址，多地区多域名多 dns 多厂商部署。 |
|
16
Jianzs OP @mightybruce 能说说为啥不？采用 TypeScript 的主要原因是目前 Nodejs 的 FaaS 比较成熟
|
 |
18
atonganan 165 天前
别倦了，再卷这行业就干不下去了
|
|
19
mightybruce 165 天前 1
首先请先了解一下平台工程 和 gitops 先， 云原生这块众多工具都是 golang 为主， 并且方便对接 kubernetes 。
我就不说各种迁移还有自动化 CICD 的开发了。 你这个是前端的玩具吧。 |
|
20
Jianzs OP @atonganan Pluto 是解放开发者呀 😉 不用自己去创建部署各种数据库啥的，写个代码一切就都完事了。开发自己玩具的话，利用 FaaS 还可以降低成本
|
|
21
Jianzs OP @mightybruce #19 感谢！
对接平台的话，我是接入了 Pulumi ，可以对接 K8s 和云，后续还会继续支持 Terraform ，生态更丰富些。 迁移和自动化 CICD 这些，目前是利用 npm 就能安装，还比较轻松，后续再继续优化，的确还没考虑完全，感谢建议！ TypeScript 更多的是给用户提供一个熟悉、简单的界面，本身 TS 编译也比较灵活，还能比较容易对接后面的云平台。如果思路验证可行的话，还会在 Python 等更多的语言上尝试。 |
|
22
mightybruce 165 天前
你说的这些，在云原生社区并不新， 很多大公司都有考虑不能被运营商锁云， 各种开发多得很，光各种集群联邦和魔改方案就很多
|
 |
23
kingjpa 165 天前
其实你说的这些难度并不大，只是大部分业务又不是微 X 支付保，停了也没啥，云服务宕机概率极低，
为了这极低的概率，付出的代价太大，人们不愿意做而已。 |
|
24
Jianzs OP @mightybruce #22 是的，但是对中小企业或者个人开发者，这方面成本还是比较高的（可能这个群体对快速迁移的需求不强
让个人开发者用云的门槛更低，让没有云背景的人也能很好地用上云，其实这是要去做的。目标的话，Pluto 作为一个自动化工具，让开发者还是 **像写单机程序代码一样** ，写出来的程序就能直接部署到云上。 |
 |
25
lindt99cocoa 165 天前
++成本;
--性能; |
 |
26
mytsing520 165 天前
按照工信部的要求，目前 ICP 备案是锁接入商的，只做了备案没做接入，ISP 有义务拦截请求。这是合规要求。
就此，一句话，如果是 web 服务，你告诉我怎么解决备案接入的问题。 不要说什么提前多接入，对于中小企业或开发者那都是成本。 |
|
27
joyanhui 165 天前
@mytsing520 我们算 是小微企业，备案先做了腾讯的那边的， 弄完一家就可以上线了这步骤是必须要做的，后面的几家备案慢慢申请就行。 华为那边因为不需要接入就可以使用，暂时没弄，不过经你这么一说，还是要去接入一下。
不过一般跨云部署 2-3 家就足够了。一个是风险规避，一个看厂商的促销活动 不过备案信息和域名实名都会泄露主体下所有的域名，会暴露一些业务出来。当然这个小问题了。 |
|
28
joyanhui 165 天前
其实 跨云迁移 最麻烦的 还是 数据的转移 和 部分有状态服务 真的头疼。
|
 |
30
Maboroshii 165 天前 via Android
数据不丢失，那都是万幸！
|
 |
31
xuanbg 165 天前
1 、成本翻倍
2 、你能确定迁移所需要的时间比故障恢复的时间短？ 所以，看起来很好的东西不见得是有价值的 |
 |
32
keepRun 164 天前
直接混合使用多个云，不同的业务用不同的云，省的一次性全挂了。至于迁移，海量数据迁移才是最麻烦的，数据在迁移中错了就麻烦大了，以及业务还是得运行，不可能客户等你迁移完。
感觉这种应该再初始架构设计时就应该避免风险，而不是事发时迁移，事发时迁移就是个伪需求。 |
 |
33
germain 164 天前
你们不知道 DR 吗？
|
 |
34
1145148964 164 天前 6
工程学上有相关的论证：这种增加系统复杂度的行为只会导致成本增加。更容易出现故障。
比如四个发动机的飞机看起来更可靠，实际上成本飙升，故障率更高。 |
 |
35
murmur 164 天前 2
多云同步用的是宝贵的公网带宽，至少云内是局域网暂时还不要钱
|
 |
36
Hyvi 164 天前
很需要，对于国内外部署的也是非常需要
|
 |
37
guyanyouyou 164 天前
数据可以迁，服务可以迁移，但是备案咋办
|
 |
38
nothingistrue 164 天前
云服务不容易挂，你这个单点的「替代人工的自动化程序」，那可是非常容易出 bug ，非常频繁的因为水土不服而失效。
|
 |
39
wyy 164 天前
得多云多活把？
出故障后才迁移，先不说你自己的服务和数据能不能快速迁移走，你想迁到哪，对方也得有相应的资源能快速提供出来把 |
 |
40
version 164 天前
这明明是广告贴啊...阿里云崩溃和这个有啥关系...
|
 |
41
kuituosi 164 天前
这方向都是错的
|
 |
42
evilmiracle 164 天前
不需要多云迁移，想要解决单云故障带来的单点问题，只需要把同样的应用和数据部署到多套云上即可；所有的应用和数据保持一致，部署在阿里云，腾讯云，天翼云，AWS ，GoogleCloud ，Azure ；所有数据库和配置文件，走专线完成同步，所有应用在发版的时候，每个云单独部署，云前走负载均衡，流量平均分摊到各个云上。
这样可以保证当某个云挂掉之后，可以实现秒切，用户无感知，因为部署在其他云上的应用和数据是实时同步的，当然前提是数据和配置文件的同步没有问题 |
 |
43
gimp 164 天前
像阿里云这次这么大的故障，躺平就完事儿了。
|
|
44
salmon5 164 天前 1
@evilmiracle #42 不切实际，多部署 1 个云，成本翻 1 倍，你这成本 6 倍。工程复杂度指数上升。更容易出故障。
假如你的小区物业门禁坏了 1-2 小时，5-10 年碰到了一次，你会一怒之下再买几套房，来防范这种风险？ |
|
46
salmon5 164 天前
@evilmiracle #42 完全是纸上谈兵。
|
|
48
salmon5 164 天前
躺平不代表不追究阿里云的责任，可以要求给出故障报告、上门解释道歉、后续的改进措施、赔偿等。
|
 |
49
Masoud2023 164 天前
那你来从这个方案的角度来讲一下怎么处理阿里云 OSS 这样级别的问题？
|
 |
50
coolcoffee 164 天前
本来云服务就已经很贵了，然后再来个费用 x2 、x3 ，云厂商做梦都要笑醒。
|
 |
51
vanityfairn 164 天前
推广自己的东西就就推广呗。当个标题党干啥呢？提升容灾能力，不做多套云部署？就是做一个拷贝工具么？
云服务商这么大的故障，中小公司遇到就是躺平好了。要求服务商出报告，谈赔偿就好了 |
|
52
mightybruce 164 天前 2
大家散了吧， 楼主很明显不是做基础设施开发或运维开发， 前端还是和基础设施中间件团队多交流吧， 增加一些知识了解先。
|
 |
53
pkoukk 164 天前 1
业内公司都是多云融合，一套服务会同时布在几个不同的云服务商那里，然后做内网打通
不需要迁移 了解下业内行情再做东西吧，别闭门造车 |
|
54
pkoukk 164 天前
@salmon5 #44 我司就是云备胎，有不少公司就这么干了。成本根本不会翻倍，原本你需要 100 台机器，100 台全在阿里云。现在 50 台阿里，50 台腾讯，20 台备胎小厂就行了，谁说非要全套都在一个厂了？多云混合网络互通的方案各家都有，还有专门做多云运维管理工具的，这行已经很成熟了，不是纸上谈兵。
|
 |
55
bthulu 164 天前
我司就租了一架 B2 轰炸机装了个机房在里面, 哪里崩溃了就飞哪里去.
目前存在的问题是, 当同时多地崩溃时, 一架 B2 不太够用. 现在公司正在讨论全球每百万平方公里配一架 B2, 就是费用有点大, 最近正在寻求新的全球全天候战略合作伙伴. |
 |
56
cnkuner 164 天前 via Android 1
多云多活不是做不到，但是成本直接爆炸，这不是个技术问题啊。
|
 |
57
shuson 164 天前
cloud exit is coming
|
|
59
Jianzs OP 很多 V 友都提到多云多活，但我个人感觉，这只能依赖于每个云都提供，且使用方式相同的计算组件吧，比如容器托管或 Kubernetes ，但是随着 Function as a Service 等能力的增强，其实利用好这些能力是有助于降低以往部署方式的成本的，而 FaaS 的适配方式各个云有显著的不同，这种情况下是不是就比较难做到多云多活了？
个人观点，欢迎来喷。 |
|
60
Jianzs OP |
|
61
evilmiracle 164 天前
|
 |
63
fly2never 164 天前
多云管理 CMP
|
|
64
salmon5 164 天前
@evilmiracle 劳斯莱斯？我还湾流 G700 。
几台服务器可以随便折腾。正常的公司都要考虑成本问题。 |
|
65
mightybruce 164 天前 1
FaaS 本身有很多缺陷，已经不是云计算的主要兴趣所在。一般来说 faas 和 baas 一起使用。faas 是不通用的，每个云厂商必须要做相当多的基础设施开发兼容自身的下层设施才能让 faas 可用，另外 faas 抽象层次更高， 虽然方便，但是对于资源管理和服务控制反而更差，其次 faas 有状态服务并不好、冷加载时间长，做些无状态计算还行。 开源的 faas 是不足以 直接拿来用的，大厂都是在开源基础上的魔改
常见几个 serverless 开发 knative 、openfunciton 、kubbeless 、openfaas 可以去了解了解先。 FaaS 基本是基于服务网格之上结合这些 knative 、openfunctions 上的开发 ， |
|
66
salmon5 164 天前
两地三中心、多云多活本来就是老掉牙的架构了。公司有钱就折腾呗。反正这玩意大概率是忽悠，多少年可能用到一次。等用到的时候，当年干活领 KPI 的早跑路了。
|
|
67
salmon5 164 天前
@pkoukk #54
这种大部分是基于商务考虑的，这个云消费一点、那个云消费一点，能有更好的议价权。防止价格上被 1 个云吃定了。 实际多云 K8S 要多云、LB 负载均衡要多云、RDS 要多云、OSS 要多云等等一大堆设施要多云，这个要自己造很多轮子。 更不靠谱。 |
 |
68
Felldeadbird 164 天前
备案怎样解决？嘿嘿。
|
 |
69
txhsj 164 天前
大家考虑跨云多活的时候都不考虑跨云带宽么，带宽太太太太贵，已经成为我司做跨云多活的阻塞点了
|
|
70
txhsj 164 天前
都不考虑成本吗
|
 |
71
OneMan 164 天前 1
不要当国内这些云什么兼容胶水，没有前途。
听着很美好，现实超骨干。换个方向吧。 |
 |
72
opengps 164 天前 1
把云做大都这么难了，你再把多云做好，难上加难，你需要的根本不应该是多云迁移，而是异地多活，这方面有成熟案例可参考，不用自己另外找更费成本的方案
|
 |
73
unco020511 164 天前
绝大部分服务宕机都没啥大事,而且宕机也是小概率事件
|
 |
74
sumarker 164 天前
把数据异地容灾备份做一下，避开业务高峰升级，云服务挂了损失还能稍微小点，如果业务高峰期服务器挂了，那就只能去买彩票了
|
|
75
evilmiracle 164 天前
下云，真正的异地多活才是最靠谱的，自建数据中心，租机柜，运营商签专线做数据一致性，这些东西做下来比多云成本低很多
|
 |
76
sampeng 164 天前
如果只是代码。。
argocd 只需要改一个配置提交。就全过去了。。 那么我就算 100T 数据在 oss 上吧，我就算你光纤聚合。100G 通道。需要 2.8 个小时。。黄花菜都凉了 |
|
77
sampeng 164 天前 1
说句不客气的话。LZ 不要想着发现一个华点就想当然的解决一锤子问题。这不仅仅是技术问题，还要涉及商务，基础数据，全局架构，公司多部门协同，安全，权限划分等等一系列技术/人力/资金等等方面问题。你只看到把代码迁移走。。光 object 数据对于运维团队要做多云融合都是要折腾一段时间的。你就想靠一个程序解决企业级的多云一键迁移？真不是打击你积极性，好高骛远，信息茧房严重。
|
|
78
Jianzs OP |
Select Language