企业官网建设流程全解析

医疗供应链管理系统这个项目，我在准备Java后端面试时反复打磨过，现在拿出来分享，是因为它几乎把微服务面试的高频考点都串了起来：服务拆分、分布式事务、库存并发、权限安全、幂等设计。光看标题你可能觉得它只是一个业务系统，但在面试官眼里，它是一个能同时考察你业务理解、架构能力和代码落地能力的完整样例。这篇文章不适合只想背八股的人，适合那些想要一个真实可讲、能层层追问、还能体现思考深度的项目的人。

1. 为什么拿医疗供应链管理系统作为面试实战项目

1.1 医疗供应链的业务场景与面试隐藏考点

医疗供应链和普通电商供应链最大的区别在于业务链条长、参与角色多、容错要求极高。一次采购下单，背后涉及供应商资质审核、采购计划、库存锁定、配送跟踪、结算对账，每一个环节都有独立的数据模型和状态机。作为面试项目，它的第一个优势就是能展示你对复杂业务的理解能力。

面试官问“你这个项目为什么这样拆分服务”时，如果你只说“按模块拆”，等于没回答。医疗供应链的天然边界非常清晰：供应商主数据、采购订单、库存、配送、结算、系统权限，每个业务域都有独立的生命周期和外部交互方。这些边界不是拍脑袋拍出来的，而是从业务实体和流程推导出来的。能把这个推导过程讲清楚，面试官就知道你不是只会照着Spring Cloud模板搭了一个空壳。

从技术角度看，这个项目天然包含高并发和一致性问题。采购入库会给库存增加，销售出库会扣减库存，而医院端对库存准确性极度敏感，不允许超卖也不允许账实不符。这个场景能引出分布式锁、乐观锁、Redis缓存、消息队列可靠投递、分布式事务等一串高频考点。可以说，一个合格的医疗供应链系统，几乎把微服务架构中所有难啃的骨头都包含了。

1.2 项目能体现的三大核心能力

第一是业务抽象能力。面试官不一定关心你用了什么框架，但他一定关心你能不能把“医疗机构采购一批耗材”这个模糊需求，拆成可落地的系统功能。你需要能画出订单、库存、结算之间的关系，能说清每个状态流转的触发条件，能处理异常回退。

第二是并发与一致性处理能力。医疗场景下，同一批药品可能同时被多个科室申请，库存不足时的处理策略、扣减库存的原子性、下游服务宕机后数据如何对齐，这些都是考察点。你如果能结合具体场景说清楚“我用了什么方案解决什么问题”，比背一百道面试题都管用。

第三是系统级设计能力。微服务不是拆分完就结束了，还要考虑服务注册发现、网关路由、熔断限流、链路追踪、定时对账。面试官最反感的是候选人把项目讲成CRUD流水账，而系统级设计能力恰好能让你从“会用框架”升级到“能设计系统”。

2. 系统整体设计与微服务拆分思路

2.1 按业务域拆分出的核心服务

我在设计时并没有一开始就铺开七八个服务，而是先从一个单机版的可运行系统出发，再根据业务边界逐步拆开。面试中你也可以采用这个策略，因为它能体现演进式架构的思想。

下面这个表格是我的推荐拆分方式，每个服务都可以对应到医疗供应链的一个真实业务域：

这个拆分的核心逻辑是“按业务变化频率和职责边界”来划分。供应商主数据的特点是低频变化但被多方引用，所以单独成服务；库存服务是高频写入且并发压力大，必须独立拆分且重点设计缓存；采购订单是流程中枢，它自己不长库存，只负责协调状态。如果把这些全塞进一个单体应用，表面上开发快，但后续每一次业务调整都可能互相影响，面试官追问“你的服务拆分依据是什么”时也会露怯。

2.2 技术选型与架构组件搭配

技术选型不需要堆砌“全家桶”，关键是每个组件都要能说出选择的理由。

基础框架围绕Spring生态展开：微服务注册与配置管理用一个开源注册中心组件，接口调用走声明式HTTP客户端，外部请求统一经过网关。这套组合是Java后端最常见的微服务落地方式，面试官熟悉，你也容易找到资料排查问题。

