本次学习是基于学习过SpringCloudNetflix基础下进行学习,此处省略对微服务环境的搭建。
根据学习发现Nacos 约等于 spring cloud eureka(注册中心)+ spring cloud config(配置中心),集成了这两个组件。
服务注册:在服务治理框架中,都会构建一个注册中心,每个服务单元向注册中心登记自己提供服务的详细信息。并在注册中心形成一张服务的清单,服务注册中心需要以心跳的方式去监测清单中的服务是否可用,如果不可用,需要在服务清单中剔除不可用的服务。
服务发现:服务调用方向服务注册中心咨询服务,并获取所有服务的实例清单,实现对具体服务实例的访问。
配置中心:为微服务架构中的微服务提供集中化的外部配置支持,配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。
了解常见的注册中心:
Zookeeper:是一个分布式服务框架,是Apache Hadoop的一个子项目,它主要是用来解决分布式应用中经常遇到的一些数据管理问题,如:统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等
Eureka:是Springcloud Netflix中的重要组件,主要作用就是做服务注册和发现。2.0后已经闭源. Consul
Consul:是基于GO语言开发的开源工具,主要面向分布式,服务化的系统提供服务注册、服务发现和配置管理的功能。Consul的功能都很实用,其中包括:服务注册/发现、健康检查、Key/Value存储、多数据中心和分布式一致性保证等特性。Consul本身只是一个二进制的可执行文件,所以安装和部署都非常简单只需要从 官网下载后,在执行对应的启动脚本即可。
Nacos:是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。它是Spring Cloud Alibaba组件之一,负责服务注册发现和服务配置,可以这样认为nacos=eureka+config。
安装Nacos安装 --下载地址: https://github.com/alibaba/nacos/releases,下载zip格式的安装包,然后进行解压缩操作
双击运行bin目录下的startup.cmd即可。
默认以集群启动,请用编辑器打开startup.cmd修改为单机启动
nacos的控制台界面地址:http://localhost:8848/nacos 或 http://192.168.0.4:8848/nacos/index.html
默认用户名密码都是nacos
com.alibaba.cloud spring-cloud-starter-alibaba-nacos-config com.alibaba.cloud spring-cloud-starter-alibaba-nacos-discovery
两个依赖分别作用是:
nacos-config这个依赖就相当于SpringCloud Config
nacos-discovery这个依赖就相当于Eureka。
spring: application: #服务名称 name: naocs-service profiles: active: dev cloud: nacos: //对config的配置展示 config: # 配置文件的环境 group: ${spring.profiles.active} # 配置文件的格式 file-extension: yaml # 配置中心的地址 server-addr: {本地Nocos地址}//默认localhost:8848/nacos或127.0.0.1:8848 # 配置文件prefix prefix: ${spring.application.name} //注册中心配置 discovery: server-addr: {本地Nocos地址}//默认localhost:8848/nacos或127.0.0.1:8848
在浏览器地址栏中输入applicaiton.yml文件中写入的nacos服务地址,这里以本机举例,在浏览器地址栏中输入127.0.0.1:8848/nacos,这里一定要注意,需要在注册地址后加入/nacos访问,用户名和密码默认都是nacos
1.nacos下载
2.nacos服务器启动
3.微服务引入相关依赖
4.springboot项目的yaml配置
5.springboot的启动类增加注解
6.项目启动后可以在nacos服务器可以看到有新注册的服务(成功连上nacas的注册中心)
将负载的请求分配在集群中的不同服务器中
根据负载均衡发生的位置,一般分为服务端负载均衡(常见Nginx)和客户端负载均衡(ribbon)
Nginx是属于服务器端的负载均衡,Ribbon是属于客户端的负载均衡,简而言之,Nginx的客户端发起请求不知道会被负载到哪台服务器上。
但是Ribbon发起的请求都是非常明确的,就像调用本地服务一样,
更广的范围说:Nginx是进程之间调用时候做的负载均衡,Ribbon是进程内部选择调用时候做的负载均衡
为了体验到负载均衡的思想,通过idea模拟多端
在RestTemplate方法下添加@LoadBalanced注解
直接修改调用微服务的ur的手动调用端口,改为服务提供者的name
默认是轮询的调用方式
(1)RoundRobinRule轮询(默认):
(2)RandomRule随机 只知道返回存活服务列表中的随机一个服务的下标,然后在存活列表upList.get(index) 这样去拿到随机的server返回:
(3)RetryRule轮询重试(重试采用的默认也是轮询)
(4)WeightedResponseTimeRule响应速度决定权重:
这个源码很长很复杂,就不放出来了,其实是对RoundRobbin的一种增强,加入了权重和计算响应时间的概念,其中响应速度最快的权重越大,权重越大则选中的概率越大。
(5)BestAvailableRule最优可用(底层也有RoundRobinRule):最优可用,判断最优其实用的是并发连接数。选择并发连接数较小的server发送请求。
(6)AvailabilityFilteringRule可用性过滤规则(底层也有RoundRobinRule):
可用过滤规则,其实它功能是先过滤掉不可用的Server实例,再选择并发连接最小的实例。
(7)ZoneAvoidanceRule区域内可用性能最优:
基于AvailabilityFilteringRule基础上做的,首先判断一个zone的运行性能是否可用,剔除不可用的区域zone的所有server,然后再利用AvailabilityPredicate过滤并发连接过多的server。
配置在服务客户端中
service-product: # 调用的提供者的名称
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule #ribbon负载策略
需要调哪个微服务就对提供者名称进行修改,在项目中可以会遇到调用多个微服务的情况