小菜鸟

Hystrix简介

发表于 2021-08-24 更新于 2025-08-20 分类于微服务阅读次数： Valine：
本文字数： 5.2k 阅读时长 ≈ 5 分钟

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

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

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

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

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

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

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

Hystrix 的核心原理与设计

1. 基于命令模式（HystrixCommand）

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

阅读全文 »

Feign简介

发表于 2021-08-23 更新于 2025-08-19 分类于微服务阅读次数： Valine：
本文字数： 4.6k 阅读时长 ≈ 4 分钟

Feign 进阶特性与实践

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

依赖

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

配置启动类

@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 客户端生效。

@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 属性中指定配置类，仅对当前客户端生效，优先级高于全局配置。

@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的负载均衡算法

发表于 2021-08-23 更新于 2025-08-20 分类于微服务阅读次数： Valine：
本文字数： 4.4k 阅读时长 ≈ 4 分钟

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

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

Ribbon 内置负载均衡算法详解

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

1. RoundRobinRule（轮询算法）

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

2. RandomRule（随机算法）

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

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

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

阅读全文 »

Ribbon简介

发表于 2021-08-23 更新于 2025-08-20 分类于微服务阅读次数： Valine：
本文字数： 4.9k 阅读时长 ≈ 4 分钟

Ribbon：客户端负载均衡的经典实现

Ribbon 是 Netflix 开源的客户端负载均衡工具，主要用于在微服务架构中实现服务间的负载均衡调用。它通过在客户端维护服务实例列表，基于预设的负载均衡算法选择合适的服务实例，从而避免单点故障并优化资源利用率。

Ribbon 的核心定位与价值

Ribbon 是客户端负载均衡器，与 Nginx 等集中式负载均衡不同：

集中式负载均衡（如 Nginx）：请求先经过负载均衡器，再转发到服务实例，负载均衡逻辑独立部署；
客户端负载均衡（Ribbon）：负载均衡逻辑集成在客户端，客户端直接从服务注册中心获取实例列表，自主选择实例发起请求。

Ribbon 的核心价值：

减少中间环节：客户端直接调用服务实例，无需经过额外负载均衡节点，降低网络延迟；
灵活的负载策略：支持轮询、随机、加权等多种负载均衡算法，且允许自定义；
内置容错机制：提供连接超时、重试等配置，提升服务调用的稳定性。

Ribbon 的依赖与配置

1. 引入依赖

根据 Spring Cloud 版本选择对应的 Ribbon 依赖：

Spring Cloud F 版及以上（推荐）：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
</dependency>

旧版本（如 Edgware 及之前）：

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

注意：若项目已引入spring-cloud-starter-openfeign，无需单独引入 Ribbon 依赖，OpenFeign 默认集成了 Ribbon。

2. 启用负载均衡

通过@LoadBalanced注解标记RestTemplate，使其具备负载均衡能力：

阅读全文 »

Lucene的评分公式

发表于 2021-08-21 更新于 2025-08-13 分类于 Lucene 阅读次数： Valine：
本文字数： 1.8k 阅读时长 ≈ 2 分钟

Lucene 评分公式：解析文档相关性的核心逻辑

Lucene 的评分机制是实现 “将最相关的文档排在前面” 的核心，其评分公式综合了多个维度的因子，量化文档与查询的匹配程度。理解这些因子的作用及公式逻辑，有助于优化索引质量和查询效果。

评分公式的核心逻辑

Lucene 的评分公式基于向量空间模型（Vector Space Model），将查询和文档都视为 “词项向量”，通过计算向量相似度（得分）判断相关性。简化后的核心公式如下（完整公式需结合所有因子）：

其中，d 代表文档，q 代表查询，Σ 表示对查询中所有词项的贡献求和。每个因子的具体作用如下：

评分公式的核心因子解析

词频（Term Frequency, TF）

定义：词项在当前文档的某个字段中出现的次数。
计算逻辑：为避免高频词过度主导得分，Lucene 通常采用 tf(t in d) = sqrt(词项在文档中出现的次数) 或 1 + log(词项出现次数)（出现次数为 0 时取 0）。
作用：词项在文档中出现次数越多，说明文档与该词项的关联越紧密（如 “机器学习” 在某篇论文中出现 10 次比出现 1 次更相关）。

逆文档频率（Inverse Document Frequency, IDF）

定义：衡量词项的 “罕见性”—— 词项在整个索引中出现的文档越少（越罕见），IDF 越高。
计算逻辑：

阅读全文 »