支付 on 姚玉亮的网络日志

动态计费引擎：复杂计费规则的配置化与计算实践

Thu, 25 Jan 2024 10:30:00 +0800

每来一个新商户，就发一次版

统一支付平台对接的商户类型非常杂：按笔收固定手续费的、按金额走阶梯费率的、月封顶的，还有"新商户前三个月免费、之后 0.6%“这种带时间条件的。最早的版本是每来一个新商户就改一次代码、发一次版，运营在群里追着开发改费率。这么下去肯定不行。

我当时的目标很明确：运营在后台配规则，计费引擎按规则实时算出手续费，不改代码、不发版；同时计费结果要可追溯、可对账。

计费拆成三层

计费维度（Dimension）：交易金额、笔数、商户等级、交易时间、渠道，从订单上下文里提取；
规则（Rule）：一组条件加一种计费方式。条件支持 AND/OR 组合，计费方式支持固定费、比例费率、阶梯、封顶、包月；
策略（Policy）：一个商户绑定一条或多条策略，策略按优先级命中第一条，或多条叠加。

规则存储我没用 DSL，而是用 JSON 结构化存储，运维友好且易于版本化：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


{
 "policy_id": "P_NEW_USER_3M",
 "priority": 100,
 "rules": [
 {
 "when": { "all": [
 { "field": "merchant.tags", "op": "contains", "value": "new" },
 { "field": "trade.created_at", "op": "before",
 "value": "merchant.joined_at + P3M" }
 ]},
 "then": { "type": "fixed", "amount": 0 }
 },
 {
 "when": { "all": [
 { "field": "trade.amount", "op": ">=", "value": 0 }
 ]},
 "then": { "type": "rate", "rate": "0.006",
 "min_fee": "0.01", "cap_monthly": "500.00" }
 }
 ]
}

求值器自己写

引擎入口是 Calculator：从订单上下文抽维度，策略按优先级排好，规则链依次求值，命中第一条就返回：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


type Dimension struct {
 MerchantID string
 Tags []string
 JoinedAt time.Time
 Amount decimal.Decimal
 CreatedAt time.Time
 Channel string
}

type Calculator struct {
 policyRepo PolicyRepo
 capRepo MonthlyCapRepo
}

func (c *Calculator) Fee(ctx context.Context, d Dimension) (decimal.Decimal, string, error) {
 policies, err := c.policyRepo.ListByMerchant(ctx, d.MerchantID)
 if err != nil {
 return decimal.Zero, "", err
 }
 sort.Slice(policies, func(i, j int) bool {
 return policies[i].Priority > policies[j].Priority
 })

 for _, p := range policies {
 for _, r := range p.Rules {
 if !match(r.When, d) {
 continue
 }
 fee, err := c.apply(ctx, r.Then, d)
 if err != nil {
 return decimal.Zero, "", err
 }
 return fee, p.PolicyID, nil
 }
 }
 return decimal.Zero, "", ErrNoPolicyMatched
}

match 我没有引表达式引擎，自己写了一个小型求值器，只支持有限的操作符：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


func match(node ConditionNode, d Dimension) bool {
 if len(node.All) > 0 {
 for _, n := range node.All {
 if !match(n, d) {
 return false
 }
 }
 return true
 }
 if len(node.Any) > 0 {
 for _, n := range node.Any {
 if match(n, d) {
 return true
 }
 }
 return false
 }
 actual := extract(d, node.Field)
 return compare(actual, node.Op, node.Value)
}

第一版其实考虑过直接上 Drools 或者 Go 生态里的表达式库，后来放弃了。一是团队得再学一门 DSL，二是表达式库出问题不好调试。自己这个求值器只有 200 多行，操作符能覆盖所有实际场景，出问题看日志一眼能定位。

阶梯费率和月封顶是两个相对复杂的计费方式：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


