小菜鸟

Zuul：微服务架构中的路由与过滤网关

Zuul 是 Netflix 开源的微服务网关组件，作为系统的 “入口网关”，负责请求的路由转发和过滤处理，是微服务架构中连接客户端与内部服务的关键中间层。

Zuul 的核心功能

Zuul 的核心价值体现在路由（Routing） 和过滤（Filtering） 两大功能：

路由（Routing）

将外部请求根据规则转发到对应的微服务实例，实现 “统一入口”。例如：

• 客户端访问 http://zuul-gateway/dept/get/1，Zuul 将请求转发到 “部门服务”；
• 访问 http://zuul-gateway/user/login，转发到 “用户服务”。

通过路由，客户端无需记住每个微服务的地址，只需访问 Zuul 网关即可。

过滤（Filtering）

在请求转发的全过程中插入自定义逻辑，实现安全校验、监控、限流等功能。例如：

• 身份认证：拦截未登录请求，返回 401 错误；
• 日志记录：记录所有请求的路径、耗时等信息；
• 请求修改：统一添加请求头（如 X-Request-Id）；
• 限流熔断：限制某接口的请求频率，防止服务过载。

Zuul 的特性与局限性

特性

Hystrix 服务监控：实时掌控分布式系统健康状态

Hystrix 不仅提供熔断、降级等容错能力，还内置了准实时监控机制，通过收集请求执行数据（成功 / 失败次数、响应时间等），以可视化方式展示服务健康状态。结合 Hystrix Dashboard 和 Turbine，可实现单服务到集群的全方位监控，帮助开发者快速定位性能瓶颈和故障点。

Hystrix 监控的核心组件

Hystrix 监控体系包含三个核心部分：

Hystrix Dashboard：单服务监控

Hystrix Dashboard 通过图形化界面展示单个服务的 Hystrix 指标，直观反映服务的健康状态和调用情况。

集成步骤

（1）引入依赖

在需要监控的服务（如服务消费者）中添加 Dashboard 依赖：

Hystrix：分布式系统的容错守护者

在微服务架构中，服务间依赖错综复杂，一个服务的故障可能引发连锁反应，导致服务雪崩（某服务不可用→依赖其的服务资源耗尽→更多服务不可用）。Hystrix 作为 Netflix 开源的容错框架，通过熔断、降级、隔离等机制，为分布式系统提供了弹性保护，避免级联故障的扩散。

Hystrix 的核心目标：解决服务雪崩

服务雪崩的本质是 “依赖服务不可用导致调用方资源耗尽”。例如：

• 服务 A 调用服务 B，服务 B 调用服务 C；
• 服务 C 响应超时或崩溃，导致服务 B 的线程阻塞等待；
• 服务 B 线程耗尽后，服务 A 的调用请求也被阻塞，最终整个调用链崩溃。

Hystrix 通过以下手段解决雪崩问题：

• 超时控制：为每个依赖调用设置超时，避免线程无限期阻塞；
• 熔断机制：当依赖失败率过高时，自动 “跳闸” 停止调用，快速失败；
• 资源隔离：为每个依赖分配独立线程池，避免单个依赖耗尽所有资源；
• 降级策略：调用失败时返回预设的备用结果，保证调用方正常运行。

Hystrix 的核心原理与设计

1. 基于命令模式（HystrixCommand）

Hystrix 通过HystrixCommand封装对依赖的调用逻辑，将同步调用转换为可控的命令执行：

Feign 进阶特性与实践

Feign 作为 Spring Cloud 生态中重要的服务调用组件，除了基础的声明式接口调用外，还有许多进阶特性可以优化服务间通信的效率、可靠性和可维护性。以下从多个维度展开介绍：

依赖

1
2
3
4
5

<!-- feign -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-feign</artifactId>
</dependency>

配置启动类

1
2
3
4
5
6
7
8
9

@SpringBootApplication
@EnableEurekaClient
// 启动feign，会进行对FeignClient的扫描加载
@EnableFeignClients(basePackages = "com.zhanghe.study")
public class ConsumerApp {
    public static void main(String[] args) {
        SpringApplication.run(ConsumerApp.class,args);
    }
}

Feign 配置自定义

Feign 允许通过配置类自定义其核心组件（如编码器、解码器、日志级别等），实现更灵活的调用控制。

1. 全局配置与局部配置

• 全局配置：通过 @Configuration 注解定义配置类，并在启动类的 @EnableFeignClients 中指定 defaultConfiguration 参数，对所有 Feign 客户端生效。

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

  @Configuration public class FeignGlobalConfig { // 配置日志级别 @Bean public Logger.Level feignLoggerLevel() { return Logger.Level.FULL; // 打印所有请求细节 } // 替换默认 HTTP 客户端为 Apache HttpClient（需引入对应依赖） @Bean public CloseableHttpClient httpClient() { return HttpClientBuilder.create().build(); } } // 启动类指定全局配置 @EnableFeignClients(defaultConfiguration = FeignGlobalConfig.class)

• 局部配置：在 @FeignClient 的 configuration 属性中指定配置类，仅对当前客户端生效，优先级高于全局配置。

  1 2 3 4 5 6 7

  @FeignClient(value = "SERVICE-PROVIDER", configuration = FeignLocalConfig.class) public interface ProviderClient { @RequestMapping(value = "/dept/get/{id}",method = RequestMethod.GET) public Dept get(@PathVariable("id") long id); }

2. 核心配置项说明

Ribbon 负载均衡算法：内置实现与自定义实践

Ribbon 的核心能力在于其灵活的负载均衡算法，通过预设或自定义的规则将请求合理分配到服务实例。本文详细解析 Ribbon 的内置算法、配置方式及自定义实现，帮助理解其负载均衡的底层逻辑。

Ribbon 内置负载均衡算法详解

Ribbon 提供了 7 种内置负载均衡算法，每种算法针对不同场景设计，核心接口为IRule，所有算法均实现该接口。

1. RoundRobinRule（轮询算法）

• 原理：按顺序轮流选择服务实例（如实例 A→实例 B→实例 C→A…）。
• 特点：
  • 实现简单，公平性强，不依赖实例状态；
  • 缺点是未考虑实例负载差异（如某实例响应慢仍会被分配等量请求）。
• 适用场景：所有服务实例配置相同、负载均匀的场景（如无状态服务）。

2. RandomRule（随机算法）

• 原理：通过随机函数从可用实例中随机选择一个。
• 特点：
  • 实现简单，避免轮询的周期性波动；
  • 短期可能出现负载不均，但长期概率接近轮询。
• 适用场景：对负载均衡的 “均匀性” 要求不高，或实例性能差异较小的场景。

3. AvailabilityFilteringRule（可用性过滤算法）

• 原理：先过滤掉 “不可用” 实例，再对剩余实例轮询：
  • 过滤 1：处于 “断路器跳闸状态” 的实例（多次访问失败被标记为不可用）；
  • 过滤 2：并发连接数超过阈值的实例（通过ActiveConnectionsLimit配置）。
• 特点：
  • 主动规避故障实例和过载实例，提高调用成功率；
  • 依赖断路器（如 Hystrix）和连接数统计。
• 适用场景：需要规避故障实例的场景（如服务稳定性要求高的核心业务）。