防止云厂商绑定是怎么做的？

[COW]

是不是应该写一个抽象层，IaC 里把各个云厂商 provider 接到抽象层下面，如果 AWS 不想用了，改一下 provider 类型，就随时能切换到其他云？

[yinmin]

只用云服务器，所有服务都在云服务器上自建

[kapr1k0rn]

不要使用云厂商专有的产品

[opengps]

你这个想法，是建立在单机背景下的，单机用途其实本身就不需要什么云。
真正需要用云来发挥价值的都是集群用户，数量大客随时增减，组件多可以减少配置难度，这种客户下云非常困难，甚至为此都会主动去设计多云架构

[renmu]

想得很美好，实际每个云厂商提供的功能千奇百怪

[COW]

@renmu 所以在最小化使用云厂商功能的前提下，做一个抽象层，云厂商切换还是可以实现的吧，剩下的就是服务本身的迁移了

[Ketteiron]

多云架构，抽象与实现有很多种，多活/双活/热备/温备/冷备等。
双活/多活就是多个云上都准备好了服务，方便某个厂商拉跨时迅速撑起流量。
冷备份是以单个云作为主力，出现灾害时通过自动化流程临时去其他云买/租机器然后迁移服务。
热备/温备介于二者之间。
但想法是理想的，现实是。。。
99.999%服务并不会因提高可用性而提高实际可用性，反而引入了更多的复杂度。

[COW]

@Ketteiron 你提到的这个单云主力 + 冷备，出现灾害时通过自动化流程临时去其他云买/租机器然后迁移服务，跟我的想法是一致的。至于跨云多活，我就没想过，感觉是不可能完成的任务。

[Zarc9609]

我觉得企业在决策是不是上多云的主要问题是成本问题

[salmon5]

这个说说很动听，实际绝大部分公司，执行不好
云上的每一个产品，都搞一个抽象层，那开展业务就像带上了脚镣

[wanniwa]

我们公司就是的，我实现的跟你思路是一样的，都抽象出来，可以随时来回切换云厂商流量，我云函数和云主机都是这么实现的，支持云函数动态切流，云主机使用完动态关机……
领导今天要接个京东云明天要接个腾讯云，后天华为云又过来说更便宜，确实会来回换。

[julyclyde]

听起来很 java

[salmon5]

还有多云，说说简单；
就像房子，你会为了某 1 套房子偶尔停水 1 天，搞 2 套房子热备、冷备？那成本是巨大的
你说你有多套房子？那行，你有私人飞机？你会为了偶尔某 1 架私人飞机可能的故障维修，搞 2 架热备、冷备？
你有 2 架私人飞机？那行，你有 2 个地球吗？地球曾经发生过恐龙灭绝？你有能力再备 1 个地球？

[salmon5]

@salmon5 多云 多活、热备、冷备，成本至少增加 50%、甚至 100%，还不算人力成本，故障概率也会增加
很多决策者往往会忽略、无视这些因素

[salmon5]

A 供应商对象存储 10 万 QPS 、100Gbps 带宽、DB 10 万 QPS
抽象层 怎么保证：
B 供应商对象存储 10 万 QPS 、100Gbps 带宽、DB 10 万 QPS ，业务基本上无感知？

[zhengfan2016]

你是否想寻找 docker 和 docker-compose ？

[salmon5]

这个抽象层有点像皮包公司（ 2-3 个员工）（ 2-3 QPS 的业务），随时可以换办公室；
如果是很大的业务量呢？（ 20000-30000 个员工）（ 20000-30000 QPS 的业务），随时可以换办公室？公司停业 30 天？

[salmon5]

所以这个抽象层，终究是个鸡肋，很难通用，小业务玩玩可以

[COW]

@salmon5 我没说搞跨云多活，看我前面的回复，我只是针对 IaC 这一层实现，目的是云厂商之间快速迁移

[salmon5]

@COW 没这么简单，还涉及到有状态的数据同步

[salmon5]

比如 OSS 和 S3 ，如果担心 S3 炸了，但是 S3 又有 N PB ，甚至 EB 级别的数据？怎么快速迁移呢？这部分往往是最难的

[crysislinux]

这样搞就只能用多个厂商 features 的子集了。我是无法接受的。

[gam2046]

理论是这么个理论，但实践很难落实。

一方面云上组件，在不同厂家里提供的能力不完全一致，你的抽象层很难写，理想情况下，抽象层提供一个不同厂家能力的交集，但是一开始你也不知道后续要对接什么厂家，所以你也不知道交集到底有多大。

[salmon5]

@crysislinux #21 是的，肯定没法接受的；原厂至少都是国际大厂，bug 、性能、功能、SLA 上都基本能保证的

[SenLief]

主要是保证数据一致就好吧，迁移的时候无非就是迁移数据