消息队列承担异步解耦和削峰填谷。在医疗供应链里，最常见的异步场景是采购订单审批通过后，需要通知库存服务预占库存，再通知结算服务生成应付单。这些操作不需要同步等待结果，但必须保证最终一致。我选择用消息队列把这些步骤串起来，关键交换机和队列做成持久化，消息消费端做幂等处理。

缓存用于处理库存热数据的查询。药品目录、实时库存这类接口的读取量远大于写入量，如果不加缓存，数据库在科室批量查询时会直接被打满。我采用本地缓存与分布式缓存配合的方式，热点冷门数据分开处理，同时缓存更新不追求强一致，而采用延迟双删和定期补偿。

网关、鉴权、异常处理、统一返回体这些横切逻辑不能散落在各个服务里。网关做路由和限流，鉴权在网关层统一处理，业务服务之间通过内部令牌传递身份信息。这一层做好之后，新增一个微服务不需要重复实现登录校验和参数校验，团队协作效率会高很多。

3. 关键模块实现与面试重点

3.1 采购下单链路：从订单到库存再到消息通知

采购下单是医疗供应链的核心流程，此接口一旦设计好，整个项目的脉络就清晰了。

下单接口的核心逻辑可以简化为：创建采购订单草稿，提交审批后调用库存服务锁定库存，锁定成功后再向消息队列发送事件，由结算服务和配送服务消费。这个流程不能写成单个服务内的大事务，因为库存服务和采购订单服务已经是两个独立进程，跨进程事务只能依靠分布式事务方案。

下面是一个简化版的下单接口核心代码，我用它来讲解流程控制：

