1.认识微服务

1.1 微服务架构演变

【1】单体架构： 将业务的所有功能集中在一个项目中开发，打包成一个包部署。
优点: 架构简单；部署成本低。
缺点：耦合度高。
【2】分布式架构： 根据业务功能对系统进行拆分，每个业务模块作为独立项目开发，称为一个服务。
优点：降低服务耦合；有利于服务升级拓展
服务治理
分布式架构要考虑的问题：
服务拆分粒度如何?
服务集群地址如何维护？
服务之间如何实现远程调用？
服务健康状态如何感知？
【3】微服务：微服务是一种经过良好架构设计得到分布式架构方案，微服务的架构特征：
单一职责：微服务拆分力度更小，每一个服务都对应唯一的业务能力，做到单一职责，避免重复业务开发。
面向服务：微服务对外暴露业务接口
自治：团队独立、技术独立、数据独立、部署独立
隔离性强：服务调用做好隔离、容错、降级、避免出现级联问题
高内聚，低耦合

1.2 SpringCloud

在国内最知名的微服务方案的实现就是SpringCloud和阿里巴巴的Dubbo。
微服务技术对比

	Dubbbo	SpringCloud	SpringCloudAlibaba
注册中心	zookeeper、Redis	Eureka、Consul	Nacos、Eureka
服务远程调用	Dubbo协议	Feign（http协议）	Dubbo、Fegin
配置中心	无	SpringCloudConfig	SpringCloudConfig、Nacos
服务网关	无	SpringCloudGateway、Zuul	SpringCloudGateway、Zuul
服务监控和保护	dubbo-admin，功能弱	Hystrix	Sentinel

Spring Cloud
Spring Cloud 集成了各种微服务功能组件，并基于Spring Boot实现了这些组件的自动装配，从而提供了良好的开箱即用的体验：

服务注册发现
服务远程调用
服务链路监控
统一配置管理
统一网关路由
流控、降级、保护
SpringCloud与SpringBoot需要考虑版本兼容问题，我这里会使用 Hoxton.SR10,因此SpringBoot版本就是2.3.x。

2.分布式服务架构案例

2.1 服务拆分和远程调用

服务拆分注意事项：

不同微服务，不要重复开发相同业务
微服务数据独立，不要访问其他微服务数据库
微服务可以将自己的业务暴露为接口，供其他微服务调用

2.2 导入服务拆分Demo

导入cloud-demo
项目结构
cloud-demo
|-------order-service(根据id查询订单)
|
|-------user-service (根据id查询用户)
启动两个项目
分别验证接口
order
user

总结

微服务需要根据业务模块拆分，做到单一职责，不要重复开发相同业务

微服务可以将业务暴露为接口，供其他服务使用
不同微服务都应有自己独立的数据库

2.3 微服务远程调用-查询订单【基于RestTemplate发送http请求】

在order-service的OrderApplication中注册RestTemplate

@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication {
    
    

    public static void main(String[] args) {
    
    
        SpringApplication.run(OrderApplication.class, args);
    }

    /**
     * 创建RestTemplate并注入Spring容器
     * @return
     */
    @Bean
    public RestTemplate restTemplate(){
    
    
        return new RestTemplate();
    }

}


@Service
public class OrderService {
    
    

    @Autowired
    private OrderMapper orderMapper;

    @Autowired
    private RestTemplate  restTemplate;
    public Order queryOrderById(Long orderId) {
    
    
        // 1.查询订单
        Order order = orderMapper.findById(orderId);
        // 2.利用RestTemplate发送http请求，查询用户
        // 2.1 url路径
        String url = "http://localhost:8081/user/"+order.getUserId();
        // 2.2 发送http请求，实现远程调用
        User  user= restTemplate.getForObject(url,User.class);
        // 3. 封装user到Order
        order.setUser(user);

        // 4.返回
        return order;
    }
}

在这里插入图片描述

3.Eureka注册中心

先来了解一下服务调用的关系：

服务提供者：暴露接口给其他微服务调用
服务消费者：调用其他微服务提供的接口
提供者和消费者角色是相对的

3.1 远程调用的问题

