前言
场景大纲
我们以这样一个场景来学习、构建我们的微服务
服务提供者的集群配置
根据官网的图示,我们集群的配置不只是注册中心,服务的提供者同样需要搭建集群,以达成系统的高可用。
8001服务集群改造
1. 创建8002模块
我们先将8001服务复制一个一摸一样的8002模块。
- 创建模块cloud-provider-payment8002。
cloud-provider-payment8002
- 将8001的pom依赖粘贴过来
ctrl+s保存
- 将8001的application.yml粘贴过来,并修改端口为8002
修改端口 - 将8001的代码复制到8002
注意:mapper文件粘贴过后需要clean一下整个工程,因为mapper是静态资源,如果之前打包过,不清除包启动会报错找不到xml文件。
- 将8002的启动类名修改一下
修改完成
CV大法用的6起来了!!!
2. 改造服务测试负载均衡
现在集群模块已经创建好了,为了调试负载均衡,让我们知道调用的是哪个服务,我们用端口号打印日志来区分。
修改8001和8002模块的controller层代码,加入获取端口号,并且在返回信息中加上端口号,这样可以直观的看出调用了哪个服务。
@Value("${server.port}")
private String serverPort;
3. 开始测试
- 启动所有服务
因为8002还没有启动过,所以Run Dashboard里面还看不到,所以我们再单独启动一下8002
2. 访问Eureka集群,测试注册中心集群
http://localhost:7001/
访问7002
http://localhost:7001/
完美~~
- 访问8001和8002,测试微服务集群查询
http://localhost:8001/payment/get/1
http://localhost:8002/payment/get/1
8001和8002服务正常
- 使用order服务调用者调用,测试负载均衡
http://localhost/customer/payment/get/1
也能正常调用。
多刷新几次,会发现始终都调用的8001端口的服务,这说明虽然两个8001和8002服务都正常,但是80服务调用的时候没有用上负载均衡。
4. 改造服务调用方使用负载均衡
- 之前我们的地址是写死的,现在有了两个集群的payment服务,所以我们需要修改成通过服务名而不是固定的ip端口调用。
http://ip:port改为http://servicename
其中服务名就是EurekaServer页面上对应的服务名 - 地址动态获取之后,我们还有使用@LoadBalanced注解来给RestTemplate开启使用负载均衡的能力,否则他还是会用ip端口的方法去调用服务,会报错。
@LoadBalanced
- 然后再次启动服务,使用customer调用。
http://localhost/customer/payment/get/1
多刷新几次这个页面,发现会交替的调用8001端口和8002端口,证明负载均衡生效了!!!
总结
同一服务名称,不同端口的服务注册的Eureka上会被视为集群。
mapper文件新增或修改后如果不能生效clean一下工程再启动就可以生效了。
集群搭建完成后,使用负载均衡需要将原来的ip:端口的调用方式改为使用服务名称调用的方式。
服务调用方默认不会开启负载均衡,使用RestTemplate方式调用时需要添加@LoadBalanced注解来开启负载均衡。
Ribbon负载均衡默认使用的时轮询。