在学习微服务的时候，我们都会听到两个词：注册中心、配置中心。
什么是注册中心呢？
解释这个问题前，要先了解下什么是微服务结构，就我个人的理解，以前一个大型项目，有许多模块，例如用户管理模块、系统管理模块、订单模块、商品模块、库存模块.........，整个项目可能单单java文件就能有几百上千个。这种大项目打一次war包可能就要几十分钟甚至几个小时，而且这种大项目在一个服务器上跑，浪费的资源是十分大的，而且访问量也低，这就是早期的单体项目。后来人们将这个大项目按模块拆开，各个模块自己作为一个web项目，彼此之间通过网络进行服务器间的通讯（RPC、webservice、HTTP等），各个模块自己随意部署，就渐渐演变成分布式项目。微服务和分布式其实是差不多的东西，都是将大项目拆解成小项目。
各个项目模块间通过网络进行通信，那各个项目就必须知道其他项目运行那哪一个机器上，IP是多少，端口是多少。如果我们部署的机器不多，而且都很固定，那我们可以直接写死在程序里。但是烦人的运维总是说机器性能不行，要把某个模块的项目部署多几个机器上，这样就又出现了一个新名词：集群。
这样子多部署几个项目虽然解决了性能和访问量的问题，但是频繁加机器减机器，就使得管理IP和端口变成了噩梦。于是乎，技术大佬们就开始想：能不能每次启动一个项目，就让他自己获取IP和端口，然后丢到网络上的某个地方，其他项目要用时就自己去取呢？为解决这个问题，大佬自己打算自己撸一个项目。这个项目就叫“IP端口管理中心”，只提供两个接口：1、接收别人发送的ip和端口信息并存储起来。2、查询并返回相应的IP和端口信息。其他人想要用我这玩意，就必须引入我提供的客户端jar，并在启动时调用我的客户端方法，去获取本机IP和端口，然后发送给“IP端口管理中心”。你要用时自己请求“IP端口管理中心”获取信息。
其实这个“IP端口管理中心”就是最原始版本的注册中心。其实这玩意并不复杂，只是现在市面上常用的注册中心都加入了很多功能，并且进行了性能优化，跟自己手撸的简单版本还是会有不少差距的。
市面上常见的注册中心有下面这几种：
其实注册中心在我们的开发使用上是非常简单的，注册中心实际上就是一个项目（或者说一个软件），我们使用它的步骤都很固定：
- 下载对应的注册中心
- 修改注册中心的配置文件
- 启动注册中心
- 我们的开发项目中引入注册中心的客户端jar
- 我们的代码上加入相应的注解或者配置
- 启动我们的项目
另外有一点要注意的是，eureka并不提供完整可运行的软件或者项目，eureka的依赖分成客户端依赖和服务端依赖，我们需要自己手动建一个新项目，如果加入eureka的服务端依赖，配置，然后启动这个项目，这个就是注册中心了。
这五种注册中心，consul、eureka、nacos是提供了管理页面的，zookeeper没有提供，coreDNS不知道，没用过。
nacos是阿里的产品，提供中文文档，其他都是英文文档。
eureka好像不再继续开发了。
我这里只说说Nacos的基本使用，其他注册中心自己网上百度。
Nacos的使用是非常简单的，基本上看看官网，跟着教程走一下，你就算入门了，熟练了。
官网：https://nacos.io/zh-cn/docs/what-is-nacos.html
官网上的下载地址时GitHub的，小水管，其他地方收费，自己上传云盘了，下载地址：https://wws.lanzous.com/ii7UVhrn8di
nacos下载后运行我曾出现了这个问题：
然后就是一闪而过，自动关闭。
看日志给我显示这玩意：
还以为是数据库连接问题，后来发现是因为nacos默认下载下来就是以cluster的方式运行的，并不是单机形式运行
打开bin/startup.cmd，进行编辑，修改MODE模式为standalone就可以正常启动了
具体的部署自己跟着官网走，我不多废话，https://nacos.io/zh-cn/docs/deployment.html
也可以看这篇文档https://github.com/alibaba/spring-cloud-alibaba/wiki/Nacos-discovery 更简单明了
另外nacos的一些参数配置可以看这个地址，https://nacos.io/zh-cn/docs/system-configurations.html
这是我自己玩的时候写的一些注释
# Spring Cloud Alibaba Nacos Config 目前提供了三种配置能力从 Nacos 拉取相关的配置。
# A: 通过 spring.cloud.nacos.config.shared-configs[n].data-id 支持多个共享 Data Id 的配置
# B: 通过 spring.cloud.nacos.config.extension-configs[n].data-id 的方式支持多个扩展 Data Id 的配置，或者ext-config
# C: 通过内部相关规则(应用名、应用名+ Profile )自动生成相关的 Data Id 配置
# 当三种方式共同使用时，他们的一个优先级关系是:A < B < C 注意：只会使用优先级最高的那个配置，低优先级的配置不加载
cloud:
nacos:
config:
enabled: true # 开启配置中心功能
server-addr: 127.0.0.1:8848
file-extension: yml # 如果配置后缀名不是properties，就必须声明
namespace: a4d88caf-5c3e-45f5-9021-04ec354b99ad # 指定命名空间，如果不是public，那么必须指定命名空间的id，注意，不是空间名
refresh-enabled: true # 运行自动刷新配置
group: DEFAULT_GROUP # 指定组
extension-configs: # 如果需要指定多个配置，可以使用这种方法
- dataId: test1.yml
- dataId: test2.yml
group: HONGCHENG_GROUP
refresh: true
# 配置项参考地址 https://github.com/alibaba/spring-cloud-alibaba/wiki/Nacos-discovery
discovery:
enabled: true # 开启注册中心功能
server-addr: 127.0.0.1:8848
# service: hongcheng # 服务名，默认为spring.application.name
group: hong # 服务分组名
weight: 4 # 负载均衡时的权重，1 ~ 100
# network-interface: # 当IP未配置时，注册的IP为此网卡所对应的IP地址，如果此项也未配置，则默认取第一块网卡的地址
# ip: 127.0.0.1 # 指定当前机器所在的ip地址，优先级最高，不写的话自动获取
# port: 9999 # 指定当应用使用的端口，优先级最高，不写的话自动获取
namespace: a4d88caf-5c3e-45f5-9021-04ec354b99ad # 命名空间id，不同命名空间的服务不能相互调用
说完注册中心，再说说配置中心
前面说过注册中心是因为机器数量过多，不易于管理而出现的，同样配置中心也是因为这种原因而诞生。
springboot的出现，本身就已经减少了我们的配置量，但是仍旧还是存在配置。在我们将大项目拆分成小项目后，我们的配置文件也同样裂变成了好几份，即便你两个小项目用的是同样的配置，你也要复制两次。一旦我们的小项目数量多了起来，那么管理这些配置将会让运维想跳楼。
而且一旦某个项目部署了十几二十个机器上后，你开发修改了某一个配置项，那就意味这必须重启这十几二十个机器上的项目。这时候运维可能在提刀过来砍你的路上。为了避免这种事情的发生，大佬又使出了第二套武功秘籍：再做一个项目专门管理配置项，也就是配置中心。
配置中心只需要做三件事就行：1、存储配置项。2、提供接口返回配置项。3、通过接口通知应用放弃之前的环境，重新根据配置项生成一个新的环境。市面上也有不少配置中心的产品，他们增加了挺多的扩展功能，我们直接用就好。
网上偷一张图说说各配置中心对比：
Spring Cloud Config 我觉得使用起来比较麻烦，而且他需要依赖git来存储配置文件，我不是很喜欢。
Apollo是携程的，不过我没用过。
Nacos是阿里的，可以做注册中心也可以做配置中心，用起来很简单，配置可以存在文件、MySQL、Redis中。
Nacos的配置中心文档可以看这个：https://github.com/alibaba/spring-cloud-alibaba/wiki/Nacos-config 通俗易懂，简单直接，用了你就会爱上
配置中心的使用步骤也很固定，跟使用注册中心的步骤完全一样的：
- 下载对应的配置中心
- 修改配置中心的配置文件
- 启动配置中心
- 我们的开发项目中引入配置中心的客户端jar
- 我们的代码上加入相应的注解或者配置
- 启动我们的项目
给你们看看nacos的管理界面