服务消费者该如何获取服务提供者的地址信息？
如果有多个服务提供者，消费者该如何选择？
消费者如何得知服务提供者的健康状态？

3.2 eureka原理

服务消费者该如何获取服务提供者的地址信息？

服务提供者启动时向eureka注册自己的信息

eureka保存这些信息

消费者根据服务名称向eureka拉取提供者信息

如果有多个服务提供者，消费者该如何选择？

服务消费者利用负载均衡算法，从服务中挑选一个

消费者如何得知服务提供者的健康状态？

服务提供者会每隔30s向EurekaServe发送心跳请求，报告健康状态

eureka会更新记录服务列表信息，心跳不正常会被剔除

消费者就可以拉取到最新的信息

总结

在Eureka架构中，微服务角色有两类：

EurekaServer：服务端，注册中心
1. 记录服务信息
1. 心跳监控
EurekaClient：客户端
- Provider：服务提供者，例如案例中的 user-service
- 1. 注册自己的信息到EurekaServer
- 1. 每隔30s向EurekaServer发送一次心跳
- Consumer：服务消费者，例如案例中的 order-service
- 1. 根据服务名称从EurekaServer拉取服务列表
- 1. 基于服务列表做负载均衡，选中一个微服务后发起远程调用

3.3 搭建EurekaServer

3.3.1 搭建注册中心

搭建EurekaServer服务步骤如下：

创建项目，引入依赖

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

编写启动类，添加@EnableEurekaServer注解
添加application.yml文件，编写下面的配置

server:
  port: 10086
spring:
  application:
    name: eureka-server
eureka:
  client:
    service-url: 
      defaultZone: http://127.0.0.1:10086/eureka

启动服务验证
在这里插入图片描述

3.4 服务注册

注册user-service
将user-service服务注册到EurekaServer步骤如下：

在user-service项目下引入依赖

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

在application.yml文件，编写下面的配置

spring:
  application:
    name: userservice
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka

整体配置文件

server:
  port: 8081
spring:
  datasource:
    url: jdbc:mysql://localhost:3306/cloud_user?useSSL=false
    username: root
    password: 111111
    driver-class-name: com.mysql.jdbc.Driver
  application:
    name: userservice #user服务的服务名称
mybatis:
  type-aliases-package: cn.itcast.user.pojo
  configuration:
    map-underscore-to-camel-case: true
logging:
  level:
    cn.itcast: debug
  pattern:
    dateformat: MM-dd HH:mm:ss:SSS

eureka:
  client:
    service-url: # eureka的地址信息
      defaultZone: http://127.0.0.1:10086/eureka

order步骤如上，总结一下服务注册就是三步走：引入依赖、配置yml（服务名称和eureka服务地址）、启动服务
在这里插入图片描述
在注册服务得到时候，我们可以将user-service多次启动，模拟多实例部署，但为了避免端口冲突，需要修改端口设置：

3.5 服务发现

在order-service完成服务拉取
服务拉取是基于服务名称获取服务列表，然后再对列表做负载均衡

修改OrderService的代码，修改访问的路径，用服务名代替ip、端口

String url = "http://userservice/user/"+order.getUserId();

在order-service项目的启动类OrderApplication中的RestTemplate添加负载均衡注解：

/**
     * 创建RestTemplate并注入Spring容器
     * @return
     */
    @Bean
    @LoadBalanced //负载均衡注解
    public RestTemplate restTemplate(){
    
    
        return new RestTemplate();
    }

启动order-service服务，发送两次请求 http://localhost:8080/order/101 http://localhost:8080/order/102 查看负载均衡后拉取哪个服务。
在这里插入图片描述

4.Ribbon负载均衡

上面我们添加了@LoadBalanced注解，即可实现负载均衡功能，这是什么原理呢？

4.1 负载均衡原理

SpringCloud底层其实是利用了一个名为Ribbon的组件，来实现负载均衡功能的。

那么我们发出的请求明明是http://userservice/user/1，怎么变成了http://localhost:8081的呢？

4.2.源码跟踪

为什么我们只输入了service名称就可以访问了呢？之前还要获取ip和端口。

