微服务架构下支付系统的设计与实践

1. 支付功能在单体与微服务架构下的设计差异在孢子记账从单体架构向微服务架构迁移的过程中支付功能模块的改造是最具挑战性的部分之一。单体架构下的支付模块通常采用紧耦合设计所有支付方式微信、支付宝、银联等的代码都打包在同一个项目中通过共享数据库表来记录交易流水。这种设计在初期确实简单直接但随着业务增长问题逐渐显现支付渠道的增加导致核心业务代码频繁修改某支付渠道的异常可能影响整个系统稳定性支付成功率等关键指标难以单独监控不同支付方式的技术栈升级相互制约在微服务架构下我们采用支付网关模式进行重构。每个主流支付方式都拆分为独立微服务通过API网关统一暴露接口。具体技术实现上我们基于.NET 8的Minimal API构建轻量级支付服务// 支付宝支付服务入口示例 var builder WebApplication.CreateBuilder(args); builder.AddServiceDefaults(); // .NET 8微服务增强配置 var app builder.Build(); app.MapDefaultEndpoints(); app.MapPost(/alipay/create, async (CreatePaymentRequest request, IAlipayClient client) { var response await client.CreateOrderAsync(request); return Results.Ok(response); }).WithTags(Alipay); app.Run();关键经验支付服务拆分时要确保事务最终一致性。我们采用.NET 8新引入的分布式事务协调器配合SQL Server的Always On可用性组实现跨支付服务的事务管理。2. 常用支付方式的微服务化实现2.1 微信支付服务设计微信支付在微服务架构下需要考虑H5场景的特殊授权要求。我们通过独立的WeChatPay服务处理所有微信生态支付场景授权拦截层使用.NET 8的端点过滤器实现builder.Services.AddScopedIEndpointFilter, WechatAuthFilter();支付订单服务采用CQRS模式分离读写// 命令处理 public class CreateWechatOrderHandler : ICommandHandlerCreateWechatOrderCommand { public async Task Handle(CreateWechatOrderCommand command) { // 调用微信支付API } }回调处理利用.NET 8的速率限制中间件防刷app.MapPost(/wechat/notify, [RateLimit(10, 10s)] async (NotifyRequest request) {...})2.2 支付宝服务的高可用设计针对支付宝服务我们重点解决了以下问题连接池管理使用Polly配置弹性HTTP客户端builder.Services.AddHttpClientAlipayClient() .AddStandardResilienceHandler(options { options.Retry.MaxRetryAttempts 3; });数据一致性采用Saga模式处理长事务public class AlipaySaga : SagaAlipaySagaData, IAmStartedByPaymentStartedEvent, IHandleMessagesPaymentCompletedEvent { // Saga状态机实现 }2.3 银联支付与新兴支付方式对于银联等传统支付方式我们将其封装为独立服务并添加适配器层public class UnionPayAdapter : IPaymentProvider { public async TaskPaymentResult ProcessAsync(PaymentRequest request) { // 转换参数格式调用银联SDK } }同时预留了数字货币等新兴支付方式的扩展点public interface ICryptoPaymentProvider { TaskWalletBalance GetBalanceAsync(string walletId); TaskTransactionResult TransferAsync(TransactionRequest request); }3. 支付核心功能的跨服务协同3.1 分布式事务处理支付业务涉及多个服务的协同工作我们采用以下方案保证一致性本地消息表记录支付操作日志CREATE TABLE PaymentEventLog ( EventId UNIQUEIDENTIFIER PRIMARY KEY, PaymentId NVARCHAR(50) NOT NULL, EventType NVARCHAR(20) NOT NULL, Payload NVARCHAR(MAX) NOT NULL, Status TINYINT DEFAULT 0, Created DATETIME2 DEFAULT SYSUTCDATETIME() );定时补偿任务使用.NET 8新的BackgroundService实现protected override async Task ExecuteAsync(CancellationToken stoppingToken) { while (!stoppingToken.IsCancellationRequested) { await ProcessPendingEventsAsync(); await Task.Delay(TimeSpan.FromMinutes(1), stoppingToken); } }3.2 支付结果通知机制微服务架构下的支付结果通知需要特别设计事件总线集成使用CAP框架实现跨服务事件[CapSubscribe(payment.completed)] public async Task HandlePaymentCompleted(PaymentCompletedEvent event) { // 更新订单状态 }Webhook重试策略指数退避算法实现builder.Services.AddRetryPolicyWebhookPolicy(options { options.MaxRetryCount 5; options.FirstRetryDelay TimeSpan.FromSeconds(1); });4. 支付服务的运维与监控4.1 可观测性增强.NET 8为微服务提供了强大的可观测性支持OpenTelemetry集成builder.Services.AddOpenTelemetry() .WithMetrics(metrics { metrics.AddMeter(Microsoft.AspNetCore.Hosting); }) .WithTracing(tracing { tracing.AddSource(PaymentService); });健康检查端点app.MapHealthChecks(/health, new HealthCheckOptions { ResponseWriter UIResponseWriter.WriteHealthCheckUIResponse });4.2 性能优化实践针对支付服务的高并发场景我们实施了以下优化缓存策略使用分布式缓存减少数据库压力[OutputCache(PolicyName PaymentPolicy)] public async TaskPaymentResult GetPayment(string id) { // 查询支付结果 }数据库访问优化针对SQL Server的特定调优services.AddDbContextPaymentContext(options { options.UseSqlServer(connectionString, sql { sql.EnableRetryOnFailure(3); sql.CommandTimeout(30); }); });在实际部署中我们通过Kubernetes的HPA实现自动扩缩容apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: payment-service spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: payment-service minReplicas: 3 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70支付服务的迁移过程中最大的收获是认识到微服务不是简单的技术拆分而是组织架构和研发流程的全面升级。我们建立了专门的支付SRE团队采用双周迭代节奏每个支付渠道服务都有独立的CI/CD流水线。监控方面除了常规的APM指标还特别关注支付成功率、平均处理时间等业务指标。