[Alliot]

IaC 能实现低成本的基础设施跨云重建， 但是业务不是简单的基础设施重建就能 OK 。

[sslyxhz]

多云、混合云.. 状态、同步、网络各方面都一堆隐性麻烦，只能说看着很美好，实际成本挺高

个人项目玩玩倒是挺好的

[jsq2627]

过度 vender lock-in 和过度 vender indenpendent 都会提高成本，权衡折中吧

[COW]

@salmon5 如果只考虑最基础的云服务，比如 EC2 这种，能自建的都自建，其他的不做抽象，比如 S3 这种就不会考虑。

[COW]

@wanniwa 所以你们是自建的控制层和状态层吗？云函数挺吸引我的，不知道实际成本高不高

[adgfr32]

数据库，对象存储呢，这种有状态的东西不是说切就切的。
正式环境切换都得找个流量低谷，提前发公告，切完专人盯着。

[adgfr32]

切完指不定哪个犄角旮旯有一个路由没配，dns 有问题，白名单没开，你就排查吧

[ajunno]

事实上各家参数都没有对齐，甚至对于 IaC 产品的设计理念也有差异。2022 年左右做 IaC ，用 terraform ，从 A 云切换到 T 云，可不止是改了个 provider 就可以的，踩了很多坑，也提了不少工单。感受到了理想和现实的差距。

[kenvix]

数据库和对象存储这种有标准协议的很好说，但是 FaaS 这种就难办了，考虑灵活性最好是别用

[COW]

@kenvix 为什么这么说，不是号称无状态的吗，按道理迁移应该更简单才对（虽然我没用过，怕隐形收费）。

[Ketteiron]

@COW #34 不同厂家的 FaaS/Serverless 的 触发器、API 、SDK 、Runtime 都不一样，上多云约等于全部重写多次。函数是无状态的不代表没有平台依赖性。
https://github.com/serverless/serverless/issues/9583

[leeg810312]

没那么多钱的，你想多了，多个云切换就是假命题，2 个全套就 2 倍成本，不说基础设施，就说开发成本，你总得 2 个云上都开发测试过才行，50w 变成 100w ，时间 3 个月变 6 个月，哪个老板能给你这样批项目预算和计划。这个适配层你还得保持维护，各个云任何一个接口更新你都得测试，有什么好处值得这么维护一个庞大的适配层呢？出了云存储这种变化相对少的 SaaS ，我还真没见过几个做跨云的 API 适配。新闻看到过吧，好多公司因为 AWS 或 Azure 云关键性故障就停摆几小时，你多大的项目还要搞成多云切换？大公司都没有想过这样做。

[tabliu]

看体量，单 region 体量年消耗几百万的话完全可以实现多云多活，体量到了一定级别就很难切量了，你想切，其他云未必能接的了。

[dko]

这个你不用操心，当你体量上来了，新厂商会派工程师上门给你评估和迁移的，出了事儿也都是他们赔
经历过线下到腾讯云上云，腾讯云迁移阿里云等等。。

[NewYear]

在这里你很容易得到反对的答案。

但我必须要和你说，早就有人在做这样的尝试了，我印象中有一个开源项目就是干这个的，抹平每个云厂商的差异。

当然前提是你使用云厂商的各种服务，也是要差不多规格的才行，否则逻辑不通。

这个最好你一开始就至少同时用 2 个服务商，这样要迁移都不是问题。

上面大家和你说的都是“风险点”，你只要提前考虑进去就行。



像阿里云之类的，也不是出事一次两次，你真的愿意每次都停下来等他们恢复吗？甚至在有可能丢失数据的情况下。

像很多公司，业务是不准停下来的，停下来公司的运作就出问题了，马上要安排放假，否则就是巨大的经济损失。

[wanniwa]

@COW #29 主要看你们用主机做什么，我们公司是拿主机和云函数执行任务。执行完任务就抛弃，或者没有任务就抛弃，云函数直接省的钱不是一点半点，太便宜了。如果你们公司对主机需求量非常大，且业务场景符合的话，切换到云函数，公司要降本的 kpi 能超额完成非常多。

[wanniwa]

@COW #29 是的我们这边自己会维护主机的状态和开关机相关的控制。我们机器内部也会有心跳上报，也会调用云厂商接口同步实例的状态，多方面保证任务不丢，机器不卡死，能正常分派任务，任务多时自动购买云主机，少时自动关机。你可以理解成一个个云主机终端都由我这边汇总控制。 但是后面我们都往云函数切了，就跟接口一样调用执行任务所以成本降了非常多。云函数每个厂商的接口我也做了适配也是可以来回切流量

[wanniwa]

@COW #29

[AmosAlbert]

感觉这个更强 https://pplx.ai/albert7kin66301