面试题：复杂业务场景下微服务架构弹性伸缩的优化设计

Question

假设存在一个电商系统，包含商品展示、下单、支付等多个微服务，且业务流量具有明显的峰值和谷值，例如促销活动期间流量大幅增长。请设计一套弹性伸缩方案，不仅要考虑到资源的合理利用，还要兼顾系统的稳定性、数据一致性以及成本控制，并详细阐述设计思路和关键技术点。

Answer 1

设计思路

1. 资源合理利用：在流量低谷时，减少资源以降低成本；在流量高峰时，增加资源以满足需求。
2. 系统稳定性：确保伸缩过程中服务不中断，数据处理准确无误。
3. 数据一致性：保证订单、支付等关键数据在伸缩过程中的一致性。
4. 成本控制：通过自动化伸缩，仅在必要时使用资源，避免资源浪费。

关键技术点

1. 监控与预警：
   • 使用 Prometheus、Grafana 等工具监控微服务的各项指标，如 CPU 使用率、内存使用率、请求响应时间、每秒请求数等。
   • 设定合理的阈值，当指标超过阈值时，通过 Alertmanager 发送预警信息到相关人员。
2. 自动化伸缩：
   • 基于 Kubernetes：
     • 使用 Horizontal Pod Autoscaler（HPA）根据 CPU 使用率或请求数自动调整 Pod 的副本数量。例如，在促销活动前，手动设置 HPA 的目标 CPU 使用率为 80%，当 CPU 使用率超过 80%时，自动增加 Pod 副本；低于 60%时，减少副本。
     • 配置 Vertical Pod Autoscaler（VPA）来动态调整 Pod 的资源请求和限制，以适应不同的负载情况，避免资源过度分配或不足。
   • 云服务提供商的自动伸缩功能：如 AWS 的 Auto Scaling Group，根据 CloudWatch 监控的指标自动调整 EC2 实例数量。可以配置多个伸缩策略，如基于时间的策略（在促销活动时间段提前增加实例）和基于指标的策略（根据负载实时调整）。
3. 负载均衡：
   • Kubernetes 内部：使用 Service（如 ClusterIP、NodePort、LoadBalancer 类型）来实现 Pod 之间的负载均衡。对于外部流量，LoadBalancer 类型的 Service 可以将流量均匀分配到各个 Pod。
   • 外部负载均衡器：如 Nginx、HAProxy 等，将外部请求均匀分配到不同的微服务实例上。可以配置会话粘性（sticky session），确保同一用户的请求始终路由到同一个实例，以维持状态一致性，特别是在处理购物车、用户登录等场景时。
4. 数据一致性：
   • 数据库层面：
     • 使用分布式数据库如 Cassandra、MongoDB 等，它们具有自动分片和复制功能，能够在节点增加或减少时保证数据的可用性和一致性。对于关系型数据库，如 MySQL，可以采用主从复制 + 读写分离架构，主库负责写操作，从库负责读操作，在伸缩过程中通过合理的切换机制保证数据同步。
     • 利用分布式事务框架，如 Seata，来保证跨微服务操作（如下单和库存扣减）的数据一致性。Seata 提供 AT、TCC、SAGA 等模式，可以根据业务场景选择合适的模式。
   • 缓存层面：使用 Redis 作为缓存，采用分布式缓存架构，如 Redis Cluster。在伸缩过程中，通过缓存更新策略（如读写时更新、异步更新等）保证缓存与数据库数据的一致性。对于一些关键数据，可以设置较短的缓存过期时间，以尽快从数据库获取最新数据。
5. 服务治理：
   • 使用 Service Mesh：如 Istio，实现服务间的流量管理、故障注入、熔断、限流等功能。在伸缩过程中，通过 Istio 的流量控制，可以防止新启动的实例因瞬间大量请求而崩溃，同时保证系统整体的稳定性。例如，设置限流策略，每个实例每秒最多处理 100 个请求。
   • 配置中心：使用 Apollo、Nacos 等配置中心，统一管理微服务的配置。在伸缩过程中，新启动的实例可以从配置中心获取最新的配置信息，保证服务的正常运行。同时，配置中心可以实现配置的动态更新，无需重启服务即可生效。