基本介绍
在微服务架构中，由于服务之间的相互依赖性，任何一个服务的故障或性能问题都可能导致整个系统的不稳定。因此，熔断、降级和限流是三种常见的技术手段，用于提高系统的可用性和稳定性。
熔断 (Circuit Breaker)
熔断机制的设计灵感来源于电路中的熔断器，用于防止过载或故障扩散，保护系统不受进一步的影响。当一个微服务出现问题，如响应时间过长或失败率过高时，熔断器会自动“断开”，阻止对该服务的进一步访问。熔断器断开后，后续的请求会直接失败，而不是继续调用下游服务。经过预定的时间后，熔断器会自动进入“半开”状态，尝试允许部分请求通过，并监控请求的成功率，如果请求成功率恢复到一定程度，熔断器会完全“闭合”，恢复服务调用。
降级 (Fallback)
降级策略是当下游服务因过载或故障导致无法正常响应时，上游服务可以自动降低服务质量，以保证核心服务的可用性。降级操作可以包括返回一个默认值、调用备用服务、限制某些功能的使用等。降级的目的是优先保证系统的整体可用性和稳定性，哪怕是以牺牲部分服务质量或功能为代价。
限流 (Rate Limiting)
限流是控制访问频率和并发量的一种手段，目的是防止服务因过度使用而过载。限流可以应用于API接口、服务间调用、数据流等多个层面。常见的限流策略包括令牌桶（Token Bucket）、漏桶（Leaky Bucket）等算法。通过限制请求的速率，可以确保服务在安全的负载范围内运行，即使在流量高峰期也能保持系统的稳定性。
总结
熔断：自动检测服务故障，暂时切断服务调用，防止故障扩散，类似于电路中的熔断器。降级：在服务出现问题时，主动降低服务质量（如返回默认响应），保证核心服务的可用性。限流：控制访问频率和并发量，防止服务因过度使用而过载，确保服务的稳定性。
这些技术手段通常在微服务架构中是相辅相成的，通过合理的设计和实现，可以显著提高分布式系统的弹性和稳定性。
熔断 (Circuit Breaker)
假设我们有一个电商应用，其中包括一个订单服务和一个支付服务。订单服务需要调用支付服务来处理支付请求。在高流量情况下，如果支付服务变得不稳定（例如，由于数据库问题或网络延迟），而订单服务继续不加限制地调用支付服务，那么不仅支付服务可能会完全崩溃，订单服务也可能因为大量积压的调用而变得缓慢或不可用。
为了防止这种情况，我们可以在订单服务中实现熔断机制。下面是一个简化的熔断机制示例，演示了如何在订单服务中调用支付服务时使用熔断器：
import com.netflix.hystrix.HystrixCommand;
import com.netflix.hystrix.HystrixCommandGroupKey;
public class PaymentServiceCommand extends HystrixCommand
private final String orderId;
public PaymentServiceCommand(String orderId) {
super(HystrixCommandGroupKey.Factory.asKey("PaymentServiceGroup"));
this.orderId = orderId;
}
@Override
protected String run() {
// 这里是调用支付服务的代码
// 模拟调用支付服务API
return "Payment processed for order " + orderId;
}
@Override
protected String getFallback() {
// 当熔断器打开或命令执行失败时，调用此回退方法
return "Fallback: Payment could not be processed for order " + orderId;
}
}
在这个示例中，PaymentServiceCommand 继承自 HystrixCommand，其中 run 方法包含调用支付服务的逻辑。如果支付服务调用成功，run 方法就会返回一个成功消息。如果调用失败（抛出异常），则自动触发 getFallback 方法，返回一个回退响应，告诉用户支付服务当前不可用。
熔断器的工作流程如下：
闭合状态（Closed）：熔断器默认状态，所有请求都会正常调用支付服务。打开状态（Open）：如果 run 方法中的错误率超过预定的阈值（例如，超过50%的请求失败），熔断器会转到打开状态。在这个状态下，所有对支付服务的调用都会直接失败，不会执行 run 方法，而是直接调用 getFallback 方法。这可以防止对已经不稳定的支付服务造成更多压力。半开状态（Half-Open）：经过一定时间后（例如，60秒），熔断器会自动进入半开状态，尝试允许一部分请求通过，并检查这些请求是否成功。如果这些请求成功，熔断器会判定支付服务已经恢复正常，然后关闭熔断器，恢复正常的请求流程。如果这些请求仍然失败，熔断器会再次打开，继续阻断请求。
通过这种方式，熔断器帮助我们防止了一次服务故障导致整个系统不稳定的情况，提高了系统的可用性和稳定性。
降级 (Fallback)
假设我们有一个视频分享平台，用户可以上传视频，平台会对视频进行处理（如转码、压缩等），然后其他用户可以观看。视频处理是一个资源密集型的任务，尤其是在高流量时期，可能会对系统造成很大压力。
为了确保平台的核心功能（视频观看）在资源紧张时仍能正常使用，我们可以实现一个降级策略：当视频处理服务过载时，系统会自动降级，即暂时停止对上传的视频进行处理，而是存储原始视频，并给上传者一个提示，说明视频将在系统负载较低时进行处理。
下面是一个简化的代码示例，演示了如何在视频上传功能中应用降级策略：
public class VideoUploadService {
public String uploadVideo(File video) {
if (isSystemOverloaded()) {
// 系统过载，执行降级策略
storeVideoWithoutProcessing(video);
return "Video uploaded successfully. It will be processed later due to high system load.";
} else {
// 系统正常，执行正常的视频处理逻辑
String processedVideo = processVideo(video);
return "Video uploaded and processed successfully: " + processedVideo;
}
}
private boolean isSystemOverloaded() {
// 检查系统负载，例如CPU使用率、内存使用率等
// 这里只是一个示例，实际情况可能更复杂
return getCurrentSystemLoad() > LOAD_THRESHOLD;
}
private void storeVideoWithoutProcessing(File video) {
// 存储视频，不进行处理
// 实际实现中会将视频保存到某个存储系统
}
private String processVideo(File video) {
// 视频处理逻辑，如转码、压缩等
// 返回处理后的视频信息
return "processedVideoInfo";
}
private double getCurrentSystemLoad() {
// 获取当前系统负载，如CPU、内存使用率
// 这里返回一个模拟值
return Math.random() * 100; // 假设100是最大负载
}
private static final double LOAD_THRESHOLD = 75.0; // 假设超过75%的系统负载就认为是过载
}
在这个示例中，uploadVideo 方法首先检查系统是否过载（通过 isSystemOverloaded 方法）。如果系统过载，就执行降级策略（storeVideoWithoutProcessing 方法），只是简单地存储视频而不进行处理，并返回给用户一个提示信息，告知他们视频将在系统负载降低后处理。如果系统未过载，则正常执行视频处理逻辑。
通过这种降级策略，即使在系统资源紧张时，用户仍然可以上传视频，而平台的核心功能（视频观看）也不会受到影响。这有助于提高用户体验和系统的整体稳定性。
限流 (Rate Limiting)
假设我们有一个在线电商平台，其中的商品详情页面在大型促销活动期间会吸引大量用户访问。为了防止服务器因为突然增加的流量而崩溃，我们可以实现一个限流策略，确保系统在任何时间点都不会超过其处理能力。
示例场景
在商品详情页面，除了展示商品信息外，还可能有一些额外的服务，比如显示用户评论、推荐相似商品等。这些服务对于提升用户体验很重要，但在流量高峰期，为了保持整个系统的稳定性，我们可能需要对这些不是核心的服务进行限流。
限流实现
假设我们决定对显示用户评论的服务进行限流。下面是一个简化的示例，展示了如何应用限流机制：
import java.util.concurrent.Semaphore;
public class CommentsService {
// 限流器，允许的最大并发请求量设置为100
private final Semaphore rateLimiter = new Semaphore(100);
public String fetchComments(String productId) {
if (rateLimiter.tryAcquire()) {
try {
// 获取评论的逻辑
return getCommentsFromDatabase(productId);
} finally {
rateLimiter.release(); // 确保在获取评论后释放许可
}
} else {
// 达到限流条件时，返回一个友好的提示或执行其他逻辑
return "Due to high traffic, comments are temporarily unavailable. Please try again later.";
}
}
private String getCommentsFromDatabase(String productId) {
// 模拟从数据库获取评论的逻辑
// 这里只是返回一个示例字符串
return "Comments for product " + productId;
}
}
在这个示例中，CommentsService 类用于获取商品的用户评论。我们使用 Semaphore 作为限流器，它的构造函数接受一个参数，表示同时允许的最大并发请求量（在这个例子中设置为100）。在处理获取评论的请求时，我们首先尝试从 Semaphore 获取一个许可（通过 tryAcquire 方法）。如果成功（即当前的并发请求数未达到限制），则继续执行获取评论的逻辑；如果失败（即已达到并发请求量的限制），则直接返回一条提示信息，告诉用户评论服务暂时不可用。
限流的好处
通过这种方式，我们可以确保即使在访问量剧增的情况下，获取评论的服务也不会对系统造成过大压力，从而保护了电商平台的核心服务（如商品浏览、下单等）的稳定性和可用性。此外，通过返回友好的提示信息，也能在一定程度上维护良好的用户体验。
好文链接
您阅读本篇文章共花了： 大家都在找：
微服务：微服务的五大组件
架构：架构设计
云原生：云原生技术是什么
发表评论