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

176 天前
 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 就能无缝地在多个云之间进行迁移部署。

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

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

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

9322 次点击
所在节点    推广
80 条回复
goodryb
176 天前
应用可以迁移,甚至可以提前部署,数据怎么办
DefoliationM
176 天前
不用这么麻烦,直接多个云组 k8s ,一个挂了自动切换到其他的上面去
jimages
176 天前
无状态的应用可以迁移,也很方便,那几个 T 的数据呢?
Perry
176 天前
那么在某一家发生异常后,你就能在极短的时间完成业务服务的迁移。

直觉上感觉迁移所需要的时间一般会大于故障修复所需要的时间。
salmon5
176 天前
你这所谓的迁移,只是迁移几个“集装箱”而已,这个难度不大。
实际的云迁移,业务无中断、客户无感知、XXXXPB 数据、XXXX 亿数据,所谓的迁移工具就是玩具
salmon5
176 天前
“那么在某一家发生异常后,你就能在极短的时间完成业务服务的迁移。”
异想天开、痴人说梦
salmon5
176 天前
@salmon5 #5
实际的云迁移,业务无中断、客户无感知、XXXXPB 数据、XXXX 亿数据,所谓的迁移工具就是玩具
===============================================================
还有成千上万条的屎山业务配置中心配置文件(硬编码的、无效的等等)
hongfs
176 天前
@salmon5 #6 那应该是 多云 来共同提供服务了,不管方案怎么样,数据的同步都是一个问题。
hallDrawnel
176 天前
实现厂商容灾的方案是一开始就将业务多活到多个云服务厂商上。

因为硬盘会坏,提高安全性的方法不是搞一个快速拷贝工具。
mooyo
176 天前
资源能迁,数据呢?
gamexg
176 天前
>可以包含多个路由,以及 KV 数据库、消息队列等 BaaS 组件

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

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

我觉得只能考虑跨多云的多活集群了.
不过还真没实际测试过跨机房的数据库,不知道那几个称可以跨机房的数据库方案靠谱不.
Jianzs
176 天前
@DefoliationM 的确是一种解决方案,但是成本可能更高一点
yinmin
176 天前
能切换到“仅使用 Aliyun 的云服务器 ECS”的模式,不依赖 aliyun 的其他服务,可靠性提升一个数量级。
mightybruce
176 天前
一看是 typescript ,好了,可以关掉了。
joyanhui
176 天前
云厂商故障,DDOS,还有域名被莫名其妙暂停解析...

目前我们:

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

如果是 app 、物联网之类非 web 项目,单独做一个服务器查询接口反馈给客户端可用的后端地址,多地区多域名多 dns 多厂商部署。
Jianzs
176 天前
@mightybruce 能说说为啥不?采用 TypeScript 的主要原因是目前 Nodejs 的 FaaS 比较成熟
Jianzs
176 天前
@joyanhui 牛,Pluto 可能更希望面向中小企业或者个人开发者这个群体吧,的确有一定体量的企业估计也都在做这方面的准备
atonganan
176 天前
别倦了,再卷这行业就干不下去了
mightybruce
176 天前
首先请先了解一下平台工程 和 gitops 先, 云原生这块众多工具都是 golang 为主, 并且方便对接 kubernetes 。
我就不说各种迁移还有自动化 CICD 的开发了。
你这个是前端的玩具吧。
Jianzs
176 天前
@atonganan Pluto 是解放开发者呀 😉 不用自己去创建部署各种数据库啥的,写个代码一切就都完事了。开发自己玩具的话,利用 FaaS 还可以降低成本

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/991920

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX