一、引言
「一键部署全球」的 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 告知同意与出境评估——把「数据住哪」作为架构的一等公民,合规就不是事后补课。
继续阅读
探索更多技术文章
浏览归档,发现更多关于系统设计、工具链和工程实践的内容。