SpringCloud Alibaba(一) Nacos注册中心快速入门
1.基本概念
1.1 什么是Spring Cloud
Spring Cloud是分布式微服务架构的一站式解决方案，是多种微服务架构落地技术的集合体，俗称微服务全家桶。
Spring Cloud为开发人员提供了快速构建分布式系统中的一些常见模式的工具(例如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态).
1.2 什么是Nacos
Spring Cloud Alibaba的一个服务注册与发现的组件,用来代替不再更新的Eureka,在我们微服务中,服务与服务之间的调用,需要知道彼此是否在线,以及知道彼此的地址才可以调用,所以我们需要把微服务统一注册到注册中心,在微服务之间调用的时候,我们需要去配置中心拉取对应服务的地址,再去调用.下面我都会以Nacos最新版本v1.4.1为例子,Spring Cloud版本为最新的Hoxton.SR8,Spring Cloud Alibaba版本为2.2.5.RELEASE.
小知识:为什么我引入了Spring Cloud Alibaba的依赖还需要引入Spring Cloud的依赖?
答:因为Spring Cloud Alibaba是基于Spring Cloud的扩展和组件的实现,依赖于我们Spring Cloud制定的规范,也依赖于我们Spring Cloud的一些原生的组件.
官方文档： 什么是 Nacos
Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
Nacos 的关键特性包括:
- 服务发现和服务健康监测
- 动态配置服务
- 动态 DNS 服务
- 服务及其元数据管理
1.3 主流的注册中心比较
至于什么是CAP,后续Nacos源码会介绍,这里先有个印象.
C代表一致性,A代表可用性,P代表分区容错性.
C:我一个集群里面,每个节点的数据都是一致的.
A:我集群的一个节点挂了,还可以对外提供服务
P:当我发生分区(集群中节点因为网络问题不能相互访问)的时候,不会产生脑裂的问题,依然可以重新选举出新的Leader,对外提供服务.
1.4 Nacos的架构
我们先对NamingService有个印象,他可以获取到我们注册中心的所有服务.
NamingService: 命名服务，注册中心核心接口
ConfigService：配置服务，配置中心核心接口
OpenAPI文档：Open API 指南
2. Nacos服务端注册中心的安装
官网:单机模式:Nacos 快速开始
集群模式:集群部署说明
其他同学的安装:nacos集群部署与配置_thomson2021的博客-CSDN博客_nacos集群配置
安装完成直接访问ip:port/nacos
注意:我们配置mysql数据库是为了持久化配置,是配置中心的功能,实际上注册中心的功能没有用到mysql,就算注册中心持久化客户端数据也是放在本地文件.
注意我们生产上如果访问我们的nacos,前面最好多一层高可用的SLB(nginx)
3. 注册中心演变及其设计思想
比如现在我的用户服务是占用(User服务)8081端口的服务, 此时我的服务提供方 (order服务端口是8010)端口 我们可以通过RestTemplate 调用方式来进行调用
@RequestMapping(value = "/findOrderByUserId/{id}")
public R findOrderByUserId(@PathVariable("id") Integer id) {
log.info("根据userId:"+id+"查询订单信息");
// RestTemplate调用
String url = "http://localhost:8010/order/findOrderByUserId/"+id;
R result = restTemplate.getForObject(url,R.class);
return result;
}版本一:硬编码
缺点:
从上面看出的缺点就是，我们的在调用的时候，请求的Ip地址和端口是硬编码的.若此时，服务提供方(order)服务部署的机器换了端口或者是更换了部署机器的Ip,那么 我们需要修改代码重新发布部署.
版本二:手动维护注册表
缺点:
假设我们的order服务压力过大，我们需要把order服务作为集群，那么意味着 order是多节点部署 比如原来的，我们只有一台服务器，现在有多台服务器，那么作为运维人员 需要在手工维护一份注册表(容易出错),如果某个服务宕机了呢?
版本三:nginx
缺点:
我可以通过ng来做负载均衡,对，我首先认为这是可行的，当时 微服务成百上千的服务，难道我们要那成百上千 ng么？或者使用一个Ng 那么我们能想一下哪个ng的配置文件有多么复杂
版本四:
缺点:
看上去我已经有了基本的服务注册与发现的雏形了但是我们的微服务每次调用，都会去进行对数据库的查询，并发一高，数据库性能就是一个瓶颈问题;而且若我们的mysql挂了，那么我们所有的微服务调用都不能正常进行
版本5:
我们来看一下上图的功能:
1.会员服务启动的时候往注册中心的注册接口注册,注册中心把服务的信息以及状态保存在mysql
2.订单服务启动的时候往注册中心的注册接口注册
3.会员服务和会员服务里面有一个定时任务TimeTask,每15秒调用注册中心的心跳接口,告诉注册中心,我还活着.
4.注册中心还需要一个TimeTask去检查节点,将一段时间内没有心跳,更改节点为不健康.
5.会员服务下线的时候需要调用注销接口
6.如果每次都去注册中心获取其他服务的地址,有点浪费资源,所以得有一个TimeTask定时去注册中心拉取健康的服务节点.
7.当会员服务调用订单服务的时候,我们会先从注册中心获取所有订单服务的ip,然后根据不同的策略去选择一个订单服务的地址去调用.
8.注册中心是集群,他们内部之间在同步各个节点的信息.
4.Nacos的核心功能:
- 服务注册：Nacos Client(我们自己的服务就叫Nacos Client)会通过发送REST请求的方式向Nacos Server注册自己的服务，提供自身的元数据，比如ip地址、端口等信息。Nacos Server接收到注册请求后，就会把这些元数据信息存储在一个双层的内存Map中。
- 服务心跳：在服务注册后，Nacos Client会维护一个定时心跳来持续通知Nacos Server，说明服务一直处于可用状态，防止被剔除。默认5s发送一次心跳。
- 服务同步：Nacos Server集群之间会互相同步服务实例，用来保证服务信息的一致性。 leader raft
- 服务发现：服务消费者（Nacos Client）在调用服务提供者的服务时，会发送一个REST请求给Nacos Server，获取上面注册的服务清单，并且缓存在Nacos Client本地，同时会在Nacos Client本地开启一个定时任务定时拉取服务端最新的注册表信息更新到本地缓存
- 服务健康检查：Nacos Server会开启一个定时任务用来检查注册服务实例的健康情况，对于超过15s没有收到客户端心跳的实例会将它的healthy属性置为false(客户端服务发现时不会发现)，如果某个实例超过30秒没有收到心跳，直接剔除该实例(被剔除的实例如果恢复发送心跳则会重新注册)
5.Nacos client客户端的搭建
- 三板斧之:第一板斧,父pom加入依赖,设置版本管理
父pom
org.springframework.boot
spring-boot-starter-parent
2.3.2.RELEASE
com.lao.mall
vip-spring-cloud-alibaba
0.0.1-SNAPSHOT
spring-cloud-alibaba
pom
1.8
Hoxton.SR8
2.2.5.RELEASE
org.springframework.boot
spring-boot-starter
org.springframework.boot
spring-boot-starter-test
test
org.springframework.cloud
spring-cloud-dependencies
${spring-cloud.version}
pom
import
com.alibaba.cloud
spring-cloud-alibaba-dependencies
${spring-cloud-alibaba.version}
pom
import
实际项目pom,依赖直接引入nacos
com.alibaba.cloud
spring-cloud-starter-alibaba-nacos-discovery
- 三板斧之:第二板斧写注解(也可以不写,新版本不需要这个注解) @EnableDiscoveryClient
@SpringBootApplication
@EnableDiscoveryClient
public class AlibabaNacosClientOrderApplication {
public static void main(String[] args) {
SpringApplication.run(AlibabaNacosClientOrderApplication .class, args);
}
}- 第三板斧之:写配置文件yml
spring:
cloud:
nacos:
discovery:
server-addr: localhost:8848 #nacos的地址,最好写nginx的地址用来反向代理nacos集群
#namespace: 8b038ac3-f97b-46e4-8e77-c10eff1aec5c
#group: pay
#cluster-name: BJ
#metadata:
#version: v1
application:
name: order-center #应用名称服务启动之后
调用discoveryClient.getInstances(),可以获取实例的信息.获取结果如下
[
{
"serviceId": "order-center",
"host": "192.168.31.198",
"port": 8020,
"secure": false,
"metadata": {
"nacos.instanceId": "192.168.31.198#8020#DEFAULT#DEFAULT_GROUP@@order-center",
"nacos.weight": "1.0",
"nacos.cluster": "DEFAULT",
"nacos.ephemeral": "true",
"nacos.healthy": "true",
"preserved.register.source": "SPRING_CLOUD"
},
"uri": "http://192.168.31.198:8020",
"scheme": null,
"instanceId": null
},
{
"serviceId": "order-center",
"host": "192.168.31.198",
"port": 8021,
"secure": false,
"metadata": {
"nacos.instanceId": "192.168.31.198#8021#DEFAULT#DEFAULT_GROUP@@order-center",
"nacos.weight": "1.0",
"nacos.cluster": "DEFAULT",
"nacos.ephemeral": "true",
"nacos.healthy": "true",
"preserved.register.source": "SPRING_CLOUD"
},
"uri": "http://192.168.31.198:8021",
"scheme": null,
"instanceId": null
}
]6.Nacos 领域模型划分以及概念详解
订单服务配置文件
spring:
cloud:
nacos:
discovery:
server-addr: localhost:8848 #nacos地址
namespace: 42f5eab5-5b12-4f7b-8dbd-d4653e3ccc22 #命名空间
group: pay #分组
cluster-name: BJ #集群名称
application:
name: order-center #应用名称
用户服务配置文件
spring:
cloud:
nacos:
discovery:
server-addr: localhost:8848
namespace: 4a460d0c-c837-47be-8c09-248a2d3abbca
group: pay
cluster-name: BJ
application:
name: user-center1.首先我们来看NameSpace,即命名空间,用作环境隔离,如下面订单服务配置了test环境的命名空间id,用户服务配置了prod环境的命名空间id,他们命名空间不一样,则order和user两个服务不能相互调用.
2.接下来我们看Group,即分组,也是用作隔离,当我们在同一个命名空间下,我们可以给不同的微服务分组,因为这些微服务可能是由不同的小组开发,并不能相互调用.所以他们也不能相互调用,如上图交易微服务和仓储微服务不能相互调用.同一个Group下可以相互调用.
3.Service其实这个概念就是我的微服务集群,例如order集群,user集群.
4.Cluster集群,我同一个orderService下面,如下图,我可能有BJ(北京)-Cluster,NJ(南京)-Cluster,他们是跨机房的集群,但是他们直接可以相互调用,例如我BJ-Cluster的order服务可以调用NJ-Cluster的pay服务.但是我们尽量不要跨集群调用,因为中间可能会有网络问题,最好优先调用NJ-Cluster的pay服务.至于怎么同集群优先调用,可以看我们下一期的Ribbon负载均衡规则的改造.
