SpringCloud之Eureka注册中心和负载均衡
微服务技术栈
认识微服务
单体架构
简介：将业务内的所有功能集中在一个项目中开发，打成一个包部署。
- 优点- 架构简单- 部署成本低
- 缺点- 耦合度高
分布式架构
简介：根据业务功能对系统进行拆分，每个业务模块作为独立项目开发，称为一个服务。
- 优点 - 降低服务耦合- 有利于服务升级拓展
- 缺点 - 服务治理麻烦
微服务
简介：是一种经过良好架构设计的分布式架构方案。
特征：
- 单一职责：微服务拆分粒度更小，每个服务都对应唯一的业务能力，做到单一职责，避免重复业务开发
- 面向服务：微服务对外暴露业务接口
- 自治：团队独立，技术独立，数据独立，部署独立
- 隔离性强：服务调用做好隔离、若错、降级、避免出现级联失败
微服务拆分及远程调用
微服务拆分注意事项
- 不同微服务，不要重复开发相同业务
- 微服务数据独立，不要访问其它微服务的数据库
- 微服务可以将自己的业务暴露为接口，供其它微服务调用
当我们某一个服务需要获取到其他服务的数据库信息时，我们就需要从当前服务向目标服务发送http请求，调用对应的接口获取数据。
- 在配置类中将RestTemplate注入容器
@BeanpublicRestTemplaterestTemplate(){returnnewRestTemplate();}
- 在对应服务功能下注入容器并发送http请求
@AutowiredprivateRestTemplate restTemplate;publicOrderqueryOrderById(Long orderId){// 1.查询订单Order order = orderMapper.findById(orderId);// 2.利用restTemplate发送http请求，查询用户String url ="http://localhost:8081/user/"+ order.getUserId();User user= restTemplate.getForObject(url,User.class);// 3.封装成Order对象
order.setUser(user);// 4.返回return order;}
从结果可以看到成功拿到用户信息。
Eureka注册中心
提供者与消费者
- 服务提供者：一次业务中，被其它微服务调用的服务。（提供接口给其它微服务）
- 服务消费者：一次业务中，调用其它微服务的服务。（调用其它微服务提供的接口）
原理分析
在服务调用的时候，地址固定，当项目环境发生变化时，对项目很不友好。
服务调用出现的问题
- 服务消费者该如何获取服务提供者的地址信息？
- 如果有多个服务提供者，消费者该如何选择？
- 消费者如何得知服务提供者的健康状态？
Eureka的作用
- 消费者该如何获取服务提供者具体信息？◆服务提供者启动时向eureka注册自己的信息◆eureka保存这些信息◆消费者根据服务名称向eureka拉取提供者信息
- 如果有多个服务提供者，消费者该如何选择？◆服务消费者利用负载均衡算法，从服务列表中挑选一个
- 消费者如何感知服务提供者健康状态？◆服务提供者会每隔30秒向EurekaServer发送心跳请求，报告健康状态◆eureka会更新记录服务列表信息，心跳不正常会被剔除◆消费者就可以拉取到最新的信息
使用流程
1、搭建EurekaServer
搭建EurekaServer服务步骤如下：
1.创建项目，引入spring-cloud-starter-netflix-eureka-server的依赖
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-eureka-server</artifactId></dependency>
2.编写启动类，添加@EnableEurekaServer注解
3.添加application.yml文件，编写下面的配置：
server:port:8082spring:application:name: eureka-server
#eureka自己也会被注册eureka:client:service-url:
defaultZone:http://localhost:8082/eureka/
2、注册user-service
将user-service服务注册到EurekaServer:步骤如下：
l.在user-service:项目引入spring-cloud-starter–netflix-eureka-client的依赖
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-eureka-client</artifactId></dependency>
2.在application.yml文件，编写下面的配置：
spring:application:name: userservice
eureka:client:service-url:#指的是注册中心服务的地址defaultZone: http://localhost:8082/eureka/
拓展
：在idea启动单个项目的多个实例：
- 在服务界面右键服务，复制配置
- 2023版本的idea需要添加虚拟机选项以及打开允许多个实例
- 在虚拟机配置**-Dserver.port=8083**（端口选择一个未用的），同时修改服务名称
- 在服务页面中启动项目
3、在order-service完成服务拉取
服务拉取是基于服务名称获取服务列表，然后在对服务列表做负载均衡
1.修改OrderService的代码，修改访问的url路径，用服务名代替ip、端口：
String url "http://userservice/user/"+order.getUserId();
2.在order-service.项目的启动类OrderApplication中的RestTemplate添加负载均衡注解：
@Bean@LoadBalancedpublicRestTemplaterestTemplate(){returnnewRestTemplate();}
负载均衡（Load Balance），意思是将负载（工作任务，访问请求）进行平衡、分摊到多个操作单元（服务器，组件）上进行执行。是解决高性能，单点故障（高可用），扩展性（水平伸缩）的终极解决方案。
这种环境下，当我们的order-server向user-server发送http请求时，会平衡地向不同实例的user-server发送请求。
Ribbon负载均衡
负载均衡流程
负载均衡策略
Ribbon的负载均衡规则是一个叫做IRule的接口来定义的，每一个子接口都是一种规则：
内置负载均衡规则类规则描述****RoundRobinRule简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。AvailabilityFilteringRule对以下两种服务器进行忽略：(1)在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。(2)并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的:.:.ActiveConnectionsLimit属性进行配置。WeightedResponseTimeRule为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择ZoneAvoidanceRule服务器，这个权重值会影响服务器的选择。
以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。BestAvailableRule忽略哪些短路的服务器，并选择并发数较低的服务器。RandomRule随机选择一个可用的服务器。RetryRule重试机制的选择逻辑
IRule默认为轮询规则，通过定义Rule实现可以修改负载均衡规则，有两种方式：
- 代码方式：在order-service中的OrderApplication类中，定义一个新的IRule:
@BeanpublicIRulerandomRule(){returnnewRandomRule();} - 配置文件方式：在order-.servicef的application,ym段件中， 添加新的配置也，可以修改规侧：
user-service:ribbon: NFLoadBalancerRuleClassName:com.netflix.loadbalancer.RandomRule #负载均规则
饥饿加载
Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient,请求时间会很长。
而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：
ribbon:eager-load:enabled:true#开启饥饿加载clients: user-server #指定劢user-server这个服务饥饿加载
版权归原作者 Gunalaer 所有， 如有侵权，请联系我们删除。