电商平台架构设计案例实战复盘：经验总结

在数字化转型浪潮中，医疗健康行业正经历着深刻的变革。传统的线下服务模式已难以满足日益增长的线上问诊、药品购买、健康管理等需求。本文将以一个真实的医疗健康类电商平台（我们称之为“康健云购”）的架构设计与演进实战为例，复盘其从0到1，再到应对千万级营销活动洪峰的全过程。我们将深入剖析其技术架构选型、核心模块设计，并重点复盘一次经典的“家庭常备药箱”主题营销活动的技术保障经验，旨在为同行提供兼具专业性与实用性的参考。

一、项目背景与核心挑战

“康健云购”平台旨在整合在线问诊、处方流转、药品及医疗器械电商、健康科普等功能于一体。其业务复杂性远高于普通电商平台，主要面临以下核心挑战：

业务合规性要求极高： 涉及处方药销售，必须严格遵循“网订店取”、“网订店送”等政策，实现处方真实、可追溯。
系统复杂性： 融合了电商交易、在线医疗（音视频问诊）、内容社区等多种业态，子系统间耦合与数据一致性要求高。
数据敏感性： 用户健康信息、电子处方等属于敏感数据，对安全、隐私保护的要求达到金融级。
流量波动剧烈： 日常流量平稳，但营销活动或季节性流行病高发期，流量可能瞬间暴涨数十倍，系统需具备卓越的弹性伸缩能力。

二、整体架构设计与技术选型

基于上述挑战，我们采用了“微服务 + 领域驱动设计（DDD）”作为核心架构思想，将系统解耦为高内聚、低耦合的独立服务。

2.1 分层架构概览

接入层： 使用 Nginx 进行负载均衡和静态资源分发，并通过 API Gateway（采用 Spring Cloud Gateway）实现统一入口、鉴权、限流和路由。
业务服务层： 核心微服务集群，包括：用户中心、问诊服务、药品目录服务、订单服务、处方服务、支付服务、库存服务等。每个服务独立数据库，使用 Spring Boot 开发。
数据层： 根据数据特性选用不同数据库。核心交易数据用 MySQL（分库分表），药品目录等读多写少数据用 Redis 缓存+MySQL，日志和行为数据用 Elasticsearch，图谱关系（如药品配伍禁忌）用 Neo4j。
支撑组件层： 服务注册与发现（Nacos），配置中心（Nacos Config），分布式事务（Seata AT模式），消息队列（RocketMQ），链路追踪（SkyWalking）。

2.2 关键设计：处方与订单的最终一致性

处方审核通过后，才能生成对应订单。这是一个典型的分布式事务场景。我们采用“可靠消息 + 最终一致性”方案，通过 RocketMQ 的事务消息来保证。

// 伪代码示例：处方审核通过后发送事务消息
@Transactional
public void approvePrescription(String prescriptionId) {
    // 1. 更新处方状态为“已审核”
    prescriptionService.updateStatus(prescriptionId, Status.APPROVED);
    
    // 2. 准备订单创建所需数据（PrescriptionOrderEvent）
    PrescriptionOrderEvent event = buildEvent(prescriptionId);
    
    // 3. 发送半事务消息到RocketMQ
    TransactionSendResult sendResult = rocketMQTemplate.sendMessageInTransaction(
        "prescription-topic",
        MessageBuilder.withPayload(event).build(),
        prescriptionId // 业务参数，用于回查
    );
    
    // 4. 本地事务提交（包含1和2的数据持久化）
}

// 事务监听器：执行本地事务
@RocketMQTransactionListener
class PrescriptionTransactionListenerImpl implements RocketMQLocalTransactionListener {
    @Override
    public RocketMQLocalTransactionState executeLocalTransaction(Message msg, Object arg) {
        try {
            // 检查本地处方状态是否已更新为APPROVED
            String prescriptionId = (String) arg;
            if(prescriptionService.isApproved(prescriptionId)) {
                return RocketMQLocalTransactionState.COMMIT; // 提交消息
            }
            return RocketMQLocalTransactionState.ROLLBACK;
        } catch (Exception e) {
            return RocketMQLocalTransactionState.ROLLBACK;
        }
    }
    
