面试题-微服务
- 微服务的优缺点
-
- [springCloud 与dubbo的区别](#springCloud 与dubbo的区别)
- springCloud与springboot的关系
- 服务雪崩、熔断与降级解决方案解析
什么是微服务
微服务（Microservices）是一种软件架构风格，将一个大型应用程序划分为一组小型、自治且松耦合的服务。每个微服务负责执行特定的业务功能，并通过轻量级通信机制（如HTTP）相互协作。每个微服务可以独立开发、部署和扩展，使得应用程序更加灵活、可伸缩和可维护。
微服务带来了哪些挑战
-
系统复杂性增加：一个服务拆成了多个服务，整体系统的复杂性增加，需要处理服务之间的通信、部署、监控和维护等方面的复杂性。
-
服务间通信开销：微服务之间通过网络进行通信，传递数据需要额外的网络开销和序列化开销，可能导致性能瓶颈和增加系统延迟。
-
数据一致性和事务管理：每个微服务都有自己的数据存储，数据一致性和跨服务的事务管理变得更加复杂，需要额外解决分布式事务和数据同步的问题。
-
部署和运维复杂性：微服务架构涉及多个独立部署的服务，对于部署、监控和容错机制的要求更高，需要建立适当的部署管道和自动化工具，以简化部署和运维过程。
-
团队沟通和协作成本：每个微服务都由专门的团队负责，可能增加团队之间的沟通和协作成本。需要有效的沟通渠道和协作机制，确保服务之间的协调和一致性。
-
服务治理和版本管理：随着微服务数量的增加，服务的治理和版本管理变得更加复杂。需要考虑服务的注册发现、负载均衡、监控和故障处理等方面，以确保整个系统的可靠性和稳定性。
-
分布式系统的复杂性：微服务架构涉及构建和管理分布式系统，而分布式系统本身具有一些固有的挑战，如网络延迟、分布式一致性和容错性。
微服务的优缺点
springCloud 与dubbo的区别
？？？？？？？？？？？？？？？？？？？
springCloud与springboot的关系
服务雪崩、熔断与降级解决方案解析
一、服务雪崩定义与成因
服务雪崩指单个服务故障引发连锁反应，导致整个系统不可用的现象，常见于微服务架构中。核心成因包括：
服务提供者不可用（如硬件故障、代码缺陷、缓存击穿）
重试机制加剧流量（用户或代码重复请求）
资源耗尽（调用方因同步等待耗尽线程或连接）
二、核心解决方案
1. 服务熔断（Circuit Breaker）
作用：自动切断对故障服务的调用，防止故障扩散
实现逻辑：
触发条件：检测到单位时间内请求失败率超过阈值（如10秒内失败率≥50%）
熔断状态：开启后直接返回预设降级结果，不再发送真实请求
恢复机制：定期探测服务可用性（如每5秒），成功则关闭熔断
典型工具：Hystrix、Resilience4j、Polly（.NET Core）
2. 服务降级（Fallback）
作用：在服务不可用时返回替代响应，保障核心业务可用
场景与策略：
超时降级：设置合理超时时间（如2秒），超时后返回默认数据
资源不足降级：线程池或信号量满载时，直接执行本地降级逻辑
多级降级：依次尝试备用服务（如自建邮箱→网易邮箱→QQ邮箱）
实现方式：通过Feign+Hystrix定义@Fallback方法，或AOP切面注入降级逻辑
3. 服务限流（Rate Limiting）
目标：控制请求量，避免突发流量压垮系统
算法选择：
令牌桶算法：允许突发流量（如网关层限流）
漏桶算法：平滑流量峰值（如Nginx限流）
工具示例：Sentinel、Spring Cloud Gateway限流过滤器
4. 资源隔离
线程池隔离：为不同服务分配独立线程池，避免资源竞争
信号量隔离：限制并发请求数（适用于低延迟场景）
物理隔离：通过容器化或虚拟机隔离故障服务
5. 超时控制
配置原则：根据服务响应历史数据，设置略高于平均响应时间的阈值（如P99值+20%）
实现层级：
客户端超时：Ribbon/OpenFeign设置readTimeout
服务端超时：Tomcat/Nginx配置请求处理超时
6. 监控与预警
指标体系：监控QPS、RT、错误率、熔断状态等关键指标
工具链：
Prometheus+Grafana：实时可视化监控48
ELK（Elasticsearch+Logstash+Kibana）：日志分析与异常追踪
自动化响应：通过告警触发熔断或扩容操作（如Kubernetes自动伸缩）
三、方案关联与差异对比
四、实践建议
组合使用：熔断与降级需配合使用（熔断触发后执行降级逻辑）
渐进式优化：优先实施超时控制+限流，再逐步引入熔断与隔离
动态调参：根据业务高峰与低谷动态调整阈值（如电商大促期间降低熔断触发阈值）
全链路压测：通过模拟流量验证熔断降级策略的有效性