📚 课程目录第3章支付工厂架构总览

3. 支付工厂架构总览

支付工厂不是把原有支付系统简单“拆大”，而是围绕统一收单、统一路由、统一账务、统一清结算构建一套可复用、可扩展、可治理的支付能力底座。理解支付工厂，首先要看清它的分层结构、服务边界、系统关系与技术选型逻辑，否则后续建设很容易退化为“微服务堆砌”。

一、核心原理：分层架构是支付工厂的骨架

支付工厂通常采用五层架构：接入层、网关层、业务服务层、核心能力层、基础设施层。接入层面向商户、收银台、开放平台和内部业务系统，负责协议适配与鉴权；网关层承担统一路由、限流、熔断、签名验签与幂等控制；业务服务层按支付产品组织，如收单、代付、退款、分账；核心能力层沉淀支付单、交易、账务、清结算、对账、渠道路由等公共能力；基础设施层提供数据库、缓存、消息、配置、日志、监控与任务调度。

分层的价值在于隔离变化：渠道接口频繁变更，应被限制在渠道适配层；业务产品快速迭代，应尽量复用核心能力；账务与资金规则必须稳定，不能随前端需求随意改动。支付工厂的稳定性，来自层与层之间清晰的职责边界。

判断分层是否合理，可以用一句话检验：当新增一个支付渠道时，是否只需要增加渠道适配与路由配置，而不改动账务、清结算和订单核心？如果答案是否定的，说明分层已被击穿。

二、微服务划分：按业务能力而非技术分层切分

微服务划分应遵循高内聚、低耦合、独立数据、独立发布原则。支付工厂常见服务划分如下：

服务域	核心职责	典型服务	数据边界
接入域	协议适配、鉴权、商户接入	开放网关、收银台服务	商户配置、密钥
交易域	支付单、退款单、交易状态	收单服务、退款服务、交易查询	支付订单、退款订单
路由域	渠道路由、降级、限流	路由服务、渠道健康服务	路由规则、渠道状态
账务域	记账、余额、分录、试算	账务服务、账户服务	账户、分录、余额
清结算域	计费、分账、结算、打款	计费服务、结算服务、分账服务	计费规则、结算单
对账域	渠道对账、差错处理	对账服务、差错服务	对账文件、差错单
渠道域	渠道协议、签名、报文转换	微信适配、支付宝适配、银联适配	渠道配置、渠道流水

划分时最容易犯的错误是按技术层拆服务，例如拆出“签名服务”“报文服务”“数据库服务”。这类服务没有业务语义，会导致调用链冗长、事务边界模糊。正确做法是按业务能力拆分，让每个服务拥有自己的聚合根与数据表。

三、核心系统与外围系统关系

支付工厂的核心系统包括支付交易核心、账务核心、清结算核心、对账核心、渠道路由核心。外围系统包括商户平台、风控系统、营销系统、发票系统、客服系统、数据仓库、财务系统等。核心系统必须保持稳定、强一致、可审计；外围系统可以异步、最终一致、快速迭代。

两者关系应遵循核心收敛、外围开放：核心系统通过标准 API 与事件对外输出能力，外围系统不得直接读写核心库。例如风控系统通过同步接口参与支付决策，但不得直接修改支付单状态；营销系统通过事件订阅获取支付成功消息，异步发放权益。

四、技术选型原则与常见误区

支付工厂技术选型应坚持稳定优先、成熟优先、可运维优先。具体原则包括：

一致性优先：资金相关操作必须支持强一致或可靠最终一致，优先选择支持事务消息、幂等表、对账补偿的成熟方案。
可观测性优先：链路追踪、指标监控、日志检索、告警必须作为基础设施同步建设，不能后补。
可回滚优先：任何变更都要有灰度、开关、回滚预案，尤其是路由规则与计费规则。
避免过度追新：支付核心不承担新技术试验田角色，新框架应先在边缘系统验证。

常见误区：把“微服务”等同于“分布式事务自由”；把“高可用”等同于“多活”；把“解耦”等同于“全部异步”。支付工厂中，支付单创建、账务记账、渠道扣款等关键路径必须明确一致性级别，不能为了架构美观牺牲资金安全。

复盘一个典型场景：某团队将渠道路由做成独立服务后，路由规则变更未做灰度，导致部分商户支付成功率骤降。根因不是微服务拆分错误，而是缺少路由规则版本化、灰度发布与快速回滚。因此，技术选型必须同时考虑“能力”与“治理”。

# 路由规则灰度配置示例
route:
  ruleId: R20240501
  gray:
    enabled: true
    percent: 5
    merchantWhitelist: [M10086, M10010]
  fallback:
    channel: ALIPAY
    timeoutMs: 800
  rollback:
    auto: true
    errorRateThreshold: 0.02

总之，支付工厂架构总览的核心是：分层定边界，微服务定能力，核心外围定治理，技术选型定底线。只有先把这四件事说清楚，后续的支付单、账务、清结算、对账与渠道接入建设才不会失控。