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

最新推荐文章于 2024-04-29 14:06:23 发布

Jianzs_426

最新推荐文章于 2024-04-29 14:06:23 发布

阅读量54

点赞数

文章标签：阿里云云计算

本文链接：https://blog.csdn.net/jianzs_426/article/details/134388332

版权

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

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

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

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

adapt | 300

这里，代码与云服务提供商的适配有两个方向：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。