微服务框架

【SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式，系统详解springcloud微服务技术栈课程|黑马程序员Java微服务】

SpringCloud微服务架构

文章目录

• • • 微服务框架
    • SpringCloud微服务架构
    • 4 Ribbon
    • • 4.1 负载均衡原理
      • • 4.1.1 负载均衡流程

4 Ribbon

4.1 负载均衡原理

4.1.1 负载均衡流程

之前我们使用

org.springframework.cloudspring-cloud-starter-netflix-eureka-client

和

org.springframework.cloudspring-cloud-starter-netflix-eureka-server

简单实现了一个服务远程调用以及负载均衡的Demo

在这个过程中，我们就只是改了个服务名称，

加了个注解

这一切就自动发生了【里面到底发生了 什么，这就是接下来要说的】

其实这套东西的负载均衡是由一个名为Ribbon 的组件进行实现的

【负载均衡流程】

在我们之前的案例中

order 其实就是发了一个

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

即 http://userservice/user/1 这样的请求去得到服务

但是其实这个东西直接使用浏览器访问

可以看到，是不能直接用的，这说明这个过程中，肯定有东西帮我们做了一些处理

其实就是我们的Ribbon

它从哪儿去得到服务信息呢？很明显，是Eureka

接着再去做负载均衡

这样就是一个整体的实现流程

【看源码】

这个注解的意义就在于，以后使用 restTemplate bean 对象发起的请求，都会被Ribbon 进行拦截并处理

就是由这个类完成的，可以看到它实现了 ClientHttpRequestInterceptor 接口

在实现的方法中打一个断点，

通过debug 进行调试

通过postman 发起一个请求

接收到一个这样的请求

单步下去

现在应该去Eureka 拉取服务信息了

接下来它把 这个服务名称交给了一个叫 loadBalancer 的对象进行处理

可以看到它就是 一个Ribbon 的东西，名叫Ribbon 负载均衡客户端

继续单步下去

这里得到了一个“动态服务列表负载均衡器”

它里面有这两个东西，这就说明服务已经被成功地拉取到了

所以这一大步

就是在根据服务名称向Eureka 获取服务列表

接下来这句就是在做负载均衡了 ，选出一个服务

接着走下去

它实现了一些接口，像随机、轮询…

默认的负载均衡规则

接着下去就返回了

进而选出了 8081

接着就是使用真实主机和IP替换URL 中的信息了

回顾一下