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

2023-11-14 20:03:40 +08:00
 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 。

11397 次点击
所在节点    推广
80 条回复
evilmiracle
2023-11-15 13:00:50 +08:00
我知道肯定有老哥说成本问题,我的意思是,没钱,没钱你玩什么云,我们都是开劳斯莱斯,都是奔驰,你没钱,没钱你自建机房吧,买个 nas 当服务器就行

@salmon5
salmon5
2023-11-15 13:01:44 +08:00
@pkoukk #54 这种不是多云多活。伪多云。OSS/COS 数据要 2 份、DB 热数据要 2 份,还有数据同步的专线费。成本增加 30-40%左右。
fly2never
2023-11-15 13:02:08 +08:00
多云管理 CMP
salmon5
2023-11-15 13:09:18 +08:00
@evilmiracle 劳斯莱斯?我还湾流 G700 。
几台服务器可以随便折腾。正常的公司都要考虑成本问题。
mightybruce
2023-11-15 13:10:00 +08:00
FaaS 本身有很多缺陷,已经不是云计算的主要兴趣所在。一般来说 faas 和 baas 一起使用。faas 是不通用的,每个云厂商必须要做相当多的基础设施开发兼容自身的下层设施才能让 faas 可用,另外 faas 抽象层次更高, 虽然方便,但是对于资源管理和服务控制反而更差,其次 faas 有状态服务并不好、冷加载时间长,做些无状态计算还行。 开源的 faas 是不足以 直接拿来用的,大厂都是在开源基础上的魔改
常见几个 serverless 开发 knative 、openfunciton 、kubbeless 、openfaas 可以去了解了解先。
FaaS 基本是基于服务网格之上结合这些 knative 、openfunctions 上的开发 ,
salmon5
2023-11-15 13:11:45 +08:00
两地三中心、多云多活本来就是老掉牙的架构了。公司有钱就折腾呗。反正这玩意大概率是忽悠,多少年可能用到一次。等用到的时候,当年干活领 KPI 的早跑路了。
salmon5
2023-11-15 13:52:10 +08:00
@pkoukk #54
这种大部分是基于商务考虑的,这个云消费一点、那个云消费一点,能有更好的议价权。防止价格上被 1 个云吃定了。
实际多云 K8S 要多云、LB 负载均衡要多云、RDS 要多云、OSS 要多云等等一大堆设施要多云,这个要自己造很多轮子。
更不靠谱。
Felldeadbird
2023-11-15 14:18:20 +08:00
备案怎样解决?嘿嘿。
txhsj
2023-11-15 14:59:47 +08:00
大家考虑跨云多活的时候都不考虑跨云带宽么,带宽太太太太贵,已经成为我司做跨云多活的阻塞点了
txhsj
2023-11-15 15:00:07 +08:00
都不考虑成本吗
OneMan
2023-11-15 16:28:25 +08:00
不要当国内这些云什么兼容胶水,没有前途。
听着很美好,现实超骨干。换个方向吧。
opengps
2023-11-15 16:30:03 +08:00
把云做大都这么难了,你再把多云做好,难上加难,你需要的根本不应该是多云迁移,而是异地多活,这方面有成熟案例可参考,不用自己另外找更费成本的方案
unco020511
2023-11-15 16:35:40 +08:00
绝大部分服务宕机都没啥大事,而且宕机也是小概率事件
sumarker
2023-11-15 16:43:15 +08:00
把数据异地容灾备份做一下,避开业务高峰升级,云服务挂了损失还能稍微小点,如果业务高峰期服务器挂了,那就只能去买彩票了
evilmiracle
2023-11-15 19:05:35 +08:00
下云,真正的异地多活才是最靠谱的,自建数据中心,租机柜,运营商签专线做数据一致性,这些东西做下来比多云成本低很多
sampeng
2023-11-15 19:52:11 +08:00
如果只是代码。。
argocd 只需要改一个配置提交。就全过去了。。
那么我就算 100T 数据在 oss 上吧,我就算你光纤聚合。100G 通道。需要 2.8 个小时。。黄花菜都凉了
sampeng
2023-11-15 19:58:44 +08:00
说句不客气的话。LZ 不要想着发现一个华点就想当然的解决一锤子问题。这不仅仅是技术问题,还要涉及商务,基础数据,全局架构,公司多部门协同,安全,权限划分等等一系列技术/人力/资金等等方面问题。你只看到把代码迁移走。。光 object 数据对于运维团队要做多云融合都是要折腾一段时间的。你就想靠一个程序解决企业级的多云一键迁移?真不是打击你积极性,好高骛远,信息茧房严重。
Jianzs
2023-11-16 00:12:04 +08:00
@OneMan
@sampeng #77
@opengps

感谢 V 友,会继续明确目标群体,说清楚解决的问题。目前想的是,不想做个大事,只是想降低一点云的使用门槛,让没有云背景的开发者也能用上云。
opengps
2023-11-16 10:37:50 +08:00
@Jianzs 不如换个思维,云的概念过于先进,实际对于个人用户的使用场景,是配置更低的虚拟机而已。优势是更廉价,云虚拟机,稳定性比 vps 好点,价格比 vps 低点,网络质量直接上升为 bgp 而不是多线,后台支持功能多了点,直接体会仅此而已
joyanhui
2023-11-17 05:19:12 +08:00
@Jianzs
一部分在云服务器里面 这部分不需要专门适配。
一部分用各家的函数计算 华为 阿里 腾讯 aws 都支持自定义运行时,不需要专门适配 只有少数业务需要微调。

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

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

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

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

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

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

© 2021 V2EX