服务端负载均衡
负载均衡是我们处理高并发、缓解网络压力和进行服务端扩容的重要手段之一,但是一般情况下我们所说的负载均衡通常都是指服务端负载均衡,服务端负载均衡又分为两种,一种是硬件负载均衡,还有一种是软件负载均衡。
硬件负载均衡主要通过在服务器节点之间安装专门用于负载均衡的设备,常见的如F5。
软件负载均衡则主要是在服务器上安装一些具有负载均衡功能的软件来完成请求分发进而实现负载均衡,常见的就是Nginx。
无论是硬件负载均衡还是软件负载均衡,它的工作原理都不外乎下面这张图:
负载均衡是我们处理高并发、缓解网络压力和进行服务端扩容的重要手段之一,但是一般情况下我们所说的负载均衡通常都是指服务端负载均衡,服务端负载均衡又分为两种,一种是硬件负载均衡,还有一种是软件负载均衡。
硬件负载均衡主要通过在服务器节点之间安装专门用于负载均衡的设备,常见的如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:
可以毫不夸张地说,这篇文章介绍的 Spring/SpringBoot 常用注解基本已经涵盖你工作中遇到的大部分常用的场景。对于每一个注解我都说了具体用法,掌握搞懂,使用 SpringBoot 来开发项目基本没啥大问题了!
为什么要写这篇文章?
最近看到网上有一篇关于 SpringBoot 常用注解的文章被转载的比较多,我看了文章内容之后属实觉得质量有点低,并且有点会误导没有太多实际使用经验的人(这些人又占据了大多数)。所以,自己索性花了大概 两天时间简单总结一下了。
创建用于拦截的 bean
1 | public class TestBean { |
SpringApplication 启动过程主要包括两个阶段:
1 | public SpringApplication(ResourceLoader resourceLoader, Class<?>... primarySources) { |