显然有人帮我们根据service名称，获取到了服务实例的ip和端口。它就是LoadBalancerInterceptor，这个类会在对RestTemplate的请求进行拦截，然后从Eureka根据服务id获取服务列表，随后利用负载均衡算法得到真实的服务地址信息，替换服务id。

我们进行源码跟踪：

1）LoadBalancerIntercepor

在这里插入图片描述

这里的intercept方法，拦截了用户的HttpRequest请求，然后做了几件事：

request.getURI()：获取请求uri，本例中就是 http://user-service/user/8
originalUri.getHost()：获取uri路径的主机名，其实就是服务id，user-service
this.loadBalancer.execute()：处理服务id，和用户请求。

这里的this.loadBalancer是LoadBalancerClient类型，我们继续跟入。

2）LoadBalancerClient

继续跟入execute方法：
在这里插入图片描述

代码是这样的：

getLoadBalancer(serviceId)：根据服务id获取ILoadBalancer，而ILoadBalancer会拿着服务id去eureka中获取服务列表并保存起来。
getServer(loadBalancer)：利用内置的负载均衡算法，从服务列表中选择一个。本例中，可以看到获取了8082端口的服务

放行后，再次访问并跟踪，发现获取的是8081：

在这里插入图片描述

果然实现了负载均衡。

3）负载均衡策略IRule

在刚才的代码中，可以看到获取服务使通过一个getServer方法来做负载均衡:

在这里插入图片描述

我们继续跟入：

在这里插入图片描述

继续跟踪源码chooseServer方法，发现这么一段代码：

在这里插入图片描述

我们看看这个rule是谁：

在这里插入图片描述

这里的rule默认值是一个RoundRobinRule，看类的介绍：
轮询负载均衡规则
在这里插入图片描述

这不就是轮询的意思嘛。

到这里，整个负载均衡的流程就清楚了。
在这里插入图片描述

4.2 负载均衡策略

Ribbon的负载均衡规则是一个叫IRule的接口来定义的，每一个子接口都是一种规则：
在这里插入图片描述
不同规则的含义如下：

内置负载均衡规则类	规则描述
RoundRobinRule	简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。
AvailabilityFilteringRule	对以下两种服务器进行忽略：（1）在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。（2）并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的..ActiveConnectionsLimit属性进行配置。
WeightedResponseTimeRule	为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。
ZoneAvoidanceRule	以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。
BestAvailableRule	忽略那些短路的服务器，并选择并发数较低的服务器。
RandomRule	随机选择一个可用的服务器。
RetryRule	重试机制的选择逻辑

默认的实现就是ZoneAvoidanceRule，是一种轮询方案

4.3.1 自定义负载均衡策略

通过定义IRule实现可以修改负载均衡规则，有两种方式：

代码方式：在order-service中的OrderApplication类中，定义一个新的IRule：

@Bean
public IRule randomRule(){
    
    
    return new RandomRule();
}

在这里插入图片描述

配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则：

userservice: # 给某个微服务配置负载均衡规则，这里是userservice服务
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则

注意，一般用默认的负载均衡规则，不做修改。

4.3 懒加载

Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，请求时间会很长。

而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：

ribbon:
  eager-load:
    enabled: true
    clients: userservice

下一篇我会学习总结Nacos注册中心的相关知识，感谢大家的支持！

微服务框架【笔记】

1.认识微服务

1.1 微服务架构演变

1.2 SpringCloud

2.分布式服务架构案例

2.1 服务拆分和远程调用

2.2 导入服务拆分Demo

总结

2.3 微服务远程调用-查询订单【基于RestTemplate发送http请求】

3.Eureka注册中心

3.1 远程调用的问题

3.2 eureka原理

总结

3.3 搭建EurekaServer

3.3.1 搭建注册中心

3.4 服务注册

3.5 服务发现

4.Ribbon负载均衡

4.1 负载均衡原理

4.2.源码跟踪

1）LoadBalancerIntercepor

2）LoadBalancerClient

3）负载均衡策略IRule

4.2 负载均衡策略

4.3.1 自定义负载均衡策略

4.3 懒加载

下一篇我会学习总结Nacos注册中心的相关知识，感谢大家的支持！

猜你喜欢