@Transactional(rollbackFor = Exception.class) public PurchaseOrder createPurchaseOrder(CreateOrderRequest request) { // 1. 校验供应商资质 SupplierInfo supplier = supplierClient.getSupplierInfo(request.getSupplierId()); if (!supplier.valid()) { throw new BizException("供应商资质异常，无法创建采购订单"); } // 2. 创建订单主表，状态为待审核 PurchaseOrder order = new PurchaseOrder(); order.setSupplierId(request.getSupplierId()); order.setStatus(PurchaseOrderStatus.PENDING.getCode()); order.setTotalAmount(calcAmount(request.getItems())); purchaseOrderMapper.insert(order); // 3. 采购订单明细写入 List<PurchaseOrderItem> items = request.getItems().stream().map(i -> { PurchaseOrderItem item = new PurchaseOrderItem(); item.setOrderId(order.getId()); item.setProductId(i.getProductId()); item.setQuantity(i.getQuantity()); item.setPurchasePrice(i.getPurchasePrice()); return item; }).collect(Collectors.toList()); purchaseOrderItemMapper.batchInsert(items); // 4. 发送订单创建事件，后续审批完成后才锁库存 eventPublisher.publish(new PurchaseOrderCreatedEvent(order.getId())); return order; }

注意这个事务只负责本服务内的操作，不会跨服务锁库存。审批通过后由另一个方法发送“预占库存”请求。这个设计解释起来很顺畅，因为锁库存是资金级操作，订单状态没有审批通过前不应该对供应商库存产生影响。

3.2 库存扣减的并发控制与幂等设计

库存扣减最怕超卖。医疗场景下，如果系统显示有货但实际没货，耽误的是临床使用，所以我对库存操作极其谨慎。

我采用的是“Redis预扣减 + 数据库乐观锁兜底”的双层方案。先说明为什么不用纯数据库行锁：当科室并发申请时，数据库行锁会串行化所有请求，性能很差；而Redis扣减是单线程原子操作，能扛住瞬时高并发。但Redis不是可靠存储，一旦服务宕机或缓存丢失，数据就会不一致，所以最终库存和流水一定要落到数据库，并且用乐观锁防止数据库层面的并发覆盖。

库存扣减服务上的核心代码大致是这样：

@Component public class StockDeductHandler { private static final String STOCK_KEY_PREFIX = "stock:product:"; public boolean tryDeductStock(Long productId, Integer quantity) { String stockKey = STOCK_KEY_PREFIX + productId; // 基于Redis原子递减，避免超卖 Long remain = redisTemplate.opsForValue() .increment(stockKey, -quantity); if (remain != null && remain >= 0) { // 预扣成功，落库并记录流水 stockMapper.deductionWithVersion(productId, quantity); return true; } // 预扣失败，回补刚才扣减的数量 redisTemplate.opsForValue().increment(stockKey, quantity); return false; } }

数据库层的扣减语句需要带上版本号，防止两个线程同时读到同一个库存快照：

UPDATE stock_info SET available_quantity = available_quantity - #{quantity}, version = version + 1 WHERE product_id = #{productId} AND available_quantity >= #{quantity} AND version = #{version}

这里还要重点处理幂等。下游服务重试扣减请求时，不能把库存重复扣了。我引入了全局流水号，订单服务生成唯一的业务流水号，库存服务在流水表里以该流水号做唯一索引。第二笔相同流水号请求进来时，数据库唯一索引直接拦截，库存服务返回上一次处理结果。面试官问到“消息重复消费怎么办”时，这个设计是可以直接复用的答案。

3.3 基于消息队列的最终一致性方案

采购订单审批完成后，下游需要做三件事：库存锁定、结算单生成、配送单创建。这三件事允许有几个秒的延迟，但不允许丢失。如果同步调用，任何一个下游耗时过长，都会拖累采购订单接口。

我采用消息队列做最终一致性，核心思路是“把业务事件作为消息，消费者执行本地任务并回执”。

下单审批通过时，采购订单服务向消息队列发送“采购单已审批”的消息。库存服务监听该消息后，锁库存并回写一条处理记录。结算服务也在监听，如果发现库存锁定成功，则生成应付单。为了让失败可以追溯，我增加了一张消息记录表，记录每条消息的发送状态、消费状态、重试次数。定时任务扫描长期未完成的消息，手工或自动触发补偿。

这个方案有一个关键点：消费者处理消息时，必须保证本地事务和消费状态记录在同一个数据库事务里。如果消费者先执行业务操作再记录消息已消费，两步之间应用宕机，这条消息会被重复消费，但因为没有幂等保护，就可能导致重复锁库存。因此消费端的伪代码应该这样写：

@Transactional(rollbackFor = Exception.class) public void consumeOrderApprovedEvent(ApprovedEvent event) { // 先检查业务流水号是否已经处理过 if (eventProcessMapper.exists(event.getProcessId())) { return; } // 执行库存锁定 stockDeductHandler.tryDeductStock(event.getProductId(), event.getQuantity()); // 记录消费状态 eventProcessMapper.insert(event.getProcessId(), event.getType()); }

这种基于唯一业务键的幂等消费，是消息队列实践中最容易踩坑也最容易拿分的地方。我在面试中如果被问到“消息不丢失怎么保证”，就会把发送方确认、队列持久化、消费者幂等处理这个链路完整讲一遍。

4. 面试官常考的技术纵深问题

4.1 微服务之间的通信可靠性如何保证

面试官通常不会只让你介绍业务，而是会沿着你的实现继续往里挖。我整理了几个高频追问。

第一个问题是“服务之间调用如果超时怎么办”。不能简单回答“设置长超时”。采购订单服务调用库存服务时，如果库存服务响应慢，你不能无限等待。我一般会设置连接超时与读超时两个参数，连接超时控制在1秒以内，读超时控制在3秒内，并配备重试机制。但重试必须幂等，所以每次请求都携带全局流水号，对方根据流水号判断是否已经执行过。

第二个问题是“如何保证服务间数据最终一致”。你如果只回答“用了消息队列”，面试官会继续问消息丢了怎么办、重复怎么办、顺序怎么办。应对方法是把消息的确认机制讲清楚：发送方使用发送确认，确保消息到达消息队列；消费方处理成功后手动确认，失败则进入重试队列；重试达到上限后进入死信队列，由人工补偿机制处理。同时所有消费者都必须做幂等，这是最终一致性方案的基础。

第三个问题是“服务下线或宕机如何感知”。这要求你对注册中心机制有一定了解。服务启动时向注册中心注册自己的实例，消费者从注册中心拉取服务列表做负载均衡。服务下线会发送删除通知，但为了应对节点意外宕机，注册中心还需要有健康检查机制，定期探测心跳，长时间未响应则从实例列表剔除。这部分回答得越具体，越能证明你不是只搭过Demo。

4.2 缓存与数据库一致性、分布式锁的细节

“库存服务用了Redis后，Redis和MySQL数据不一致怎么办”是必问题。我的处理策略是所有库存写入先更新数据库，再删除缓存，下次读取时回填数据库最新值。如果更新数据库成功但删除缓存失败，需要依赖延迟双删：先删除缓存，等待几百毫秒，再删除一次，避免并发期间旧数据把缓存覆盖。

如果库存服务需要做分布式锁，我会比较Redis分布式锁和数据库锁的取舍。锁必须设置过期时间，防止持有锁的节点宕机导致死锁；过期时间又导致锁提前释放而临界区还没执行完，所以我倾向于使用带续期的分布式锁实现。更稳妥的方式是引入Redlock算法，但在实际部署时单机Redis已经能满足大部分场景，不会为了炫技故意引入过于复杂的方案。面试中你需要用一句话总结：分布式锁不是银弹，能用数据库唯一约束解决的，就不需要引入额外中间件。

缓存穿透也是医疗供应链里容易遇到的问题。药品详情是热点数据，如果某个药品ID不存在，恶意请求或异常调用会一直穿透Redis打到数据库。我的方案是缓存空值并设置较短过期时间，布隆过滤器也可以作为前置拦截，不过对于单个服务来说，空值缓存成本最低、最容易落地。

4.3 高可用与稳定性设计

医疗供应链系统虽然是内部系统，但峰值流量同样不可小觑。月末集中结算时，结算服务和报表导出接口很容易被打满。我在项目里做了三类稳定性设计：

限流：网关层按接口路径配置令牌桶限流，采购单创建接口设置单机每秒最大请求数，超出的请求直接返回友好提示，而不是让业务代码崩溃。

降级：库存查询接口依赖Redis，如果Redis不可用，服务不能直接报错。我配置了降级规则，允许返回部分缓存旧数据，或者在极端情况下查询数据库主库。重要的是面试官问“降级和熔断的区别”时，你要能说得清：降级是主动放弃非核心功能，熔断是当下游连续失败达到阈值后自动断开调用。

幂等与重试：接口层统一处理重复请求，业务层对于关键写操作（下单、支付、库存扣减）全部使用业务流水号做幂等控制。重试策略现在变得可审计，每次重试都记录重试次数和耗时，避免“盲目重试反而加重下游压力”。

5. 实战落地步骤与项目搭建记录

5.1 项目目录结构与初始化过程

如果你也想完整复现，我的建议是先搭一个多模块Maven工程，而不是把所有代码放在一个服务里。下面是简化后的目录结构：

medical-supply-chain ├── gateway-server ├── auth-service ├── supplier-service ├── order-service ├── inventory-service ├── delivery-service ├── settlement-service └── common-module

common-module用来放统一返回体、全局异常、工具类和公共DTO，其他服务都依赖它。初始化时先搭建网关、认证服务和注册中心，然后按业务优先级依次落地。我在搭建库存服务前会先把订单服务的数据库表结构想清楚，因为采购订单、库存流水和结算单之间共享了很多字段。

配置管理上，每个服务的配置文件会拆成application.yml和bootstrap.yml。bootstrap.yml负责从配置中心拉取远程配置，application.yml只放本地必需的配置。这样生产环境需要调整线程池参数或应急开关时，不需要重新发布服务，只要修改配置中心并触发刷新即可。

5.2 核心接口实现与调试记录

实际开发中，我踩得最多的坑是“事务只在自己的服务内生效”。在订单服务的本地事务里，直接调用库存服务的远程接口，如果库存服务扣减成功但订单服务后续SQL异常，订单会回滚，而库存已经扣了。很多候选人会在这里犯糊涂，以为把远程调用放到@Transactional里就有分布式事务效果，其实完全无效。

解决方法是避免跨服务远程调用直接嵌入本地事务。正确顺序是：先完成本地所有写操作，然后发送领域事件，后续通过消息队列异步处理。这样订单服务本地事务只处理订单本身，不携带外部系统状态。如果真的需要同步调用库存服务，那就要考虑引入分布式事务方案，而不是单纯依赖本地事务。

调试时我习惯先用curl调通本地启动的三个服务：

curl -X POST "http://localhost:8080/api/order/create" \ -H "Authorization: Bearer {token}" \ -H "Content-Type: application/json" \ -d '{"supplierId":"SUP001","items":[{"productId":"P001","quantity":100,"price":12.5}]}'

返回订单号和总金额后，再去库存服务查库存流水，确认是否产生了预占记录。整个链路联调比单独调每个接口更能发现问题，比如网关路由规则配置错误、消息队列topic名称不一致，这些都会在第一次完整流程跑到一半时暴露。

5.3 面试前如何把这个项目讲成有深度的故事

很多开发者项目做得不错，但面试时只会说“我这个项目用了Spring Cloud，有订单和库存等模块”，这样的描述一点冲击力都没有。我建议按下面的顺序组织你的项目讲述：

• 第一步说背景：医疗供应链系统面向什么用户，解决什么问题。比如“医院采购耗材需要跨多个科室审批，线下流程慢且对账困难”。
• 第二步说职责：我在项目中负责订单和库存两个核心服务的设计与实现。
• 第三步说难点：库存数据一致性和高并发扣减是项目中最难的部分。
• 第四步说方案：Redis预扣减、数据库乐观锁、消息队列最终一致、幂等控制。
• 第五步说结果：系统支持了每秒数百次下单调用而不出现超卖，采购订单从创建到审批再到库存锁定实现全链路可追踪。

讲的时候不要把代码背一遍，而是要说清楚你在选择方案时进行了哪些取舍。面试官想听的不是“我会用Redis”，而是“为什么这里用Redis而不用数据库锁”“这个方案的边界在哪”。

6. 常见问题与排查技巧实录

6.1 分布式事务一致性问题的排查思路

最终一致性方案上线后，最怕出现“数据库库存已经扣了，但订单还是待审核”这类不一致。我的排查步骤是：先查消息记录表，看采购单审批事件是否发送成功；然后查消费记录表，看库存服务有没有消费过该消息。如果消息没消费，查看消费日志和死信队列。如果消费了但数据库没变化，重点看消费方法是否有本地事务控制，有没有把回执状态和业务操作放到同一事务。

为了加速排查，我特意在关键表中加了trace_id，从订单创建开始，所有日志和流水都带上同一个追踪标识。查问题时只要拿到一个订单号，就能把链路日志串起来。这个方法成本极低，收益极高，面试时也是一大亮点。

6.2 接口变慢和缓存失效场景排查

网关限流和缓存穿透都比较容易通过监控发现，但“缓存生效期间接口还是慢”最让人头疼。我遇到过的情况是热点药品被大量查询，每个请求都穿透到数据库，数据库连接池被打满。原因是缓存过期时间没设随机值，同一时刻所有药品缓存同时失效。

解决办法是把药品详情缓存的过期时间设为基础值加上随机偏移量，避免缓存雪崩。同时数据库连接池的超时时间不能小于网关读超时时间，否则网关侧先超时返回，数据库连接还在后台慢慢执行，积压后会形成恶性循环。

6.3 面试中容易暴露的细节坑

这里整理一个速查表，都是我自己在模拟面试里见过候选人翻车的地方：

这些坑不一定只在项目上线时出现，面试官只要追问一两个细节，你的基础扎不扎实马上就能看出来。所以如果你准备用这个项目面试，一定要把上面这些细节全部动手跑一遍，而不是只在文档里画架构图。

7. 最后再分享一点个人体会

我见过很多候选人拿着一堆热门项目名称，却没有一个能深挖超过十分钟。医疗供应链管理系统真正有价值的，不是用了微服务，而是你能通过它展示“在复杂业务里如何做取舍”。每次面试被问到库存扣减方案时，我都会先说业务诉求，再讲技术实现，最后补充对账和兜底策略。这种“业务-方案-补偿”的表达结构，面试官听起来很舒服，也能看出你是真的在解决问题，而不是堆名词。

如果你准备时间有限，建议优先把采购审批、库存锁定、消息最终一致这条主链路打通，把核心的代码逻辑、异常场景、排查思路全部吃透，再考虑扩展配送和结算服务。这个项目可以作为你简历上的亮点，也可以作为你面试时主动展开的纵深话题。把它拆开揉碎之后，你会发现很多看似高深的微服务问题，其实都源于一个简单的业务需求：不能让库存算错。