1. 项目背景与挑战作为微赚淘客系统3.0的核心研发成员我们面临一个极具挑战性的技术需求为微信公众号查券助手构建一个能够支撑日均200万次商品券查询请求、峰值QPS超过3500的高可用服务系统。这个系统需要满足以下几个核心需求高并发处理能力在电商大促期间如双11系统需要能够应对突发的流量高峰低延迟响应用户查询体验至关重要需要将平均响应时间控制在200ms以内高可用性系统需要达到99.99%的可用性即全年不可用时间不超过52分钟弹性伸缩能够根据流量变化自动扩缩容既保证性能又控制成本快速故障恢复当某个组件出现问题时系统能够自动隔离故障并快速恢复面对这些需求我们经过多轮技术选型评估最终决定采用Java Spring Cloud Alibaba作为基础技术栈。这个选择主要基于以下几个考量生态完整性Spring Cloud Alibaba提供了一整套微服务解决方案包括服务注册发现、配置中心、熔断限流等核心组件社区活跃度作为阿里巴巴开源的项目有强大的技术支持和活跃的开发者社区与Spring生态的无缝集成可以充分利用Spring Boot的开发效率和Spring Cloud的标准化接口云原生友好完美适配Kubernetes等容器编排平台便于实现弹性伸缩2. 技术架构设计2.1 整体架构我们的系统采用经典的微服务架构设计主要分为以下几个核心模块API网关层负责请求路由、鉴权、限流等通用功能业务服务层包括优惠券查询服务、佣金计算服务等核心业务模块中间件层包含Nacos、Sentinel、RocketMQ等支撑组件数据存储层使用MySQL作为主数据库Redis作为缓存架构图如下文字描述客户端 → API网关 → 业务服务集群 ↓ Nacos(服务注册中心) ←→ Sentinel(熔断限流) ↓ RocketMQ(消息队列) ↓ MySQL Redis(数据存储)2.2 核心组件选型我们选择了以下核心组件来构建系统Nacos作为服务注册中心和配置中心替代了传统的EurekaConfig组合优势支持动态配置、服务发现、命名空间隔离等功能版本1.4.2Sentinel负责系统的流量控制、熔断降级优势支持热点参数限流、系统自适应保护等高级特性版本1.8.2RocketMQ用于异步消息处理优势高吞吐、低延迟适合订单量大的场景版本4.9.3Seata处理分布式事务优势AT模式对业务代码侵入小版本1.4.2OpenFeign服务间HTTP调用优势声明式API与Spring Cloud深度集成3. 核心实现细节3.1 服务注册与配置管理我们使用Nacos同时作为服务注册中心和配置中心配置如下# bootstrap.yml spring: application: name: coupon-query-service cloud: nacos: discovery: server-addr: nacos.juwatech.cn:8848 namespace: prod-namespace-id config: server-extension: yaml refresh-enabled: true shared-configs: ->// 定义Feign客户端接口 FeignClient(name commission-service, fallback CommissionClientFallback.class, configuration FeignConfig.class) public interface CommissionClient { GetMapping(/api/commission/rate) CommissionRateResponse getCommissionRate(RequestParam String itemId); } // 降级实现 Component public class CommissionClientFallback implements CommissionClient { private static final BigDecimal DEFAULT_RATE new BigDecimal(0.5); Override public CommissionRateResponse getCommissionRate(String itemId) { log.warn(触发降级使用默认佣金率itemId{}, itemId); return new CommissionRateResponse(itemId, DEFAULT_RATE); } } // Sentinel配置 PostConstruct public void initSentinelRules() { // 流控规则每秒最多1000次调用 FlowRule rule new FlowRule(commission-service) .setGrade(RuleConstant.FLOW_GRADE_QPS) .setCount(1000) .setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_DEFAULT); FlowRuleManager.loadRules(Collections.singletonList(rule)); }实际应用中的经验降级策略应根据业务特点设计如电商场景可返回缓存数据或默认值熔断阈值需要根据实际压测结果调整一般错误比例阈值设为50%对于核心服务建议设置慢调用比例熔断如RT500ms占比超过50%3.3 热点参数限流针对爆款商品的查询热点问题我们实现了基于商品ID的热点参数限流SentinelResource(value queryCoupon, blockHandler handleBlock, fallback handleFallback) public CouponResult queryCoupon(String itemId) { // 业务逻辑 return doQuery(itemId); } // 限流处理 public CouponResult handleBlock(String itemId, BlockException ex) { log.warn(商品ID {} 被限流, itemId); return CouponResult.fallback(itemId); } // 异常处理 public CouponResult handleFallback(String itemId, Throwable t) { log.error(查询优惠券异常, t); return CouponResult.fallback(itemId); }对应的Sentinel规则配置{ resource: queryCoupon, grade: 1, paramIdx: 0, count: 100, durationInSec: 1, controlBehavior: 0, clusterMode: false }关键点说明paramIdx0表示对第一个参数(itemId)进行限流count100表示每个itemId每秒最多100次查询通过SentinelResource注解实现细粒度控制3.4 异步日志处理为了不影响主流程性能我们使用RocketMQ异步处理查询日志Service public class QueryLogProducer { Autowired private RocketMQTemplate rocketMQTemplate; public void sendQueryLog(QueryLog log) { rocketMQTemplate.asyncSend(QUERY_LOG_TOPIC, MessageBuilder.withPayload(log).build(), new SendCallback() { Override public void onSuccess(SendResult sendResult) { // 发送成功处理 } Override public void onException(Throwable e) { log.error(发送日志失败, e); // 失败降级处理如写入本地文件 } }); } }优化实践采用异步发送避免阻塞主线程设置合理的重试策略默认2次对于重要日志实现本地文件降级方案监控消息堆积情况设置合理的Topic队列数4. 性能优化实践4.1 缓存策略我们采用多级缓存架构提升查询性能本地缓存使用Caffeine缓存热点商品数据Bean public CacheString, CouponInfo localCache() { return Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(5, TimeUnit.MINUTES) .recordStats() .build(); }分布式缓存Redis集群缓存全量商品数据数据结构Hash存储商品ID → 优惠券信息过期策略随机过期时间避免缓存雪崩缓存更新策略被动更新查询时发现缓存不存在则回源查询主动更新通过RocketMQ接收商品变更通知4.2 线程池优化针对IO密集型操作我们优化了线程池配置Bean public ThreadPoolTaskExecutor ioTaskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(20); executor.setMaxPoolSize(100); executor.setQueueCapacity(500); executor.setThreadNamePrefix(io-exec-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; }配置要点根据压测结果设置合理的线程数通常CPU核数×2使用有界队列避免内存溢出监控线程池指标活跃线程数、队列大小等4.3 JVM调优针对高并发场景我们对JVM参数进行了优化-server -Xms4g -Xmx4g -XX:UseG1GC -XX:MaxGCPauseMillis200 -XX:InitiatingHeapOccupancyPercent45 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/logs/heapdump.hprof调优效果GC停顿时间减少60%吞吐量提升30%内存溢出时自动生成dump文件便于分析5. 监控与运维5.1 全链路监控我们搭建了基于Prometheus Grafana的监控系统应用指标通过Micrometer暴露JVM、HTTP请求等指标Bean public MeterRegistryCustomizerPrometheusMeterRegistry metricsCommonTags() { return registry - registry.config().commonTags(application, coupon-service); }业务指标自定义关键业务指标Service public class CouponMetrics { private final Counter queryCounter; public CouponMetrics(MeterRegistry registry) { queryCounter registry.counter(coupon.query.count, type, total); } public void incrementQuery() { queryCounter.increment(); } }告警规则设置QPS突增、错误率升高等告警5.2 日志收集采用ELK栈实现集中式日志管理日志格式统一使用JSON格式便于解析encoder classnet.logstash.logback.encoder.LogstashEncoder customFields{app:coupon-service,env:prod}/customFields /encoder采样策略对DEBUG日志进行采样避免产生过多日志敏感信息过滤掉身份证、手机号等敏感信息5.3 灾备方案为确保系统高可用我们实现了以下灾备措施多可用区部署服务实例分布在3个可用区数据库主从MySQL配置一主三从缓存双活Redis采用集群模式跨机房部署流量切换通过Nginx实现机房级流量切换6. 实际效果与经验总结经过上述架构设计和优化系统在双11大促期间的表现可用性达到99.992%全年不可用时间约42分钟性能平均响应时间128msP99500ms吞吐量峰值QPS达到4,200远超预期目标弹性根据流量自动扩缩容节省30%服务器成本关键经验总结配置中心化所有环境相关的配置必须通过Nacos管理避免打包环境差异限流精细化不仅要限制总QPS更要关注热点参数的限流降级有预案每个依赖服务都必须有明确的降级策略监控全覆盖从基础设施到业务指标都需要完整监控压测常态化定期进行全链路压测提前发现瓶颈踩过的坑与解决方案Nacos客户端内存泄漏升级到1.4.2版本解决长轮询问题Sentinel规则丢失配置规则持久化到NacosRocketMQ消息堆积调整消费者线程数并优化处理逻辑Feign超时设置区分连接超时和读取超时避免雪崩后续优化方向引入Service Mesh实现更细粒度的流量控制尝试Serverless架构应对突发流量优化分布式追踪系统降低性能损耗探索AI预测自动扩缩容策略