你好,欢迎阅读,本文是系列文章中的第1篇。
Part1 - Nacos 是什么?
Part2 - Nacos 环境搭建
Part3 - Nacos 服务发现实践
Part4 - Nacos 分布式配置实践
本文的目标是理解 Nacos 的概念作用,并理解服务发现与分布式配置的概念。
1. Nacos 介绍 Nacos 的官网地址为 https://nacos.io
文章图片
上图为首页截图,已经明确的说明了 Nacos的2个核心作用:
- 服务发现
- 配置管理
Nacos 这个名字怎么读呢?它的音标为 /nɑ:k??s/。这个名字不是一个标准的单词,而是以下单词的首字母缩写:
Name and Config Service从命名中也可以看出 Nacos 的功能了。
从上图中可以看到,Nacos 的网站是中文的,这是因为 Nacos 是国产的,是阿里开源的。
阿里为 SpringCloud 贡献了一个子项目,叫做 SpringCloud Alibaba,其中包括了微服务开发中的几个基础组件,Nacos 就是此项目中的一项技术。
文章图片
SpringCloud Alibaba 可以对标 SpringCloud 中老牌的主流项目 SpringCloud Netflix(包括 Eureka、Hystrix、Zuul 等等),也是一个技术集,包括:
文章图片
可以看到,主要技术有:
- Sentinel -- 提供流控、服务降级、熔断能力,为体统提供防护。
- Nacos -- 负责服务注册与发现,还有分布式配置。
- RocketMQ -- 用于实现事件驱动模式、消息总线,已经整合了 SpringCloud Stream。
- Seata -- 用于实现分布式事务。
- Dubbo RPC -- 使用 RPC 进行服务调用。
下面大概浏览一下 Nacos 的控制台界面,看看主要的功能。
- 服务管理
文章图片
文章图片
文章图片
- 配置管理
文章图片
文章图片
文章图片
2. 服务发现概念简介 分布式系统中,包含多个独立的服务,服务之间存在需要调用的需求,应该如何调用?
服务调用时必须知道目标服务实例的 IP、端口、API 接口。
其中 API 信息可以通过服务接口文档中获知,但 IP、端口 都是动态的,每次部署服务实例的时候可能都会变。
知道了目标服务实例的地址,就相当于发现了对方。具体怎么发现目标服务?这就是服务发现机制。
文章图片
如上图,在服务实例数量少的时候,每个服务实例可以自己维护相关服务实例的地址信息,也就是自己维护一个通讯录。
例如通过配置文件来记录,相关服务实例地址发生变更的时候就修改一下,有点麻烦,但还可以忍受。
但是,当服务实例数量变大之后,就无法自己维护了,相关服务数量多、地址变化频繁。
此时必须有一种更优的发现机制,就出现了服务注册中心。
文章图片
如上图,每个服务实例启动之后,都主动向注册中心登记自己的地址信息,这样注册中心便拥有了所有服务实例的记录,类似于查号台。
当某个服务实例停止运行的时候,主动让注册中心销毁自己的信息。
如果服务实例不是主动停止,而是因为故障等原因死掉的,如何处理?需要注册中心能够主动清理。
注册中心要能够实时知道各个服务实例的状态,通过心跳机制来实现,实例定时向注册中心发送请求,表明自己还活着,如果心跳没了,注册中心就可以对其清理。
文章图片
一个服务实例向调用另一个服务时,可以根据服务名称从注册中心获取此服务的实例信息列表,从中选取一个实例进行调用。
以上就是注册中心这种服务发现机制的工作方式。
3. 分布式配置概念简介
文章图片
每个服务都会有自己的配置信息,例如 SpringBoot 项目中的配置文件,服务运行时会读取配置文件中的配置项。
一个服务通常会启动多个实例,来提供其可靠性,那么每个实例中就都会包含这个配置文件,一个服务的各个实例中配置都是相同的。
如果要改某个配置项的值,怎么办?
修改配置文件,然后重新部署此服务的所有实例。麻烦低效。
文章图片
如果把服务的配置信息提出来,不放在自己的配置文件中,而是放到一个第三方的配置中心,服务实例从配置中心读取属于自己的配置,而且,在配置中心里面修改配置项之后,所有相关实例都可以立即拿到最新值,不用重新部署了,这样就方便很多。
所以分布式配置有2大好处:
- 方便维护,集中维护优于分散式维护每个服务的配置文件。
- 动态更新,配置修改后直接生效,不用重新部署。