[日报] Ribbon、Eureka、Nginx、负载均衡

前言

    这次的文章会偏主观和实用性，因为这些内容可以讲的东西太多了，因此我只会根据老师布置的题目和需求，结合搜索工具、内容进行针对性定制化。

一、Ribbon和Eureka的关系

    Ribbon和Eureka在微服务架构中共同协作以实现服务的动态负载均衡。Eureka作为服务发现组件，负责管理服务实例的注册与发现。而Ribbon则是客户端负载均衡器，它根据Eureka Client提供的注册信息来选择合适的服务实例进行请求分发。

    注意这里你经常看到的一个词：**服务发现件组。**这玩意有点类似反向代理，但是它并不会去代理任何业务，职责非常单一：发现、注册。主观概念上完成了“反向代理”的，其实是Ribbon（同时它还提供了负载均衡，像Nginx）。

    但是它和反向代理又有区别：Ribbon确实承担了类似于反向代理的一些功能，因为它需要决定将请求发送到哪个服务实例。但是Ribbon的工作是在**客户端**完成的，而传统的反向代理则是作为服务器端的组件来操作。

二、Eureka知识笔记（个人理解）

    当项目架构变成微服务阶段时，不同服务之间需要靠网络进行通信。为了解决原始的HttpClient需要把url写死的问题，引入了**服务发现件组**（如Eureka**）**、RestTemplate等一套解决方案。

    使用Eureka和服务发现机制的本质，是将服务实例的地址（IP和端口）管理从静态配置转移到了动态注册和发现。服务实例在启动时会将自己的地址信息注册到Eureka，而消费者通过Eureka来发现服务实例。这样服务的部署和扩缩容变得更加灵活，不需要手动修改和维护服务消费者的配置。

    如果你使用了服务集群来提升性能，那么需要使用相同的spring.application.name来向Eureka注册（因为Eureka是根据服务名分服务的），Ribbon进行负载均衡。

    这一套解决方案的流程大致是：

1. 启动Eureka服务
2. 启动微服务(自动向Eureka注册)
3. 客户端通过Ribbon向Eureka服务提交需求，获取到服务列表
4. 通过负载均衡算法，挑出适合的服务实例去调用

三、关于Ribbon和Nginx的负载均衡区别

1、位置&工作方式

    这是最明显的区别，因为：

• Nginx是一个服务端的负载均衡器，它作为反向代理服务器，处理到达服务器的所有请求，并将它们分发到后端的多个服务实例中
• Ribbon是一个客户端负载均衡器，它在微服务架构中运行，通过从服务注册中心（如Eureka）拉取服务列表，然后在客户端本地进行负载均衡算法处理，选择一个服务实例进行调用

2、策略

• Nginx支持多种负载均衡策略，如轮询、最少连接数、IP哈希
• Ribbon允许开发者自定义负载均衡策略，可以更灵活地根据需要选择不同的算法

3、集中式与分布式

• Nginx是集中式的，所有请求都会经过Nginx服务器进行处理和路由
• Ribbon是分布式的，每个客户端独立进行服务发现和负载均衡，这样可以减少单点故障的风险，并且可以更好地扩展

四、杂项

1、版本问题

    2.7.13版本的spring boot需要用3.1.x（比如3.1.8）版本的spring cloud，问就是去maven官网挨个试过去得到的结论

2、一些课堂内容订正

     老师建议使用@Resource而不是@Autowired，我有不同的看法。首先，他是在用字段注入进行讲解——但实际开发环境中，应该选用构造器注入的方式。而Spring官方推荐的构造器注入是使用注解@Autowired的（据说是因为这样可以确保依赖的不可变性和非空性）。 

    其次，老师推荐使用@Resource的原因是，它默认是按名注入而不是@Autowired的按类型注入。但是这里他没有讲

@Bean("ye,it's its name")

public SomeService(@Qualifier("ye,it's its name") RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

这种写法(硬编码仅供解说展示，非编程习惯)

    为什么要用构造器注入而非字段注入呢？

1. 不可变性: 使用构造器注入可以创建不可变的对象，这意味着一旦构造器通过注入创建了对象，其依赖就不能被更改。这有助于保证对象状态的一致性和安全性
2. 依赖明确性: 构造器注入强制要求提供所有必需的依赖，这样可以在对象创建时就确保所有的依赖都被正确地提供，避免了空指针异常的风险
3. 易于测试: 构造器注入使得对象更容易进行单元测试，因为测试时可以通过构造器直接传递模拟或者存根对象
4. 减少Spring依赖: 字段注入需要依赖于Spring容器的反射机制来注入依赖，而构造器注入则可以在不使用Spring特定功能的情况下实现，这使得代码更加独立和可移植
5. 预防循环依赖：使用构造器注入可以在应用启动时就发现循环依赖的问题，因为如果存在循环依赖，Spring容器无法创建Bean实例，这样就可以在编译时而不是运行时解决这些问题。而字段注入可能会隐藏循环依赖的问题，因为它允许Spring容器通过反射机制先创建Bean实例，然后再进行依赖注入。这可能导致运行时错误，因为Bean实例已经被创建，但是它们的依赖却没有被正确地处理。

所以，如果要我二选一，综合考虑下我更推荐使用@Autowired。(另外它是Spring自家的，有种莫名的靠谱感)

提一嘴：如果一个类只有一个构造方法，Spring框架会默认使用这个构造方法来进行依赖注入，无需添加任何注解（相反，如果有多个构造方法，必须添加@Autowired注解），从Spring 4.3版本开始这个特性就已经被包含在内了。这样可以减少你使用注解，让代码变得更加优美（但也会让可读性下降）。

3、Spring Cloud生态给出的替代方案

    事实上，Spring Cloud生态已经提出了Eureka和Ribbon的升级替换方案：

Spring Cloud LoadBalancer

** **旨在替代 Ribbon。

• Spring Cloud LoadBalancer 是 Spring Cloud 提供的一个客户端负载均衡器，旨在替代 Ribbon。它提供了一种更加轻量级和灵活的负载均衡解决方案，与 Ribbon 相比，Spring Cloud LoadBalancer 提供了更简化的 API 和更灵活的扩展机制
• Spring Cloud LoadBalancer 支持多种负载均衡策略，并且可以与服务发现组件（如 Eureka、Consul）集成，以实现动态的服务发现和负载均衡

Spring Cloud Consul

** **虽然没有明确想替换Eureka的目的，但是：

• Spring Cloud Consul 是 Spring Cloud 提供的一个服务发现和配置管理工具，基于 Consul 实现。Consul 是一个开源的分布式服务发现和配置工具，可以用于构建分布式系统中的服务注册、发现和配置管理
• Spring Cloud Consul 提供了与 Consul 的集成，可以通过 Consul 实现服务的注册与发现，同时还可以利用 Consul 的健康检查功能来实现服务的动态负载均衡

完成度比较

    Spring Cloud LoadBalancer 和 Spring Cloud Consul 都是 Spring Cloud 生态系统中的重要组件，它们提供了现代化的服务发现和负载均衡解决方案。相较于 Ribbon，Spring Cloud LoadBalancer 提供了更简单、更灵活的负载均衡功能，而 Spring Cloud Consul 则提供了与 Consul 集成的服务发现和配置管理功能

    从功能和设计上来说，Spring Cloud LoadBalancer 和 Spring Cloud Consul 可以看作是对 Ribbon 的进一步完善和扩展，更符合现代微服务架构的需求。因此，它们在某种程度上可以看作是 Ribbon 的升级版本，提供了更加全面和先进的功能