构建生产就绪的 Data Marketplace：架构、安全性与经验教训

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the specific sections) you want converted to Simplified Chinese? Once I have the text, I’ll keep the source link at the top unchanged and provide the translation while preserving all formatting and technical terms.

问题空间

• 支付：集成 Stripe，处理 webhook，管理结账会话
• 安全：加密 API 密钥，管理会话，防止攻击
• 并发：在多个买家竞争最后一件商品时防止超卖
• 访问控制：发放令牌，管理权限，处理撤销
• 测试：确保所有功能在生产环境中可靠运行

每个都是一个小型项目。UDAM 解决了所有这些。

架构概览

UDAM遵循经典的三层架构，但针对市场需求进行了特定的设计优化：

┌─────────────┐      ┌──────────────┐      ┌─────────────┐
│   Frontend  │─────▶│   Backend    │─────▶│  PostgreSQL │
│  (Next.js)  │      │  (Node.js)   │      │   Database  │
└─────────────┘      └──────────────┘      └─────────────┐
                            │
                            ▼
                     ┌──────────────┐
                     │    Stripe    │
                     │   Payments   │
                     └──────────────┘

技术栈选择

后端：Node.js + Express

• 快速迭代市场逻辑
• 出色的 Stripe SDK 支持
• 大型生态系统，便于未来扩展

数据库：PostgreSQL

• ACID 事务（对支付至关重要）
• 行级锁（防止竞争条件）
• 成熟、经受生产考验

前端：Next.js

• 支持 SSR，提升 SEO（市场可发现性）
• 故意保持简约——易于定制
• API 优先设计

深入探讨：令牌加密

挑战

卖家提供 API 密钥，买家需要使用这些密钥来访问其服务。这些密钥必须满足以下要求：

• 在静止状态下加密（即使数据库被泄露也不应暴露密钥）
• 合法买家能够解密（他们需要获取真实的密钥）
• 绝不以明文形式记录或缓存

解决方案：AES‑256‑GCM

const crypto = require('crypto');

function encryptToken(apiKey, masterKey) {
  const iv = crypto.randomBytes(16);
  const cipher = crypto.createCipheriv('aes-256-gcm', masterKey, iv);

  let encrypted = cipher.update(apiKey, 'utf8', 'hex');
  encrypted += cipher.final('hex');

  const authTag = cipher.getAuthTag();

  return {
    encrypted,
    iv: iv.toString('hex'),
    authTag: authTag.toString('hex')
  };
}

关键点

• GCM 模式 同时提供加密和认证。
• 随机 IV 确保每次加密使用唯一的初始化向量。
• 认证标签 用于检测篡改行为。
• 主密钥 安全存放在环境变量中（绝不写入代码）。

这种做法意味着，即使有人获取了数据库访问权限，也无法在没有主密钥的情况下解密 API 密钥。

并发控制：超卖问题

场景

解决方案：行级锁

BEGIN;

-- Lock the row for this transaction
SELECT * FROM listings 
WHERE id = $1 
FOR UPDATE;

-- Check availability
IF available_units >= units_requested THEN
  UPDATE listings 
  SET available_units = available_units - $2
  WHERE id = $1;

  INSERT INTO orders (...) VALUES (...);
END IF;

COMMIT;

工作原理

• FOR UPDATE 会锁定选中的行，直到事务完成。
• 其他事务必须等待锁释放。
• 同一时间只能有一个事务递减库存，从而避免超卖。

我们在负载下通过 CI 测试验证了此方案：该测试为 3 件可用库存启动 5 个并发购买尝试——恰好有 3 个订单成功，另外 2 个因“库存不足”而失败。

支付流程：Instant vs. Stripe Checkout

即时令牌发放（小额订单）

对于低于可配置阈值的订单（例如，$5）：

• 创建订单。
• 令牌立即发放。
• 无需付款确认。

为什么？ 对于小额订单，Stripe Checkout 的流程摩擦会比欺诈风险更大地影响转化率。

Stripe Checkout（大额订单）

对于超过阈值的订单：

1. 创建一个 Stripe Checkout 会话。
2. 将用户重定向到 Stripe。
3. Webhook 确认付款。
4. 确认后发放令牌。

实现

if (totalPrice  NOW()',
    [token]
  );

  if (!session.rows[0]) {
    return res.status(401).json({ error: 'Unauthorized' });
  }

  req.userId = session.rows[0].user_id;
  next();
}

测试：CI/CD for Critical Flows

- name: E2E small-limit flow
  run: |
    TOKEN=$(curl -X POST /auth/login ...)
    LISTING_ID=$(curl -X POST /listings ...)
    ORDER=$(curl -X POST /orders ...)
    TOKENS=$(curl /tokens ...)

我们的测试内容

• ✅ 完整购买流程（login → create listing → buy → get tokens）
• ✅ 会话撤销（logout → can’t access protected routes）
• ✅ 并发（5 simultaneous purchases for 3 units）
• ✅ 支付 webhook（in dev mode）

性能考虑

数据库索引

CREATE INDEX idx_listings_status ON listings(status);
CREATE INDEX idx_orders_buyer ON orders(buyer_id);
CREATE INDEX idx_tokens_buyer ON tokens(buyer_id);
-- Additional indexes as needed for query patterns