    @Override
    public RocketMQLocalTransactionState checkLocalTransaction(Message msg) {
        // 回查逻辑，同上
    }
}

// 订单服务：消费消息，创建订单
@RocketMQMessageListener(topic = "prescription-topic", consumerGroup = "order-group")
public class OrderCreationConsumer implements RocketMQListener {
    @Override
    public void onMessage(PrescriptionOrderEvent event) {
        orderService.createOrderFromPrescription(event);
    }
}

三、营销活动经典案例复盘：“家庭常备药箱”大促

本次营销活动通过组合销售感冒、发烧、肠胃、外伤等常用非处方药及器械，主打“一站式备齐，健康无忧”概念。活动上线1小时内，访问量达到平日峰值的50倍。

3.1 活动技术保障策略

流量预估与扩容： 基于历史数据和活动力度，预估峰值QPS为10万。我们提前对核心链路（商品详情页、购物车、下单）进行全链路压测，并基于压测结果，在云平台上对相关服务（尤其是网关、商品、库存、订单）进行水平扩容，实例数增加至平时的5倍。
缓存设计升级：
- 商品信息： 活动商品详情页完全静态化，上传至CDN。动态部分（如库存、价格）通过Ajax异步加载，并采用 Redis 缓存，缓存时间缩短至5秒，保证强时效性。
- 库存预热与扣减： 活动库存提前预热至Redis。采用 Redis Lua脚本 保证扣减的原子性，防止超卖。

-- Redis Lua 脚本：原子化扣减库存
local key = KEYS[1] -- 商品库存Key，如 'stock:item:1001'
local change = tonumber(ARGV[1]) -- 扣减数量，负数为扣减
local current = redis.call('GET', key)
if (not current) then
    return -1 -- 库存Key不存在
end
current = tonumber(current)
if (current + change < 0) then
    return -2 -- 库存不足
end
redis.call('INCRBY', key, change)
return current + change -- 返回扣减后的库存

异步化与削峰填谷：
- 下单流程： 将“创建订单”与“扣减库存”、“生成支付单”等后续操作解耦。用户点击下单后，系统快速校验库存并生成一个“待处理订单”记录到数据库，同时向 RocketMQ 发送一个延时消息。订单服务异步消费此消息，完成后续复杂的业务处理。前端通过轮询或WebSocket获取最终状态。
- 积分发放、短信通知等非核心操作全部异步化。
限流与降级：
- 在API Gateway层对非关键接口（如商品评价列表、推荐算法）配置熔断降级策略，在系统压力大时直接返回兜底数据或简短提示。
- 对核心的“提交订单”接口，根据服务能力在网关层设置精准的QPS限流，超出部分友好提示“系统繁忙，请稍后重试”。

3.2 遇到的坑与解决方案

问题： 活动开始瞬间，商品详情页的“库存查询”接口（异步加载）调用量激增，虽然Redis能扛住，但与之关联的“药品详情服务”数据库连接池被占满，导致服务短暂不可用。
根因： “库存查询”接口逻辑中，除了读Redis库存，还同步查询了数据库中的商品上下架状态和部分动态属性，造成了数据库压力。
解决方案：

短期应急： 立即扩容“药品详情服务”的数据库连接数，并重启服务恢复。
长期修复： 重构该接口，将商品状态等变更频率低的信息也缓存至Redis，与库存一起返回。数据库查询改为“旁路”更新，即管理员在后台修改商品状态时，同步更新Redis缓存。接口逻辑简化为纯Redis操作。

四、医疗行业特殊性的架构应对

除了通用电商架构，医疗特性带来了独特的设计考量。

隐私数据脱敏： 在日志系统（ELK）、监控系统等环节，对所有用户ID、姓名、处方内容等字段进行强制脱敏。在服务间内部调用传递敏感对象时，也使用脱敏后的DTO。
处方合规链： 利用区块链的不可篡改特性（采用联盟链），将处方的关键操作（开具、审核、调剂、核销）哈希值上链存证，实现全流程可追溯、可审计。
多租户与数据隔离： 平台接入多家线下药房。在数据库设计上，采用“逻辑隔离”（在关键表中增加 pharmacy_id 字段，所有查询强制带此条件）与“物理隔离”（核心业务数据按药房分库）相结合的方式，确保数据安全与合规。