全球部署与合规:多区域、数据主权与 GDPR 落地

系统讲解全球部署与合规实践:多区域架构(就近路由/数据驻留)、CDN 与边缘网络的全球策略、数据主权与本地化要求(GDPR/PIPL 等)、跨境数据传输合规、合规审计与数据最小化、中国区部署的特殊性(备案/合规),以及全球合规部署的落地清单。

一、引言

「一键部署全球」的 Serverless/CDN 让「全球访问」变得简单,但「全球合规」并不简单:欧盟 GDPR、中国 PIPL/个保法、美国各州隐私法、巴西 LGPD 各自规定了数据在哪存、能不能传、怎么保护。数据驻留(Data Residency)、跨境传输、用户权利(删除/导出)都是必须落地的问题。

本文系统讲全球部署与合规:先讲多区域架构(就近路由 + 数据驻留),再讲 CDN 与边缘的全球策略、数据主权与本地化要求、跨境数据传输合规、合规审计与数据最小化,最后重点讲中国区部署的特殊性(备案)与一份全球合规落地清单。

关联:https://plumephp.com/tools-edge-cache-cdn-strategy/(边缘缓存)、https://plumephp.com/tools-edge-auth-sessions/(会话与数据)、https://plumephp.com/tools-serverless-database-selection/(数据层驻留)、https://plumephp.com/cloudflare-china-cdn/(中国区加速)。


二、多区域架构:就近路由 + 数据驻留

2.1 全球应用的多区域设计

计算层:Serverless/边缘 → 天然全球就近(Vercel/Cloudflare 全球 PoP)
数据层:数据驻留(存到特定区域)→ 需要「区域化数据库」
关键:计算可全球,数据要驻留 → 「就近计算 + 本区域数据」
架构层全球策略说明
静态/CDN全球缓存边缘缓存到 PoP
计算(函数)全球就近执行请求到最近 PoP
会话/KV按用户区域就近 KV
数据库区域驻留主库放指定区域
文件存储区域驻留R2/S3 区域桶

2.2 多区域路由

按用户地域路由到对应区域:
  DNS Geo 路由 / 边缘函数按 IP 区域判断 → 请求到就近或合规区域
// 边缘按区域路由
export default {
  async fetch(req: Request) {
    const country = req.headers.get('cf-ipcountry') || 'US'
    if (country === 'CN') return routeTo('cn-region', req)
    if (country === 'DE') return routeTo('eu-region', req)   // GDPR 驻留
    return routeTo('global', req)
  }
}

2.3 区域故障与冗余

多区域 ≠ 简单复制:要定义「主区域 + 灾备区域」
跨区域复制注意:数据是否允许跨区备份(合规约束)

一句话总结:多区域架构 = 计算全球就近 + 数据按区域驻留——路由按用户地域走,合规数据留在指定区域。


三、CDN 与边缘的全球策略

3.1 CDN 的全球覆盖

CDN 边缘缓存静态资源到全球 PoP → 就近访问、降低源站负载
Cloudflare:300+ PoP;Vercel Edge Network:全球边缘
静态资源(HTML/JS/图片)→ 全部进边缘缓存

3.2 边缘缓存的合规注意

1. 页面可能含用户数据 → 不能盲目全缓存
2. 区域化缓存:特定区域缓存特定内容
3. 缓存隐私:带认证的内容不要进共享 CDN
4. Cookie/用户态页面 → 不缓存 或 按用户分段
// 边缘:认证页面不缓存
export async function middleware(request: Request) {
  const response = NextResponse.next()
  if (request.cookies.get('session')) {
    response.headers.set('Cache-Control', 'private, no-store')
  }
  return response
}

3.3 边缘合规能力

Cloudflare Data Localization Suite:
  请求只在指定区域处理(数据不离开区域)
  是「边缘层」满足数据驻留的手段

一句话总结:CDN 全球缓存提升性能,但「含用户数据的页面要 private/区域化」——边缘层也能用 Data Localization 约束数据不出区域。


四、数据主权与本地化要求

4.1 各国数据驻留要求

地区主要法律驻留要求
欧盟GDPR数据出境需充分性认定/标准条款
中国PIPL/个保法重要数据境内存储
俄罗斯个人数据法俄公民数据必须存俄境内
巴西LGPD跨境需合同/认定
美国各州隐私法(CCPA 等)州级要求不一

4.2 数据驻留的工程落地

1. 数据分类:明确哪些数据受「驻留约束」
2. 区域数据库:EU 数据存 EU 库(如 Supabase 欧洲区)
3. 路由绑定:按用户区域把请求路由到对应区域数据
4. 备份约束:跨境备份需合规评估
# 示例:Supabase 欧洲区域
# 创建项目时选 EU Central (Frankfurt) → 数据驻留欧盟
supabase projects create --org <org> --db-pass <pw> --region eu-central-1

4.3 用户请求的「区域亲和」

欧盟用户 → 数据入欧盟库(GDPR 驻留)
中国用户 → 数据入境内(PIPL 境内存储)
其他     → 就近默认区域
实现:边缘按 cf-ipcountry 决定「读写哪个区域的数据」

一句话总结:数据主权 = 分类 + 区域库 + 路由绑定——按用户区域读写对应区域数据,备份与跨境传输都要过合规评估。


五、跨境数据传输合规

5.1 三种合规路径(GDPR 视角)

1. 充分性认定:目标国有「充分保护水平」认定(如欧盟→日本)
2. 标准合同条款(SCC):双方签署欧盟标准条款
3. 例外情形:用户明确同意/必要履行合同

中国 PIPL 视角:
  重要数据出境 → 安全评估/认证/标准合同
  个人数据出境 → 告知 + 单独同意 + 必要最小

5.2 工程上的「最小化跨境」

