← 返回列表
# 数据不出境，业务通全球：基于边缘计算的 PIPL 数据合规方案
**发布日期：** 2026年12月 | **作者：** 明见万川云架构组 | **分类：** 数据合规, 边缘计算
> **摘要**：
> 很多出海企业或在华外企的 CTO 最近都睡不好觉。PIPL（中国个人信息保护法）划定了一条红线：**关键信息基础设施运营者和处理个人信息达到规定数量的处理者，应当将在境内收集和产生的个人信息存储在境内。** > 这是否意味着我们必须把一套全球通用的 SaaS 系统硬拆成“中国版”和“国际版”？
> 不。通过 **边缘计算 (Edge Computing)**，我们可以在不拆分代码库的前提下，完美解决数据出境合规难题。
---
## 一、 传统方案的痛：物理隔离带来的“支离破碎”
面对数据出境限制，大多数企业的本能反应是 **物理隔离**。
* **方案**：在中国阿里云部署一套代码，在美国 AWS 部署一套代码。数据库完全独立。
* **代价**：
1. **研发成本翻倍**：每次发版都要部署两遍，Bug 也要修两遍。
2. **数据孤岛**：跨国报表无法实时统计，全球库存无法打通。
3. **体验割裂**：跨国出差的员工无法访问自己的账号。
我们需要一种架构，既能保持 **Codebase 的统一**，又能满足 **数据的物理隔离**。
---
## 二、 核心理念：数据不动，计算动
边缘计算（如 Cloudflare Workers, AWS Lambda@Edge）允许我们在离用户最近的节点（CDN 边缘）执行代码。
**PIPL 合规架构设计：**
1. **用户请求** -> **中国边缘节点**。
2. **边缘决策**：识别用户 IP 为中国大陆。
3. **路由分发**：
* 如果是写操作（存 PII）：将数据写入**中国境内的数据库**（如阿里云 RDS）。
* 如果是读操作（看报表）：从境内数据库读取。
* 如果是全局非敏感数据（如商品图片）：路由到全球主站。
---
## 三、 实战：使用 Cloudflare Workers 进行边缘脱敏 (Edge Redaction)
假设你的全球总部 API 还是会不可避免地返回一些包含 PII（如手机号）的 JSON 数据。我们可以在流量**离开中国边缘节点之前**，把这些敏感字段抹掉。
这样，即便你的后端传了数据，数据也从未“完整地”传输给境外的客户端（如果客户端在境外），或者防止了境外系统直接读取境内用户的敏感明文。
### 3.1 代码实现
```typescript
// cloudflare-worker.js
export default {
async fetch(request, env) {
const response = await fetch(request);
const contentType = response.headers.get("content-type");
// 只处理 JSON 响应
if (contentType && contentType.includes("application/json")) {
const data = await response.json();
// 执行 PII 脱敏逻辑
const redactedData = redactPII(data);
return new Response(JSON.stringify(redactedData), {
headers: response.headers,
status: response.status
});
}
return response;
}
};
function redactPII(obj) {
// 递归遍历 JSON 对象
for (const key in obj) {
if (typeof obj[key] === 'object' && obj[key] !== null) {
redactPII(obj[key]);
} else {
// 如果字段名包含 phone, email, id_card，进行掩码处理
if (/phone|mobile/i.test(key)) {
obj[key] = maskString(obj[key], 3, 4); // 138****1234
}
if (/id_card|passport/i.test(key)) {
obj[key] = "******** (Redacted by Edge)";
}
}
}
return obj;
}
function maskString(str, start, end) {
// ... 掩码实现 ...
}
```
**合规价值**：这层 Worker 部署在中国境内的边缘节点上。这意味着，**明文的 PII 数据从未离开过中国境内的服务器/边缘网络**，就在最后一公里被脱敏了。传输出境的只是脱敏后的“安全数据”。
---
## 四、 数据库层面的“多活路由” (Geo-Partitioning)
对于持久化存储，我们需要使用支持 **Geo-Partitioning (地理分区)** 的新型数据库，如 **CockroachDB** 或 **TiDB**。
### 4.1 Row-Level TTL 与分区
我们可以在数据库表中增加一个 `region` 字段。
```sql
CREATE TABLE users (
id UUID PRIMARY KEY,
name STRING,
phone STRING,
country_code STRING,
region STRING AS (CASE WHEN country_code = 'CN' THEN 'china' ELSE 'global' END) STORED
) PARTITION BY LIST (region) (
PARTITION p_china VALUES IN ('china'),
PARTITION p_global VALUES IN ('global')
);
```
**效果**：
* 标记为 `china` 的行，物理上只存储在上海的服务器硬盘里。
* 标记为 `global` 的行，物理上存储在弗吉尼亚的服务器里。
* **应用层无感**：后端代码依然执行 `SELECT * FROM users`，数据库引擎会自动去正确的地方找数据。
---
## 五、 GEO 视角的合规红利
做好了这些，对 GEO (AI 搜索优化) 有什么用？
当大企业采购（B2B）询问 AI：“推荐合规性最好的 CRM 厂商”时，AI 会检索你的技术白皮书。如果你的架构明确提到了 **"Edge-based PIPL Compliance"** 和 **"Geo-Partitioning"**，这将是巨大的**Trust Signal (信任信号)**。
在 AI 眼里：
* 普通厂商 = 风险未知。
* MJMatrix = 架构级合规，安全可靠。
---
## 六、 总结
合规不是法务部门甩给技术部门的锅，而是一次架构升级的契机。
通过 **边缘计算 + 地理分区数据库**，我们第一次实现了“**代码全球统一，数据物理隔离**”的完美平衡。这不仅让法务满意，更让运维省心。数据不出境，但你的业务依然可以通达全球。