func (c *Calculator) apply(ctx context.Context, action Action, d Dimension) (decimal.Decimal, error) {
 switch action.Type {
 case "fixed":
 return decimal.NewFromFloat(action.Amount), nil
 case "rate":
 fee := d.Amount.Mul(action.Rate)
 if action.MinFee.GreaterThan(decimal.Zero) && fee.LessThan(action.MinFee) {
 fee = action.MinFee
 }
 if action.CapMonthly.GreaterThan(decimal.Zero) {
 used, _ := c.capRepo.MonthUsed(ctx, d.MerchantID, d.CreatedAt)
 remain := action.CapMonthly.Sub(used)
 if remain.LessThanOrEqual(decimal.Zero) {
 return decimal.Zero, nil
 }
 if fee.GreaterThan(remain) {
 fee = remain
 }
 }
 return fee, nil
 case "tiered":
 return applyTiered(action.Tiers, d.Amount), nil
 }
 return decimal.Zero, fmt.Errorf("unknown action type: %s", action.Type)
}

金额一律用 shopspring/decimal，绝不用 float64，这是做支付的底线。

三个坑

月封顶的并发问题真踩过。一笔订单算费时先读"本月已收”，再加当前 fee 写回 cap 表，两笔并发一撞就会超额。最后改成了 INSERT ... ON DUPLICATE KEY UPDATE used = used + ? 的原子更新，配合 merchant_id + yyyymm 唯一索引：先原子递增，再判断超没超额，超额部分回滚为 0。

第二个是阶梯计费的口径。是"全额落入某档"还是"分段累进"？两种业务都有，是跟运营反复确认才掰清楚的。我在 action 里加了 tier_mode: "full" | "progressive" 区分，不硬编码。

第三个是规则发布。每次运营改规则我都生成新版本号，订单上记录命中的 policy_id + version，对账时能精确还原"当时这笔订单是按哪条规则算的"。新规则先在白名单商户灰度 24 小时，再全量。

后来

这套引擎上线之后，新商户的费率配置从"排期等开发"变成运营后台自助，几分钟搞定。每笔手续费都带着规则版本，对账和客诉处理都轻松了不少。规则引擎这事，我的体会是不必追求大而全：能覆盖业务、能调试、能灰度，就够了。

封面图：Ralf Steinberger / Flickr · CC BY 2.0

支付平台三端分离架构设计：多场景统一支付的落地

Sat, 09 Dec 2023 10:30:00 +0800

支付场景太散了

我在某科技公司主导统一支付平台。支付场景很散：有面向终端用户的充值、订阅付费，有面向机构客户的对公转账和批量打款，还有运营后台的手工调账、退款审批。要是把这些逻辑全塞进一个应用，权限边界会搅在一起，发版互相影响，接口粒度也没法统一。

我的做法是三端分离、共用一个支付内核：用户端、商户端、管理端各自独立部署，底层共用支付订单、状态机、渠道适配和对账能力。

三端，一个内核

接入层用 Gin 起了三个独立服务，各自有自己的路由组和中间件链。用户端对接前端，OAuth2 登录，只有下单、查单、回调接收；商户端对接机构客户的系统，走 AppID/AppSecret 的 OpenAPI 签名认证，提供统一下单、退款、查询；管理端对接运营后台，RBAC 权限，审批、调账、对账导出都在这。

三端都不直接碰数据库，统一走 gRPC 调 payment-core。支付核心封装了订单状态机和支付渠道适配：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51


type PaymentService struct {
 db *gorm.DB
 channels map[string]Channel // channelCode -> adapter
 engine *billing.Engine // 动态计费引擎
}

type Channel interface {
 CreateOrder(ctx context.Context, order *Order) (payURL string, err error)
 QueryOrder(ctx context.Context, orderNo string) (*ChannelOrder, error)
 Refund(ctx context.Context, orderNo string, amount int64) error
 ParseCallback(req *http.Request) (*CallbackResult, error)
}

// 统一下单入口，三端最终都走到这里
func (s *PaymentService) CreateOrder(ctx context.Context, req *CreateOrderReq) (*Order, error) {
 // 1. 计费引擎算出应付金额
 amount, err := s.engine.Calculate(ctx, req.BizCode, req.Params)
 if err != nil {
 return nil, err
 }

 order := &Order{
 OrderNo: snowflake.New().NextID().String(),
 BizCode: req.BizCode,
 BizID: req.BizID,
 PayerID: req.PayerID,
 Amount: amount,
 Status: OrderStatusPending,
 Channel: req.ChannelCode,
 CreatedAt: time.Now(),
 }

 // 2. 落库
 if err := s.db.Create(order).Error; err != nil {
 return nil, err
 }

 // 3. 调起对应渠道
 ch, ok := s.channels[req.ChannelCode]
 if !ok {
 return nil, ErrChannelNotSupported
 }
 payURL, err := ch.CreateOrder(ctx, order)
 if err != nil {
 order.Status = OrderStatusFailed
 s.db.Model(order).Update("status", OrderStatusFailed)
 return nil, err
 }
 order.PayURL = payURL
 return order, nil
}

商户端的签名认证是独立中间件，除了验签还带防重放，5 分钟时间窗加 nonce 去重：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


func MerchantSignAuth(redis *redis.Client, merchantSvc MerchantService) gin.HandlerFunc {
 return func(c *gin.Context) {
 appID := c.GetHeader("X-App-Id")
 sign := c.GetHeader("X-Sign")
 timestamp := c.GetHeader("X-Timestamp")
 nonce := c.GetHeader("X-Nonce")

 if appID == "" || sign == "" {
 c.AbortWithStatusJSON(401, gin.H{"msg": "missing auth headers"})
 return
 }
 // 防重放：5 分钟时间窗 + nonce 去重
 if math.Abs(float64(time.Now().Unix()-toInt64(timestamp))) > 300 {
 c.AbortWithStatusJSON(401, gin.H{"msg": "timestamp expired"})
 return
 }
 if ok, _ := redis.SetNX(c, "nonce:"+nonce, 1, 5*time.Minute).Result(); !ok {
 c.AbortWithStatusJSON(401, gin.H{"msg": "replayed request"})
 return
 }

 secret, err := merchantSvc.GetAppSecret(c, appID)
 if err != nil {
 c.AbortWithStatusJSON(401, gin.H{"msg": "invalid app"})
 return
 }
 // 按 method + path + timestamp + nonce + body 拼接待签名字符串
 signStr := buildSignString(c, timestamp, nonce)
 if err := rsa.Verify(secret.PublicKey, []byte(signStr), sign); err != nil {
 c.AbortWithStatusJSON(401, gin.H{"msg": "sign verify failed"})
 return
 }
 c.Set("merchant_id", secret.MerchantID)
 c.Next()
 }
}

四个权衡

第一是接口粒度。结果发现三端要的东西完全不一样：用户端要聚合后的 DTO，订单里带商品名、状态文案；商户端要稳定精简的字段，OpenAPI 不能随便加字段；管理端要全量字段加筛选分页。我们没有让 payment-core 做接口裁剪，而是三端 API 层各自组装 DTO，core 只返回领域模型，别让核心服务被展示逻辑污染。

第二是回调幂等。支付渠道的回调可能重复投递。我们用 order_no 加 channel_trade_no 做唯一索引，重复回调直接返回成功，不重复触发流转。状态机自己还有一层防护：Paid 状态再收到 PaySuccess 是空操作，不会重复发货。

第三是对账。三端共用一个对账内核，每天凌晨拉渠道对账单跟本地订单比对，差异进差错池。导出用 Excelize 流式写入，机构客户一次能导几十万行，全量加载会 OOM。数据隔离在 DAO 层用 merchant_id 强制过滤，商户端只能导出自己名下的订单。

第四是计费规则。按次、包月、阶梯价、渠道费率，不同业务线算法不一样。我们把规则抽成 Rule 接口，配置驱动，新增业务线只加规则实现和配置，不用动下单主流程。

后来

三端分离拆的其实是"谁在用"和"怎么支付"这两件事：认证、权限、DTO 组装留在接入层，状态机一致性和渠道扩展性收在核心层。支付系统还有条底线：业务代码不许直接改订单状态，所有流转都过状态机校验。

封面图：The City of Toronto / Flickr · CC BY 2.0