1. 项目背景与挑战2018年我刚加入这家创业公司时我们的返利APP还跑在单台8核32G的物理服务器上。随着用户量从百万级突破到日均千万UV系统开始频繁出现数据库连接池耗尽、缓存雪崩、订单超时等问题。最严重的一次大促整个系统瘫痪了47分钟直接损失佣金收入300多万元。这个典型的单体架构痛点促使我们启动了为期两年的云原生改造计划。当时面临的核心矛盾是既要保证业务连续性不能停服改造又要实现架构的平滑演进。我们最终选择了分阶段渐进式改造策略整个过程就像给飞行中的飞机更换引擎。2. 架构演进路线图2.1 第一阶段服务拆分2019Q1-Q2首先通过领域驱动设计DDD划分业务边界将原有单体拆分为六个核心服务用户中心含会员等级体系商品目录服务对接20电商平台API订单追踪服务处理电商平台回调佣金计算引擎实时离线双重计算营销活动服务优惠券/限时返利财务结算系统关键技术选型服务通信初期采用RESTFeign后期逐步引入gRPC配置中心Nacos兼顾服务发现功能数据同步Canal实现MySQL binlog订阅踩坑实录第一次拆分时错误地将用户画像和会员系统放在同一个服务导致频繁互相影响。后来按变更频率重新划分将高频访问的用户基础信息与低频更新的画像数据分离。2.2 第二阶段容器化部署2019Q3采用Kubernetes作为编排引擎时我们遇到了传统虚拟机思维到容器思维的转变挑战。几个关键决策点资源配额管理为Java服务设置合理的JVM参数-Xmx不超过容器内存的70%采用Vertical Pod Autoscaler自动调整资源请求量健康检查配置livenessProbe: httpGet: path: /actuator/health port: 8080 initialDelaySeconds: 120 # 充分考虑JVM启动时间 periodSeconds: 30 readinessProbe: httpGet: path: /actuator/ready port: 8080 failureThreshold: 3日志收集方案对比方案优点缺点适用场景EFK功能全面资源消耗大需要复杂分析的场景Loki轻量级查询功能较弱容器环境日志聚合阿里云SLS开箱即用厂商锁定全托管需求最终选择LokiGrafana方案日均处理日志量达120GB成本比ELK降低62%。2.3 第三阶段流量治理2020Q1当服务数量超过30个时传统的硬编码服务调用方式已无法维护。我们引入服务网格架构时特别关注了以下几个核心指标熔断器配置优化// 使用Resilience4j配置订单服务调用 CircuitBreakerConfig.custom() .failureRateThreshold(50) // 50%失败率触发熔断 .waitDurationInOpenState(Duration.ofSeconds(30)) .ringBufferSizeInHalfOpenState(10) .ringBufferSizeInClosedState(100) .recordExceptions(TimeoutException.class, CallNotPermittedException.class) .build();全链路压测发现的问题商品详情页依赖链路过长最多达9次RPC调用未设置合理的超时传递底层1s超时导致上层5s堆积缓存未考虑地域分布华南用户频繁访问华北Redis解决方案实施接口聚合BFF层在Istio中配置全链路超时apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: product-service spec: hosts: - product http: - timeout: 1s route: - destination: host: product2.4 第四阶段数据架构升级2020Q3原有单MySQL实例已无法支撑日均2亿的订单流水我们实施了多层次的数据架构改造分库分表方案按用户ID哈希分片128个分片采用ShardingSphere中间件保留全局索引表用于跨分片查询实时数仓建设Flink SQL实时计算佣金 INSERT INTO commission_results SELECT user_id, order_id, amount * rate * 0.98 AS commission, -- 扣除2%平台服务费 CASE WHEN level VIP THEN amount * 0.02 ELSE 0 END AS extra_bonus FROM kafka_orders WHERE status SUCCESS;缓存策略优化本地缓存Caffeine Redis分布式缓存热点Key检测自动降级采用Redisson实现分布式锁3. 云原生关键技术实践3.1 可观测性体系构建我们建立了覆盖四个维度的监控体系指标监控Prometheus采集QPS、延迟、错误率自定义业务指标如佣金计算耗时链路追踪Jaeger实现微服务调用链可视化重点优化99线P99性能日志分析关键业务日志结构化JSON格式建立200条告警规则事件中心将K8s事件、业务事件统一管理实现关键操作审计追踪3.2 混沌工程实践通过定期故障注入测试系统韧性主要场景包括随机kill节点验证K8s自愈能力模拟区域网络中断测试多AZ部署可靠性数据库主从切换演练某次测试发现的典型问题2020-11-15 压测期间 - 佣金服务线程池打满从200调整到500 - Redis连接泄漏增加连接池监控 - 订单回调积压引入动态批量处理3.3 成本优化成果经过持续优化在流量增长3倍的情况下基础设施成本仅增加40%指标改造前当前优化幅度单订单计算成本0.021元0.009元-57%服务器利用率35%68%94%发布频率每周1次每日20次20x故障恢复时间47分钟2分18秒-95%4. 经验总结与避坑指南数据库迁移教训首次分库时未考虑join查询问题导致大量业务逻辑需要重写解决方案提前建立全局视图表逐步迁移查询逻辑配置管理陷阱某次误将生产环境配置推送到预发环境改进措施建立配置变更三重校验机制缓存一致性问题采用先更新数据库再删除缓存策略增加异步重试机制处理删除失败场景人员能力建设初期团队对K8s掌握不足导致多次误操作实施每周内部技术分享认证考试制度这套架构目前支撑着日均3亿的请求量在去年双11期间平稳度过了每秒8万订单的洪峰。回头看这段演进历程最重要的体会是云原生转型不仅是技术升级更需要配套的研发流程、团队能力和监控体系的全面进化。 
长河君 · 2026/11/4 20:46:08 · 阅读 1.2k 从单体到云原生：千万级流量系统的架构演进实践
1. 项目背景与挑战2018年我刚加入这家创业公司时我们的返利APP还跑在单台8核32G的物理服务器上。随着用户量从百万级突破到日均千万UV系统开始频繁出现数据库连接池耗尽、缓存雪崩、订单超时等问题。最严重的一次大促整个系统瘫痪了47分钟直接损失佣金收入300多万元。这个典型的单体架构痛点促使我们启动了为期两年的云原生改造计划。当时面临的核心矛盾是既要保证业务连续性不能停服改造又要实现架构的平滑演进。我们最终选择了分阶段渐进式改造策略整个过程就像给飞行中的飞机更换引擎。2. 架构演进路线图2.1 第一阶段服务拆分2019Q1-Q2首先通过领域驱动设计DDD划分业务边界将原有单体拆分为六个核心服务用户中心含会员等级体系商品目录服务对接20电商平台API订单追踪服务处理电商平台回调佣金计算引擎实时离线双重计算营销活动服务优惠券/限时返利财务结算系统关键技术选型服务通信初期采用RESTFeign后期逐步引入gRPC配置中心Nacos兼顾服务发现功能数据同步Canal实现MySQL binlog订阅踩坑实录第一次拆分时错误地将用户画像和会员系统放在同一个服务导致频繁互相影响。后来按变更频率重新划分将高频访问的用户基础信息与低频更新的画像数据分离。2.2 第二阶段容器化部署2019Q3采用Kubernetes作为编排引擎时我们遇到了传统虚拟机思维到容器思维的转变挑战。几个关键决策点资源配额管理为Java服务设置合理的JVM参数-Xmx不超过容器内存的70%采用Vertical Pod Autoscaler自动调整资源请求量健康检查配置livenessProbe: httpGet: path: /actuator/health port: 8080 initialDelaySeconds: 120 # 充分考虑JVM启动时间 periodSeconds: 30 readinessProbe: httpGet: path: /actuator/ready port: 8080 failureThreshold: 3日志收集方案对比方案优点缺点适用场景EFK功能全面资源消耗大需要复杂分析的场景Loki轻量级查询功能较弱容器环境日志聚合阿里云SLS开箱即用厂商锁定全托管需求最终选择LokiGrafana方案日均处理日志量达120GB成本比ELK降低62%。2.3 第三阶段流量治理2020Q1当服务数量超过30个时传统的硬编码服务调用方式已无法维护。我们引入服务网格架构时特别关注了以下几个核心指标熔断器配置优化// 使用Resilience4j配置订单服务调用 CircuitBreakerConfig.custom() .failureRateThreshold(50) // 50%失败率触发熔断 .waitDurationInOpenState(Duration.ofSeconds(30)) .ringBufferSizeInHalfOpenState(10) .ringBufferSizeInClosedState(100) .recordExceptions(TimeoutException.class, CallNotPermittedException.class) .build();全链路压测发现的问题商品详情页依赖链路过长最多达9次RPC调用未设置合理的超时传递底层1s超时导致上层5s堆积缓存未考虑地域分布华南用户频繁访问华北Redis解决方案实施接口聚合BFF层在Istio中配置全链路超时apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: product-service spec: hosts: - product http: - timeout: 1s route: - destination: host: product2.4 第四阶段数据架构升级2020Q3原有单MySQL实例已无法支撑日均2亿的订单流水我们实施了多层次的数据架构改造分库分表方案按用户ID哈希分片128个分片采用ShardingSphere中间件保留全局索引表用于跨分片查询实时数仓建设Flink SQL实时计算佣金 INSERT INTO commission_results SELECT user_id, order_id, amount * rate * 0.98 AS commission, -- 扣除2%平台服务费 CASE WHEN level VIP THEN amount * 0.02 ELSE 0 END AS extra_bonus FROM kafka_orders WHERE status SUCCESS;缓存策略优化本地缓存Caffeine Redis分布式缓存热点Key检测自动降级采用Redisson实现分布式锁3. 云原生关键技术实践3.1 可观测性体系构建我们建立了覆盖四个维度的监控体系指标监控Prometheus采集QPS、延迟、错误率自定义业务指标如佣金计算耗时链路追踪Jaeger实现微服务调用链可视化重点优化99线P99性能日志分析关键业务日志结构化JSON格式建立200条告警规则事件中心将K8s事件、业务事件统一管理实现关键操作审计追踪3.2 混沌工程实践通过定期故障注入测试系统韧性主要场景包括随机kill节点验证K8s自愈能力模拟区域网络中断测试多AZ部署可靠性数据库主从切换演练某次测试发现的典型问题2020-11-15 压测期间 - 佣金服务线程池打满从200调整到500 - Redis连接泄漏增加连接池监控 - 订单回调积压引入动态批量处理3.3 成本优化成果经过持续优化在流量增长3倍的情况下基础设施成本仅增加40%指标改造前当前优化幅度单订单计算成本0.021元0.009元-57%服务器利用率35%68%94%发布频率每周1次每日20次20x故障恢复时间47分钟2分18秒-95%4. 经验总结与避坑指南数据库迁移教训首次分库时未考虑join查询问题导致大量业务逻辑需要重写解决方案提前建立全局视图表逐步迁移查询逻辑配置管理陷阱某次误将生产环境配置推送到预发环境改进措施建立配置变更三重校验机制缓存一致性问题采用先更新数据库再删除缓存策略增加异步重试机制处理删除失败场景人员能力建设初期团队对K8s掌握不足导致多次误操作实施每周内部技术分享认证考试制度这套架构目前支撑着日均3亿的请求量在去年双11期间平稳度过了每秒8万订单的洪峰。回头看这段演进历程最重要的体会是云原生转型不仅是技术升级更需要配套的研发流程、团队能力和监控体系的全面进化。