Google Pay支付钱包系统设计

基于微服务的支付钱包架构设计：

专栏重点仅限于理解这些不同系统架构的架构、数据和控制流，欢迎加我好友一起交流学习。

1 聚焦架构：基于微服务的架构

基于微服务的架构具有模块性、可扩展性和灵活性，非常适合设计像 Google Pay 这样的支付钱包。

对于支付钱包系统，微服务架构可无缝处理大量交易、与第三方系统集成并持续部署更新。

2 支付钱包的主要功能

像 Google Pay 这样的支付钱包通常支持

• 用户引导：用户注册、KYC 验证和账户设置。
• 余额管理：钱包资金、余额检查和退款。
• 交易：点对点 (P2P) 转账、商户支付和拆单支付。
• 与支付网关集成：与银行、UPI 和银行卡网络连接。
• 安全性：加密、身份验证（如 OTP、生物识别）和欺诈检测。
• 通知：实时更新交易和促销信息。

3 支付钱包的微服务设计/架构

该系统的主要服务项目：

3.1 用户服务

处理用户注册、认证和管理，负责：

• 创建和更新用户配置文件
• 通过第三方API进行 KYC 验证
• 管理关联的银行账户和银行卡

3.2 钱包服务

管理钱包余额和操作，负责：

• 维护用户钱包余额
• 通过链接的银行账户或银行卡入金
• 在交易过程中扣除余额

3.3 交易服务

处理 P2P 和商家支付，负责：

• 交易启动和验证。
• 确保幂等性，避免重复支付
• 与第三方网关（如 UPI、信用卡处理器）交互

3.4 支付网关服务

与外部支付系统的摘要集成，负责：

• 与 UPI、银行卡网络和银行对接
• 确保安全和遵守法规
• 处理支付失败的重试和回退

3.5 通知服务

向用户提供实时更新，负责：

• 通过短信、电子邮件或推送发送通知
• 确保事件驱动更新（如交易确认）

3.6 欺诈检测服务

监测和防止恶意活动，负责：

• 分析交易模式以发现异常
• 标记可疑交易，进行人工审查
• 与 AI/ML 系统集成，实现实时欺诈检测

3.7 分析服务

为业务和运营提供洞见，负责：

• 跟踪用户活动和交易趋势
• 提供运行监控仪表板
• 支持个性化促销和优惠活动

3.8 日志和监控服务

确保系统可靠性和调试，负责：

• 跨微服务聚合日志。
• 监控系统健康状况并告警
• 故障发生时支持根因分析

3.8 基础设施服务

这些服务处理事件驱动的通信、与外部系统的集成或运行方面的问题：

• Kafka Broker：充当服务间异步通信的主干，实现事件驱动的工作流
• 银行/卡网络：用于支付结算和资金处理的外部服务。
• 管理面板（监控和管理）：为管理员提供操作见解，包括系统健康状况、日志和欺诈警报。

4 总体架构

可根据服务在架构中扮演的角色将其分类：

i. 用户侧： API网关、用户服务、通知服务

ii. 中间层： 钱包服务、交易服务、支付网关服务

iii. 支撑服务： KYC 服务、欺诈检测服务、分析服务、日志服务

iv. 基础设施层： Kafka 消息队列、银行/卡网络、管理后台

支付钱包架构：

5 工作流程

5.1 用户引导

• 从前端到后端
• 前端向 API 网关发送 POST /users/register 请求
• API 网关会将请求转发给用户服务

用户服务到 KYC 服务

• 用户服务向 KYC 服务发送 POST /kyc/verify 请求，以验证用户身份
• KYC 服务处理申请并在其数据库中更新状态

事件发布

用户注册成功后，用户服务会向 Kafka 发布 user.created 事件。

事件消费

• 通知服务监听 user.created，并向用户发送欢迎信息
• 分析服务监听 user.created，并记录事件以便报告

以上汇总的交互显示了该工作流程中跨服务映射的 API 和 Kafka 事件，清楚地说明了数据和控制是如何在系统中流动的。

用户引导工作流程图：

API 交互

