IRule
这是所有负载均衡策略的父接口,里边的核心方法就是choose方法,用来选择一个服务实例。
AbstractLoadBalancerRule
AbstractLoadBalancerRule是一个抽象类,里边主要定义了一个ILoadBalancer,就是负载均衡器。这里定义它的目的主要是辅助负责均衡策略选取合适的服务端实例。
这是所有负载均衡策略的父接口,里边的核心方法就是choose方法,用来选择一个服务实例。
AbstractLoadBalancerRule是一个抽象类,里边主要定义了一个ILoadBalancer,就是负载均衡器。这里定义它的目的主要是辅助负责均衡策略选取合适的服务端实例。
首先我们需要在服务消费者中引入hystrix,如下:
1 | <dependency> |
首先我们来看一张上篇文章中的旧图:
这是ILoadBalancer接口的一张类关系图,我们就从这张图里看起吧。
AbstractLoadBalancer类的定义如下:
Spring Cloud RestTemplate 负载均衡
开启负载均衡很简单,只需要在RestTemplate的bean上再添加一个@LoadBalanced注解即可,所以本文我们就从这个注解开始我们的分析吧。
首先我们来看看@LoadBalanced注解的源码:
1 | /** |
负载均衡是我们处理高并发、缓解网络压力和进行服务端扩容的重要手段之一,但是一般情况下我们所说的负载均衡通常都是指服务端负载均衡,服务端负载均衡又分为两种,一种是硬件负载均衡,还有一种是软件负载均衡。
硬件负载均衡主要通过在服务器节点之间安装专门用于负载均衡的设备,常见的如F5。
软件负载均衡则主要是在服务器上安装一些具有负载均衡功能的软件来完成请求分发进而实现负载均衡,常见的就是Nginx。
无论是硬件负载均衡还是软件负载均衡,它的工作原理都不外乎下面这张图:
Spring Cloud RestTemplate 中几种常见的请求方式
首先我们要搭建一个测试环境,方便我们一会验证相应的API。
创建好的maven项目如下图所示:
其中commons是一个公共模块,是一个普通的JavaSE工程,我们一会主要将实体类写在这个模块中,provider和consumer是两个spring boot项目,provider将扮演服务提供者的角色,consumer扮演服务消费者的角色。
Eureka服务治理体系支持跨平台,虽然我们前文使用了Spring Boot来作为服务提供者,但是对于其他技术平台只要支持Eureka通信机制,一样也是可以作为服务提供者,换句话说,服务提供者既可以是Java写的,也可以是python写的,也可以是js写的。这些服务提供者将自己注册到Eureka上,供其它应用发现然后调用,这就是我们的服务提供者,服务提供者主要有如下一些功能:
服务提供者在启动的时候会通过发送REST请求将自己注册到Eureka Server上,同时还携带了自身服务的一些元数据信息。Eureka Server在接收到这个REST请求之后,将元数据信息存储在一个双层结构的Map集合中,第一层的key是服务名,第二层的key是具体服务的实例名
服务的发现和消费实际上是两个行为,这两个行为要由不同的对象来完成:服务的发现由Eureka客户端来完成,而服务的消费由Ribbon来完成。Ribbo是一个基于HTTP和TCP的客户端负载均衡器,当我们将Ribbon和Eureka一起使用时,Ribbon会从Eureka注册中心去获取服务端列表,然后进行轮询访问以到达负载均衡的作用,服务端是否在线这些问题则交由Eureka去维护。OK,下面我们将通过一个简单的案例,来看看如何实现服务的发现与消费。
启动结果如下:
首先我们需要创建一个普通的Spring Boot工程,命名为eureka-server,普通到什么程度呢?就是一个starter都不需要添加,创建成功之后就只引用了一个父starter。
工程创建成功之后,向pom.xml文件中添加eureka-server的依赖,目前eureka的稳定版本是Dalston.SR3
,添加完依赖之后,pom.xml文件如下所示:
在上篇博客中,我们创建了一个名叫eureka-server的服务注册中心,那么在本文中,我将修改这个工程的配置文件,进而将其启动多次。如下,我向这个工程中添加两个配置文件application-peer1.properties和application-peer2.properties:
两个配置文件的内容分别如下:
application-peer1.properties: