摘要本文介绍一套面向海外支付场景的计费中台架构实践通过领域驱动设计DDD和配置化引擎实现新业务接入成本降低 80%、代码复用率提升 70%、计费成功率 100% 的工程目标。关键词计费中台领域驱动设计配置化引擎架构实践1. 背景与问题1.1 业务挑战海外支付业务面临地域多样性、渠道复杂性、业务多元性、场景灵活性等挑战各国监管政策、费率结构差异显著计费逻辑需快速适配迭代。1.2 架构痛点传统计费架构采用分散式嵌入式设计计费能力散落在路由系统router、网关系统gateway等多个子系统中核心问题代码重复相同计费逻辑多系统重复实现复用率低于 30%一致性风险路由估算与网关实际扣费存在偏差对账困难变更成本高新增渠道需多系统协同发布周期 2-3 周追溯困难计费日志分散全链路定位问题成本高1.3 解决思路构建独立计费中台billing将计费能力从业务系统中剥离统一收归至独立中台实现能力复用、配置驱动、热更新。2. 架构方案2.1 架构演进【改造前】 【改造后】 分散计费模式 统一计费架构 · 逻辑散落 → · 能力下沉 · 硬编码为主 · 配置驱动 · 需重启生效 · 热更新2.2 统一计费架构2.3 分层设计3. 领域建模3.1 核心实体基于 DDD 思想对计费领域进行抽象建模3.2 实体定义4. 核心设计4.1 事件风暴通过事件风暴识别计费领域核心业务事件4.2 聚合根设计采用聚合根模式封装计费规则确保业务一致性边界public class BillingRuleAggregate { private RuleId ruleId; private ConditionSpec condition; private FormulaSpec formula; private RateConfig rateConfig; public boolean matches(BillingContext context) { return condition.evaluate(context); } public BillingResult calculate(BillingContext context) { Decimal amount formula.compute(context, rateConfig); return BillingResult.create(amount, getCalculationDetails()); } }4.3 配置化体系支持多维度配置组合实现配置即开发采用Aviator作为表达式求值引擎支持条件表达式、公式表达式、三元表达式、函数调用等4.4 算法模型计费引擎支持固定费用和比例费用两种模式5. 关键实现5.1 配置缓存架构采用多级缓存 变更推送架构保障高性能多级缓存Caffeine 本地缓存 Redis 分布式缓存变更推送Redis Pub/Sub 实时通知各节点缓存预热服务启动时预加载全量配置降级策略缓存失效时降级至数据库5.2 规则执行引擎基于 Aviator 实现动态规则解析private static final MapString, Expression EXPRESSION_CACHE new ConcurrentHashMap(); public Expression getExpression(String expressionStr) { return EXPRESSION_CACHE.computeIfAbsent(expressionStr, AviatorEvaluator::compile); }工作流程表达式解析 → 字节码编译 → 缓存复用 → 环境注入 → 结果返回5.3 结构化日志日志支持全链路追溯与审计{ traceId: 计费链路追踪 ID, tenantId: 租户标识, scenarioCode: 场景编码, matchedRules: [{ruleId: 规则 ID, ruleName: 规则名称}], calculation: {originalAmount: 原始金额, rateApplied: 应用费率, finalFee: 最终费用}, result: {status: 计费状态, feeAmount: 费用金额} }6. 系统成效6.1 核心指标当前系统支撑近 20 家交易渠道、10 余条业务线、近 10 种交易场景的计费需求。6.2 性能表现6.3 稳定性表现7. 架构扩展能力7.1 清结算场景计费引擎的算费能力可扩展至清结算领域支撑商户结算、分润、服务费等场景7.2 插件化扩展系统采用插件化架构支持按需扩展新的计费场景8. 总结核心经验领域抽象深入理解业务提炼通用模型配置驱动变化部分配置化提升灵活性缓存保障多级缓存策略保障高性能日志基石结构化日志支持全链路追溯设计原则作者简介