1. 数据本地化:能存本地就不跨境(区域库 + 区域路由)
2. 数据脱敏后出境:分析用假名化/聚合数据
3. 权限最小化:跨境接口只传必要字段
4. 加密传输 + 访问日志

5.3 审计与留痕

跨境传输要能证明「基于什么依据」
保留:同意记录、SCC 签署、评估报告、日志

一句话总结:跨境合规靠「充分性认定/SCC/同意」三条路径,工程上优先「数据本地化 + 脱敏后出境」——每次跨境都要有依据、有留痕。


六、合规审计与数据最小化

6.1 数据最小化原则

只收集/存储「业务必需」的数据:
  不该存的不存(完整 IP、精确位置可能非必需)
  能聚合的聚合(分析用聚合指标,不用明细 PII)
  设保留期(TTL/自动删除)

6.2 用户权利落地(GDPR 的 DSAR)

用户权利:访问、更正、删除、导出、撤回同意
工程落地:
  1. 删除:找到该用户所有数据 → 级联删除(或脱敏)
  2. 导出:聚合用户数据 → 标准格式交付
  3. 撤回同意:撤销处理依据
// 用户删除请求处理(示意)
async function handleDeleteRequest(userId: string) {
  await db.transaction(async (tx) => {
    await tx.delete('orders').where({ userId })
    await tx.delete('profiles').where({ userId })
    // 日志/审计数据:脱敏而非真删
    await tx.update('audit_log').where({ userId }).set({ userId: 'redacted' })
  })
}

6.3 合规审计要点

1. 数据地图:什么数据存在哪(区域/系统/保留期)
2. 处理记录(RoPA):处理目的、依据、流向
3. 定期评估:DPIA(数据保护影响评估)
4. 泄露响应:72 小时报告(GDPR)、及时通知(PIPL)

一句话总结:合规落地 = 数据最小化(少存)+ 用户权利可执行(删除/导出)+ 审计留痕(数据地图/处理记录/泄露响应)。


七、中国区部署的特殊性

7.1 ICP 备案

中国大陆服务器/域名解析 → 必须 ICP 备案
关键点:
  1. 服务器在中国大陆(阿里云/腾讯云等)→ 必须备案
  2. 纯境外托管(Cloudflare 免费版无中国大陆节点)→ 不强制但访问慢
  3. 备案主体与网站一致,约 1-3 周

7.2 中国区加速的合规路径

方案一:境内服务器 + 备案(阿里云/腾讯云 + 境内 CDN)→ 合规且快
方案二:境外托管 + 中国大陆 CDN(需已备案域名)→ 边缘接入
方案三:Cloudflare 中国网络(与京东云合作,需企业/备案)

7.3 PIPL 在中国的特别要求

1. 重要数据境内存储(法律规定场景)
2. 个人信息处理要「告知-同意」
3. 敏感个人信息(生物识别/位置等)单独同意
4. 向境外提供个人信息 → 单独同意 + 安全评估/标准合同
5. 个人信息保护负责人/合规审计

一句话总结:中国区 = ICP 备案(境内服务必办)+ PIPL 合规(告知-同意、重要数据境内存储、出境评估);加速方案要在「备案 + 境内 CDN」与「境外+边缘」间权衡合规与性能。


八、全球合规部署落地清单

  • 数据分类:哪些是 PII、哪些受驻留约束
  • 区域数据库:EU 库、中国库、默认库(按区域创建)
  • 边缘路由:按用户区域路由到对应区域(cf-ipcountry)
  • 静态/隐私页面缓存策略(private/no-store)
  • 跨境传输有依据(SCC/同意/认定)并有留痕
  • 数据最小化 + 保留期(TTL/自动删除)
  • 用户权利接口(访问/删除/导出)
  • 泄露响应流程(报告时限 + 通知机制)
  • 中国区:ICP 备案状态确认
  • 定期 DPIA / 数据地图更新

九、全球合规架构图

用户(EU/CN/US)
  ↓ 边缘路由(cf-ipcountry)
EU 用户 → 欧盟区域函数 + 欧盟数据库(GDPR 驻留)
CN 用户 → 中国区域服务(备案)+ 境内存储(PIPL)
US 用户 → 默认全球区域
  ↓
缓存:静态全球缓存;隐私页面 private/no-store
文件:R2/S3 按区域桶
分析:脱敏/聚合后入数仓(最小化)
合规:数据地图 + 处理记录 + 泄露响应 + 定期审计

十、速查表

需求方案
全球性能CDN/边缘全球缓存
数据驻留区域数据库 + 区域路由
GDPR 跨境充分性认定 / SCC / 同意
数据最小化只存必需 + TTL + 聚合
用户删除级联删除 + 日志脱敏
用户导出聚合 + 标准格式
隐私缓存private/no-store
中国区ICP 备案 + 境内存储
PIPL 出境单独同意 + 安全评估
审计数据地图 + 处理记录 + 泄露响应

一句话记忆:全球部署 ≠ 全球合规——数据主权要求「分类 + 区域库 + 区域路由」,EU 存欧盟、中国存境内;CDN 全球缓存但隐私页面 private;跨境靠认定/SCC/同意且有留痕;数据最小化 + 用户权利(删除/导出)可执行;中国区核心是 ICP 备案 + PIPL 告知同意与出境评估——把「数据住哪」作为架构的一等公民,合规就不是事后补课。

继续阅读

探索更多技术文章

浏览归档,发现更多关于系统设计、工具链和工程实践的内容。

全部文章 返回首页

「tools」更多文章

  1. 部署与回滚策略:蓝绿、金丝雀与不可变部署实战
  2. 边缘认证与会话管理:JWT、Cookie 与 Serverless 登录实战
  3. 可观测性与错误追踪:日志、Trace 与告警闭环