Catalog
- Spring Cloud Consul
- 一、需求
- 二、是什么
- 三、优点
- 四、缺点
- 五、怎么用
- 六、细节
Spring Cloud Consul
一、需求
多个微服务之间通过RestTemplate中的api相互调用,一般要写死微服务的IP地址和端口号,相当于硬编码,非常不灵活,而且对于某中微服务可能会做负载均衡,这样通过编码的方式写IP地址和端口号,对于一个微服务需要去调用另外一个微服务的时候就非常繁琐和麻烦,Consul就帮我们解决了这个问题,项目中的每一个微服务都在Consul进行注册(入驻),微服务之间调用的时候,就通过Consul来需要需要调用的微服务。
除此之外,当一个项目是由多个微服务组成的时候,往往会存在很多通用的配置,比如多个微服务可能使用的都是同一个数据库的IP地址和端口号,如果在每一个微服务都单独配置这些通用的配置,当数据库的IP或者端口改变的时候,就需要去到每一个微服务单独修改配置文件,当微服务的数量非常多的时候,修改这些配置文件就非常耗时,且意义不大,本着有问题就加一层的原则,我们可以将这些通用的配置信息抽取出来统一管理(全局配置信息),当全局配置信息发生改变的时候,就通知到每一个微服务进行修改,而Consul就可以帮我们做这件事情。
二、是什么
Consul属于第三方软件(类似tomcat),是独立于微服务项目之外的(较于Eureka的优势所在之一),可以为我们提供服务注册与发现、代理配置中心等等功能,满足CP(CAP理论),即保证数据一致性和分区容错性,但不保证高可用。(Consul官网、Spring官网)
tips:CAP理论
CAP理论,即下面三个词组的首字母Consistency、 Availability 、 Partition tolerance, 任何分布式系统理论上只能满足其中任意两个特性。
- C:代表数据的强一致性,其实也就是多个节点之间同步数据的时候,如果某个节点同步数据失败,会直接拒绝后续的请求;
- A:代表高可用性,是相对于用户来说,也就是这个分布式系统什么时候都能做出非错误响应(数据可能是过期的);
- P:代表分区容错性,在分布式系统中,有多个节点,比如有三个节点A、B、C,A和B之间出现网络故障无法通信,但A和C、B和C仍然可以通信,相当于形成了两个分区,只有分区内的节点能够相互通信,这就是网络分区故障,而分区容忍性代表着系统即使发生网络分区,也可以继续运行。
三、优点
- 实现了和多微服务项目的解耦(早期的Eureka是耦合在项目中的);
- 阳哥笔记:
四、缺点
- 需要额外维护第三方服务器(Consul服务器)
五、怎么用
下载Consul服务
-
官网下载
-
安装好后,点击Exe文件,可能会一闪而过,但不影响使用
-
在D:\Final-plan\SpringCloud\dev-soft\consul_1.17.1_windows_386目录下(输入cmd,进入命令提示符界面),输入"consul agent -dev"以开发模式启动:
微服务的注册与发现
-
导入Maven坐标;
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-consul-discovery</artifactId><exclusions><exclusion><groupId>commons-logging</groupId><artifactId>commons-logging</artifactId></exclusion></exclusions></dependency>
-
修改微服务配置文件,主要配置微服务在Consul的名字,然后启动项目;
spring:application:name: cloud-payment-service# 配置spring cloud consul for discovery servicecloud:consul:host: localhostport: 8500discovery:service-name: ${spring.application.name}
-
打开Consul的图形化界面(本机),查看是否有该微服务;
-
基于Consul,通过RestTemplate实现微服务之间的调用,将原来被调用的微服务的IP地址和端口一并删掉,换成在Consul中配置的名字;
//public static final String PaymentSrv_URL = "http://localhost:8001/pay";public static final String PaymentSrv_URL = "http://cloud-payment-service"; //IP地址和端口号修改为在Consul配置的名字,这里是在微服务中的调用方配置的需要调用的微服务地址
微服务从Consul拉取配置信息
-
导入Maven坐标;
<!--SpringCloud consul config--><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-consul-config</artifactId></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-bootstrap</artifactId></dependency>
-
建立bootstrap.yml文件(resource目录下),该文件是比application.yml优先级更高的配置文件,会在项目初始化化的时候拉去外部源(这里指的是在Consul中的配置信息)的配置信息;
spring:application:name: cloud-payment-service####Spring Cloud Consul for Service Discoverycloud:consul:host: localhostport: 8500discovery:service-name: ${spring.application.name}config:profile-separator: '-' # default value is ",",we update '-',这里配置的是Consul的文件夹命名的分隔符,主要是要识别最后一个分隔符后面的单词作为环境标识符format: YAML # 规定Spring Cloud程序用什么解析器解析从consul拉取过来的数据watch:wait-time: 1 # 当Consul配置信息发生改变的时候,通知微服务来拉取# config/cloud-payment-service/data # /cloud-payment-service-dev/data # /cloud-payment-service-prod/data
-
在Consul中配置全局配置中心的信息,注意要创建文件夹输入的名字的结尾要加’/', 第一个目录需要指定为config,最后的数据的名字需要指定为data;
-
在application.yml文件中配置使用哪个环境的配置文件(对应到在Consul配置的配置信息文件夹中,最后一个分隔符的名字);
spring:profiles:active: dev# 多环境配置加载内容dev/prod,不写就是默认default配置
-
测试从Consul拉取配置信息是否成功,在Controller层测试;
@Value("${server.port}")private String port;@GetMapping("/get/info")public String getInfoByConsul(@Value("${test.info}") String info){return "test.info: " + info + " " + port;}
六、细节
- 重启Consul服务器之后,上面设置的全局配置中心就全部清空了,后续需要对这些配置做持久化。