目录
前言
一、Ribbon和Eureka的关系
二、Eureka知识笔记（个人理解）
三、关于Ribbon和Nginx的负载均衡区别
1、位置&工作方式
2、策略
3、集中式与分布式
四、杂项
1、版本问题
2、一些课堂内容订正
3、Spring Cloud生态给出的替代方案
Spring Cloud LoadBalancer
Spring Cloud Consul
完成度比较
前言
这次的文章会偏主观和实用性，因为这些内容可以讲的东西太多了，因此我只会根据老师布置的题目和需求，结合搜索工具、内容进行针对性定制化。
一、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进行负载均衡。
这一套解决方案的流程大致是：
- 启动Eureka服务
- 启动微服务(自动向Eureka注册)
- 客户端通过Ribbon向Eureka服务提交需求，获取到服务列表
- 通过负载均衡算法，挑出适合的服务实例去调用
三、关于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;}这种写法(硬编码仅供解说展示，非编程习惯)
为什么要用构造器注入而非字段注入呢？
- 不可变性: 使用构造器注入可以创建不可变的对象，这意味着一旦构造器通过注入创建了对象，其依赖就不能被更改。这有助于保证对象状态的一致性和安全性
- 依赖明确性: 构造器注入强制要求提供所有必需的依赖，这样可以在对象创建时就确保所有的依赖都被正确地提供，避免了空指针异常的风险
- 易于测试: 构造器注入使得对象更容易进行单元测试，因为测试时可以通过构造器直接传递模拟或者存根对象
- 减少Spring依赖: 字段注入需要依赖于Spring容器的反射机制来注入依赖，而构造器注入则可以在不使用Spring特定功能的情况下实现，这使得代码更加独立和可移植
- 预防循环依赖：使用构造器注入可以在应用启动时就发现循环依赖的问题，因为如果存在循环依赖，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 的升级版本，提供了更加全面和先进的功能
)
和枚举定义方法)