Kafka事件

DB设计

数据库：关系数据库（如 PostgreSQL、MySQL） 目的：存储用户配置、KYC 数据和偏好。

为何选择：具有定义关系的结构化数据、关键用户数据的 ACID 合规性、用于 KYC 验证的强大一致性。

// Stores basic user information.
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    phone VARCHAR(15) UNIQUE,
    password_hash VARCHAR(255) NOT NULL,
    is_verified BOOLEAN DEFAULT FALSE
);

// Stores notification preferences.
CREATE TABLE user_preferences (
    user_id INT NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    email_pref BOOLEAN DEFAULT TRUE,
    sms_pref BOOLEAN DEFAULT TRUE,
    push_pref BOOLEAN DEFAULT TRUE,
    PRIMARY KEY (user_id)
);

// Tracks KYC verification status.
CREATE TABLE kyc_details (
    user_id INT NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    kyc_status VARCHAR(50) NOT NULL,
    kyc_document_type VARCHAR(50) NOT NULL,
    kyc_document_url TEXT,
    PRIMARY KEY (user_id)
);

5.2 将资金添加到钱包

前端到后端：

• 前端向 API 网关发送 POST /wallet/add-funds 请求
• API 网关会将请求转发给钱包服务

钱包服务到支付网关

• 钱包服务向支付网关发送 POST /payment/initiate 请求，启动资金转账流程
• 处理支付后，支付网关会向钱包服务发送一个 POST /payment/status 回调，其中包含支付结果

钱包更新

如果支付成功，钱包服务会更新数据库中用户的钱包余额，并触发下一步操作。

事件发布

钱包服务向 Kafka 发布 wallet.fund_added 事件。

事件消费

• 通知服务监听 wallet.fund_added，并向用户发送确认通知
• 分析服务会记录交易详情，以便报告
• 欺诈检测服务监控事件的可疑模式

以上摘要概括了向钱包添加资金的工作流，如何以清晰和面向服务的方式协调 API 和 Kafka 事件之间的交互。

将资金添加到钱包工作流程：

API 交互

Kafka事件

DB 设计

数据库：NoSQL 数据库（如 DynamoDB、MongoDB）

目的：管理钱包余额和添加资金的交易日志。

为何选择该数据库？钱包更新的高吞吐量、资金交易的快速写入和模式灵活性。

wallets : Collection Tracks user wallet balance.

{
  "user_id": "string",
  "balance": "decimal",
  "last_updated": "ISODate"
}

fund_transactions : Collection Logs fund addition transactions.

{
  "transaction_id": "string",
  "user_id": "string",
  "amount": "decimal",
  "status": "string",
  "timestamp": "ISODate"
}

5.3 P2P支付

• 前端到交易服务：前端向交易服务发送 POST /p2p-payment 请求，其中包含发送方和接收方的详细信息以及支付金额
• 交易服务到钱包服务（发送方钱包）
• 交易服务发出 POST /wallet/lock-funds 请求，为交易锁定发送方钱包中的资金
• 钱包服务会核实发件人的余额并锁定指定金额

交易服务到钱包服务（接收方钱包）

• 成功锁定发送方资金后，交易服务会发送 POST /wallet/add-funds 请求，将金额记入接收方钱包
• 钱包服务更新接收方的钱包余额

事件发布

付款成功完成后，交易服务会向 Kafka 主题发布 transaction.completed 事件。

事件消费

• 通知服务会消耗 transaction.completed 事件，并向发送方和接收方发送通知
• 分析服务记录交易详情，用于报告和分析
• 欺诈检测服务监控交易是否有可疑活动。
• 日志服务会将事务记录在持久日志中，以便审计

以上总结以清晰和以服务为导向的方式概括了 P2P 支付的端到端工作流程。

p2p支付工作流程：

API 交互：

Kafka 事件：

DB 设计

数据库：关系数据库 + NoSQL（用于交易日志）

目的：记录 P2P 支付详情并更新钱包余额。

为何选择该数据库？低延迟更新多个钱包，无模式设计，交易灵活。

