面试题：特定业务场景下微服务架构弹性伸缩与资源利用率的深度优化

Question

给定一个电商促销活动场景，每秒请求量在活动开始瞬间可能会从 1000 突增至 100000，活动持续 2 小时后逐渐恢复正常。该电商系统采用微服务架构，包含用户服务、订单服务、库存服务等多个微服务。请详细阐述针对这个场景，如何设计一套精准且高效的弹性伸缩方案以优化资源利用率，同时要考虑到不同微服务之间的依赖关系以及数据一致性问题，并且说明方案实施过程中可能遇到的挑战及应对措施。

Answer 1

弹性伸缩方案设计

1. 基于指标的自动伸缩
   • CPU、内存指标：设置 CPU 使用率和内存使用率作为主要伸缩指标。例如，当 CPU 使用率连续 5 分钟超过 80% 时，增加实例；当连续 5 分钟低于 30% 时，减少实例。在活动开始瞬间，由于请求量剧增，各微服务的 CPU 和内存使用会迅速上升，触发实例增加。
   • 请求队列长度：对于请求处理，设置请求队列长度作为辅助指标。若订单服务的请求队列长度超过 1000，意味着处理速度跟不上请求速度，此时增加订单服务实例。
2. 分阶段伸缩策略
   • 预热阶段：在活动开始前 15 分钟，根据预估的流量增长情况，手动预先增加各微服务实例。例如，将用户服务、订单服务、库存服务实例数分别增加 2 - 3 倍，提前做好资源准备。
   • 活动阶段：活动开始瞬间，以更短的监控周期（如 1 分钟）监控伸缩指标，快速响应流量变化。根据实际流量，按比例增加各微服务实例。比如，订单服务流量增长 100 倍，实例数也相应按比例增加。
   • 冷却阶段：活动结束后，以较长的监控周期（如 15 分钟）逐渐减少实例，避免资源释放过快导致服务不稳定。
3. 考虑微服务依赖关系
   • 确定依赖顺序：库存服务依赖于用户服务（检查用户权限等），订单服务依赖于库存服务（检查库存是否充足）和用户服务（获取用户信息）。在伸缩时，优先保证上游微服务有足够资源，例如先增加用户服务实例，再增加库存服务实例，最后增加订单服务实例。
   • 级联伸缩：当某个微服务因流量增加而进行伸缩时，检查其下游微服务的负载情况。若订单服务因流量增加而扩容，同时检查库存服务的负载，若负载上升接近阈值，也对库存服务进行扩容。

数据一致性保障

1. 分布式事务处理
   • 采用 TCC（Try - Confirm - Cancel）模式：在订单创建场景中，订单服务先 Try 预留库存（调用库存服务的 Try 接口），如果所有 Try 操作成功，再 Confirm 提交订单和扣减库存；若有任何一个 Try 失败，执行 Cancel 操作回滚所有已执行的 Try 操作。
2. 消息队列与最终一致性
   • 使用消息队列（如 Kafka）：订单创建成功后，发送消息到消息队列，库存服务从消息队列消费消息进行库存扣减。即使库存服务暂时不可用，消息也不会丢失，待其恢复后继续处理，保证最终数据一致性。

方案实施挑战及应对措施

1. 网络延迟与通信故障
   • 挑战：在伸缩过程中，新实例加入或旧实例移除时，可能出现网络延迟或通信故障，影响微服务间的调用。
   • 应对措施：采用重试机制，如订单服务调用库存服务失败时，进行 3 次重试，每次重试间隔 1 秒。同时，使用断路器模式（如 Hystrix），当失败次数达到一定阈值，断路器打开，暂时不再调用故障服务，防止级联故障。
2. 数据缓存不一致
   • 挑战：在实例伸缩过程中，缓存中的数据可能与数据库不一致，例如库存缓存与实际库存数据。
   • 应对措施：采用缓存更新策略，如在数据更新时，先更新数据库，再删除缓存。同时，设置缓存过期时间，定期从数据库重新加载数据，保证缓存数据的一致性。
3. 资源分配不均衡
   • 挑战：可能出现部分微服务资源过度分配，而部分微服务资源不足的情况。
   • 应对措施：实时监控各微服务的资源使用情况和流量变化，动态调整伸缩策略。例如，发现库存服务流量增长缓慢，而订单服务流量增长迅速，可适当减少库存服务的扩容比例，增加订单服务的扩容比例。