English
Nederlands
Deutsch
Français
Español
Português
Italiano
Polski
中文
हिन्दी
仅欧洲替代方案 DigitalOcean.
DigitalOcean 是以开发者为先的美国云服务商，具有竞争力的定价、简洁的用户体验，以及一个阿姆斯特丹区域，这让许多欧盟团队误以为数据驻留问题已经解决。事实并非如此：DigitalOcean LLC 是一家特拉华州公司，其阿姆斯特丹数据中心在美国公司控制下运营，CLOUD Act 依然适用。好消息是，我们为您执行的从 DigitalOcean 迁移到欧盟司法管辖区基础设施的过程，是本指南中最简洁的迁移之一，DigitalOcean 的 API 接口面很小，大多数迁离该平台的工作负载都反映出账单更低，性能相当甚至更好。
- 供应商
- DigitalOcean
- 总部
- New York, NY
- 司法管辖区
- 美国
- 法律制度
- CLOUD Act, FISA 702
"欧盟区域"不等于主权。四个问题决定一切。
数据驻留告诉你数据存放在哪里。主权则告诉你哪个法律体系可以强制访问。这四点的答案必须都成立 - 否则该技术栈就不具备主权性。
- 驻留
-
数据物理存储在哪里?
不只是笼统的“在云端” - 而是具体在哪个数据中心、哪个国家、受哪种司法管辖。
- 次级处理者
-
您的数据路径中还有谁?
每一个接触数据的供应商:CDN、邮件中继、错误追踪、分析管道。
- 司法管辖区
-
哪些法律可以强制披露?
总部位于美国的提供商受 FISA 702 和 CLOUD Act 管辖 - 即使数据存放在法兰克福也不例外。
- 密钥托管
-
谁实际持有加密密钥?
如果云服务商同时持有数据和密钥，无论签订何种 DPA，数据对其而言都是可读的。
在司法管辖权和密钥托管上失败。
欧盟数据、美国母公司、默认路径中的美国次级处理者、供应商管理的密钥。
四项全部通过。
托管在欧盟、由欧盟总部基础设施提供。默认路径中零美国次级处理者。客户持有或欧盟 KMS 密钥。在您的第 28 条 DPA 中按名称列出。
为什么团队正在退出 DigitalOcean
我们经手的 DigitalOcean 迁出案例几乎都源于同一个触发因素：客户审计（B2B SaaS）或合规审查中发现 “DigitalOcean Amsterdam” 在 Schrems II 下不够合规，客户要么必须增加昂贵的补充措施（如 BYOK 加密，但这会削弱托管服务本身的价值），要么选择迁移。迁移通常是更经济的选择。由于 DigitalOcean 的产品线本就设计得十分精简，技术工作量较小，这使得 EU 映射变得简单直接。
DigitalOcean 服务及其仅欧盟等效方案
迁移不是"换一个盒子"。下面的映射是我们为离开以下平台的客户运行的 DigitalOcean 基于 Schrems II 的考量 - 完全适用欧盟司法管辖，数据链路中不涉及美国母公司。
Droplets
- 我们改用什么
- Binadit 托管云平台。基于 Debian 或 Ubuntu 的 KVM 虚拟机，使用 Terraform 供给资源，通过 Ansible 配置。
- 工程说明
- 我们根据您实际的负载情况来确定实例规格，而非套用目录档位，因此大多数迁移最终会使用数量更少、利用率更高的机器。
Spaces (object storage)
- 我们改用什么
- Binadit 托管云平台。MinIO 或 Ceph RGW，兼容 S3。
- 工程说明
- 所有选项均兼容 S3；迁移只需在 SDK 配置中修改一个 endpoint。
Managed Databases (PostgreSQL, MySQL, Redis)
- 我们改用什么
- Binadit 托管云平台。PostgreSQL 或 MySQL 配合 Patroni 实现故障转移，pgBackRest 实现时间点恢复。
- 工程说明
- 流式复制让我们能够以数秒的停机时间完成切换，而无需专门的维护窗口，且恢复流程会按计划定期测试，而不是想当然地假设可行。
App Platform (PaaS)
- 我们改用什么
- Binadit 托管云平台。在 GitLab CI 中构建 Docker 镜像并部署到 Kubernetes，为每个分支提供审查环境。
- 工程说明
- App Platform 在 PaaS 层面没有直接的主权等效方案。Coolify（开源自托管）可以在欧盟基础设施上提供类似 Heroku 的使用体验。
Kubernetes (DOKS)
- 我们改用什么
- Binadit 托管云平台。基于 Debian 或 Talos 的 Kubernetes，使用 Cilium 网络方案，并通过 cert-manager 管理证书。
- 工程说明
- 您的 manifests 和 Helm charts 将原样迁移。发生变化的是 ingress class 和 storage class，这两项由我们负责处理。
Load Balancers
- 我们改用什么
- Binadit 托管云平台。HAProxy 或 Nginx，配合 keepalived 实现故障转移。
- 工程说明
- 对于大多数使用场景，欧盟服务商提供的托管负载均衡器已经足够；如需高级规则配置，则在小型 VM 上部署 HAProxy 是标准方案。
Volumes (block storage)
- 我们改用什么
- Binadit 托管云平台。Ceph RBD，或使用 Longhorn 实现 Kubernetes 原生存储卷。
- 工程说明
- 所有欧盟方案均提供基于 NVMe 的标准块存储；性能相当或更优。
DNS (DigitalOcean DNS)
- 我们改用什么
- Binadit 托管云平台。PowerDNS 或 Knot，权威 DNS，经 DNSSEC 签名。
- 工程说明
- 迁移只需导出并重新导入区域数据；几分钟即可完成。
Floating IPs
- 我们改用什么
- Binadit 托管云平台。静态 IP 分配，配合 keepalived 实现节点间故障转移。
- 工程说明
- 所有提供商都提供等效的故障转移 IP 模式。
CDN (DigitalOcean CDN)
- 我们改用什么
- 我们为您部署并运维欧盟 CDN：Bunny.net 或 KeyCDN，并在源站使用 Nginx 和 Varnish 进行缓存。
- 工程说明
- CDN 是我们少数不自行运行的层级之一。我们会选定 EU 提供商，配置缓存头、清除策略和源站防护，并将其作为托管服务的一部分进行运维。
Monitoring (DO Monitoring)
- 我们改用什么
- Binadit 托管云平台。Prometheus、Grafana、Loki 和 Tempo，通过 OpenTelemetry 串联。
- 工程说明
- OpenTelemetry 让埋点具备可移植性，而且没有按指标或按 trace 计费的问题需要规避设计，因此团队不再需要为了省钱而对所需数据进行采样削减。
Container Registry
- 我们改用什么
- Binadit DevOps & Support。使用 Harbor 或 GitLab container registry，在推送时进行漏洞扫描。
- 工程说明
- Harbor 是生产级的开源 registry；我们为客户运维该服务。
我们如何迁移离开 DigitalOcean
典型的中端市场迁移分为三个阶段进行。以下数据假设工程团队规模为 6-10 人，应用程序技术栈复杂度中等。
-
第 1-3 天
清点与依赖关系
列出每一个 Droplet、Database、Space 以及 App Platform 部署。识别所有需要重写的 DigitalOcean 专有 API 或 doctl 自动化脚本。输出：一份清晰、无意外的迁移计划。
-
第 4-10 天
首先处理软依赖
首先迁移 DNS、Spaces 和 CDN。数据库副本预先部署在 EU managed service 上。容器镜像仓库迁移至 Harbor。监控迁移至 EU Prometheus。
-
第 2-5 周
Compute与数据库切换
Droplets 使用相同镜像在 Binadit 计算资源上重新配置。数据库通过逻辑复制完成切换。App Platform 工作负载迁移到 Binadit 上的 Kubernetes。负载均衡器通过 DNS 切换完成切换。
从DigitalOcean迁出的5年TCO：通常便宜40-60%，最大的节省体现在计算资源上（同等配置价格通常约为一半）以及托管数据库上。DigitalOcean的优势在于其App Platform的用户体验，而欧盟主权技术栈则以Coolify或自托管PaaS作为替代方案。