wallets collection: Shared with Add Funds workflow

p2p_transactions collection: Logs sender and receiver details for P2P payments.

{
  "transaction_id": "string",
  "sender_id": "string",
  "receiver_id": "string",
  "amount": "decimal",
  "status": "string",
  "timestamp": "ISODate"
}

5.4 退款

前端到交易服务：前台向交易服务发送 POST /refund 请求，并提供要退款的交易详情

从交易服务到钱包服务：

• 交易服务会核实退款政策和原始交易详情。
• 验证后，它会向钱包服务发送 POST /wallet/add-funds 请求，将金额退还到用户钱包。
• 钱包服务会相应更新用户的钱包余额

事件发布

退款成功完成后，事务服务会向 Kafka 主题发布 transaction.refunded 事件。

事件消费

• 通知服务使用 transaction.refunded 事件通知用户退款状态
• 分析服务会记录退款详情，以便报告和跟踪
• 日志服务记录退款交易，用于审计和故障排除

以上摘要简明扼要地介绍了 Refund 工作流在服务、应用程序接口和事件之间的交互。

退款工作流程：

API交互

Kafka事件

DB Design:

DB 设计：

*Database**: Relational Database Purpose: To track refunds and update wallet balances. Why chosen: Strong consistency required for refunds, Relational dependencies on original transactions.*

数据库：关系数据库 目的：跟踪退款和更新钱包余额。 为什么选择该数据库？退款需要较强的一致性，与原始交易的关系依赖性。

- refunds table: Logs refund details with references to transactions.

CREATE TABLE refunds (
    refund_id SERIAL PRIMARY KEY,
    transaction_id INT NOT NULL,
    user_id INT NOT NULL,
    amount DECIMAL(10, 2) NOT NULL,
    status VARCHAR(50) NOT NULL,
    timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
);

5.5 商户支付工作流程（Merchant Payment）

1. 前端到交易服务：前端向交易服务发送 POST /merchant-payment 请求，其中包含用户、商家和支付金额的详细信息。
2. 交易服务到钱包服务（用户钱包）：交易服务验证用户钱包余额，并向钱包服务发送 POST /wallet/lock-funds 请求，以锁定所需金额。
3. 交易服务到支付网关：交易服务使用 POST /payment/settle 请求与支付网关交互，以处理支付和结算资金。
4. 交易服务到钱包服务（商家钱包）：结算成功后，交易服务向钱包服务发送 POST /wallet/add-funds 请求，将金额记入商家钱包。

事件发布

完成支付流程后，交易服务会向 Kafka 发布 transaction.merchant_payment 事件。

事件消费

• 通知服务会监听 transaction.merchant_payment 事件，以便向用户和商家通知交易情况。
• 分析服务记录商户交易，以便进行报告和分析。
• 日志服务记录交易详情，以便审计。
• 欺诈检测服务监控事件中的可疑活动。

以上明细清楚地概述了各项服务如何通过 API 调用和 Kafka 事件为商家支付工作流提供协作：

API交互

Kafka事件

DB 设计

数据库：NoSQL 数据库（用于实时更新） 目的：记录商家付款并更新用户钱包。 为何选择该数据库？与 P2P 支付的需求类似，可灵活设置商家特定字段。

merchant_payments collection: Stores transaction details.


{
  "payment_id": "string",
  "merchant_id": "string",
  "user_id": "string",
  "amount": "decimal",
  "status": "string",
  "timestamp": "ISODate"
}

5.6 交易历史

1. 前端到交易服务：

• 前台向交易服务发送 GET /transactions/history 请求。
• 交易服务从数据库中检索交易记录。

2.将交易服务转为日志服务（可选）：

• 如果需要丰富的交易详细信息（如元数据或详细日志），交易服务会向日志服务发出 GET /logs/enrich-transactions 调用。
• 日志服务会回复附加数据，并将其与基本交易历史记录合并。

1. 对前端的响应：交易服务会将完整的交易历史记录（无论是否经过充实）返回给前台。

上述工作流程可确保向用户实时提供交易历史记录，并可通过日志服务灵活地纳入详细的分析：

