适用项目：线上商品的销售与运营平台
复习状态：已复习 8 次 (2026-05-21T16:57:51)
微服务架构是一种将复杂业务系统按照业务能力拆分为多个小型自治服务的架构方式，每个服务可以独立开发、独立部署、独立扩展，并通过轻量级接口或消息机制完成协作。线上商品销售与运营平台涉及商品管理、库存扣减、订单交易、支付结算、优惠营销、运营配置、数据统计等多个业务域，如果采用单体架构，后期会出现代码耦合严重、发布风险高、促销高峰扩容困难等问题。因此，在本项目中，我采用 Spring Boot 和 Spring Cloud Alibaba 构建微服务体系，使用 Nacos 进行服务注册与配置管理，使用 Spring Cloud Gateway 作为统一入口，使用 Docker 和 Kubernetes 进行容器化部署。通过微服务架构，本平台能够支撑约 18 万个 SKU 的日常运营、日均 3 万笔订单处理，并在促销活动期间按业务压力对核心服务进行独立扩容。
首先，我按照业务边界对系统进行了微服务拆分。项目中我没有简单按照表现层、业务层、数据层进行技术拆分，而是按照线上销售平台的核心业务能力，将系统拆分为用户服务、商品服务、库存服务、订单服务、支付服务、营销服务、运营管理服务和数据统计服务。商品服务负责 SPU、SKU、类目、品牌、价格和上下架管理，库存服务负责库存锁定、扣减、回滚和库存预警，订单服务负责购物车提交、订单生成、订单状态流转和售后入口，营销服务负责优惠券、满减、限时折扣和秒杀活动配置。每个服务维护自己的数据库表，并通过接口对外提供能力。例如，运营人员调整满减规则时，只需要修改营销服务和运营管理服务，不需要重新发布订单服务和支付服务。采用这种按业务能力拆分的方法后，实现了商品、订单、营销等功能的独立迭代，常规需求发布周期由原来的约 10 天缩短到 3 到 5 天，核心交易服务的变更风险也明显降低。
其次，我重点设计了微服务之间的通信和数据一致性处理机制。对于商品详情查询、订单详情查询、用户登录校验等实时性要求较高的场景，我采用 Gateway 转发请求，并通过 OpenFeign 调用各服务提供的 REST 接口；对于订单创建后的库存锁定、优惠券核销、支付结果通知、运营数据采集等不要求同步完成的场景，我采用 RocketMQ 进行异步解耦。具体来说，用户提交订单后，订单服务先生成待支付订单，再发送库存锁定消息；库存服务消费消息后锁定对应 SKU 库存，并将处理结果回传给订单服务；用户支付成功后，支付服务发送支付成功事件，订单服务更新订单状态，营销服务完成优惠券核销，数据统计服务异步记录交易明细。对于重复回调和消息重复消费，我在订单服务和库存服务中增加了业务流水号和幂等校验表，避免重复扣减库存。采用“同步接口 + 异步消息 + 幂等控制”的方法后，实现了订单、库存、优惠券和支付状态的最终一致，在压测中可以稳定处理每分钟约 6000 条订单相关消息，库存超卖问题控制为 0 次。
最后，我在微服务部署和治理方面做了具体设计，以保证平台在高并发场景下的可用性。项目中各服务均打包为 Docker 镜像并部署到 Kubernetes 集群，商品服务、订单服务、库存服务和支付服务作为核心服务配置了独立的副本数量和自动扩缩容策略。平时商品服务部署 4 个实例、订单服务部署 3 个实例、库存服务部署 3 个实例；在大促活动期间，根据 CPU 使用率和接口 QPS 进行水平扩容，商品服务最多扩展到 12 个实例，订单服务扩展到 10 个实例，库存服务扩展到 8 个实例。同时，我通过 Gateway 实现统一鉴权、限流和路由，通过 Sentinel 对秒杀下单、优惠券领取等热点接口设置限流阈值，并通过 Prometheus 和 Grafana 监控接口耗时、错误率和服务实例状态。当支付服务或营销服务短时间异常时，订单服务会进入降级流程，先保留订单和待补偿任务，避免主交易链路整体失败。采用容器化部署、服务注册、限流熔断和监控告警等方法后，平台在促销压测中可以支撑约 2500 QPS 的商品查询请求和每分钟约 1800 笔订单创建请求，核心接口 95% 响应时间控制在 800 毫秒以内。