API 交互

Kafka 事件

此工作流程完全同步，不涉及基于 Kafka 的事件驱动通信。

5.7 欺诈检测

事件消耗（欺诈检测服务）：

• 欺诈检测服务订阅 transaction.completed Kafka 主题
• 利用欺诈检测算法对每笔交易进行近乎实时的分析

2.标记可疑交易：如果发现异常，欺诈检测服务会标记该交易。

3.事件发布（欺诈警报）：对于标记的交易，欺诈检测服务会向 Kafka 发布 fraud.alert 事件。

4.通知服务：通知服务消耗欺诈警报事件，并向相关用户或管理员发送警报。

5.日志服务：日志服务通过 Kafka 事件（fraud.alert）和直接 API 调用记录欺诈警报详情，用于审计和故障排除。

上述工作流程利用 Kafka 进行实时异常检测和事件驱动通知，同时确保通过 API 进行日志记录，以实现可追溯性和可审计性。

欺诈检测工作流程：

API交互

Kafka 事件

DB 设计

数据库：分析数据库（如 Elasticsearch、Snowflake）

目的：记录可疑交易并分析欺诈模式。

为何选择：全文搜索和异常情况高级查询、大型数据集快速查询。

- fraud_transactions index: Stores flagged transactions.

{
  "fraud_transactions": {
    "mappings": {
      "properties": {
        "transaction_id": { "type": "keyword" },
        "user_id": { "type": "keyword" },
        "merchant_id": { "type": "keyword" },
        "amount": { "type": "double" },
        "anomaly_score": { "type": "float" },
        "timestamp": { "type": "date" }
      }
    }
  }
}

- fraud_patterns index: Defines reusable fraud detection patterns.


{
  "fraud_patterns": {
    "mappings": {
      "properties": {
        "pattern_id": { "type": "keyword" },
        "description": { "type": "text" },
        "created_at": { "type": "date" }
      }
    }
  }
}

5.8 通知

事件消费

• 通知服务订阅多个 Kafka 主题，如 user.created、wallet.fund_added、transaction.completed 和 fraud.alert
• 收到事件后，它会处理信息并生成个性化通知

API交互

根据用户偏好和通知类型，通知服务与外部网关进行交互：

• 用于发送电子邮件的电子邮件网关
• 用于发送短信的 SMS 网关
• 用于发送设备通知的推送通知网关

上述工作流程可确保在整个系统内无缝传送各种事件的通知。

通知工作流程：

API

Kafka事件

6 总结

构建支付钱包要求架构具有可扩展性和弹性，并且能够以最小的延迟每秒处理数百万笔交易。以下是我们选择微服务架构、Kafka 和特定数据库的原因：

6.1 为什么要采用微服务架构？🛠️

模块化和隔离：每个核心功能（如支付、分类账、身份验证）都是独立开发、部署和扩展的，从而确保更快的开发速度和更容易的调试。

故障隔离：一项服务（如支付）的故障不会连锁到其他服务（如账簿或用户管理）。

技术不可知论：服务可根据自身需要使用最合适的技术堆栈（例如，用于实时查询的 NoSQL、用于事务一致性的关系数据库）。

6.2 为什么用Kafka进行事件处理？💬

实时更新：Kafka 可确保支付、账簿和通知等服务之间的实时通信。付款成功 "或 "余额更新 "等事件可即时传播。

解耦：服务通过 Kafka 异步交互，提高了灵活性和容错性。生产者（如支付服务）和消费者（如账本服务）是松散耦合的。

可扩展性：Kafka 的分布式特性支持高吞吐量场景，因此非常适合每天处理数百万个钱包事件。

可重播性：Kafka 存储和重放事件的能力有助于调试和故障恢复。

6.3 数据库注意事项 📊

数据库选择：

• 关系型数据库（如 PostgreSQL）：确保余额更新和事务记录等关键操作符合 ACID 标准
• NoSQL 数据库（如 Cassandra 或 DynamoDB）：处理钱包余额和用户元数据的高速、低延迟查询