不知道有没有考虑过这样一个问题，为什么要注册中心呢？以及注册中心该如何的选择呢？还是默认的哪个是最新的，哪个用的人多，就选用哪个呢？
服务之间的互相调用时，需要服务端开启服务，客户端进行对接。但是，想一下，客户端想要发送一个请求到服务端的时候，需要什么数据呢？ ip地址，端口号等等吧。在只有一个客户端和一个服务端的情况下，这些ip地址可以在客户端的配置文件中写死即可。
如果是多个服务端进行发布服务呢？或者如果在配置文件中写死的server3宕机了呢？那是不是需要再次修改配置文件中的ip呢？这样一来，注册中心就解决了这个问题，客户端调用的时候去注册中心获取服务端信息（ip，端口等等），获取信息之后，再进行调用，如果需要加服务，或者服务宕机，只需要修改注册中心的信息即可。
注册中心就是存储一些服务信息，负责服务的注册与发现。有新的服务启动即在注册中心填写自己服务的基本信息。有服务宕机，注册中心通过自己的一些机制，把宕机的服务信息进行剔除，通过这样的方式让客户端动态的知道服务的最新信息。但是一旦注册中心出现问题，比如断网了，或者宕机了，那么整个服务的调度就会出问题，这一块也需要注意一下。
1.常见的注册中心
1.1 Zookeeper
我觉得现在如果还是在用dubbo框架的公司注册中心基本上都是zk作为注册中心。毕竟是官方推荐使用的注册中心。
zookeeper是一个基于CP设计的，zookeeper提供了watch机制，watch机制是一个发布订阅的功能。观察者订阅自己感兴趣的主题，比如订阅服务器节点的变化。如果zookeeper节点发生变化，会推送给订阅了此节点的观察者。通过这种方式，实现了服务器宕机，或者新的服务注册进来告诉客户端更新服务端信息。
优点就是数据一致性做的好，缺点当然也有。zookeeper集群中有三种角色（zookeeper服务器节点），它们分别是：群首（leader），追随者（follower），观察者（observer）。在leader宕机之后，总要选择出一个leader来领导大家工作呀，这个时候需要选举出一个新的leader。在选举的这段时间整个集群的状态是不可用的。
1.2 Eureka
dubbo推荐用zookeeper作为注册中心，spring cloud推荐的是Eureka。都是官方推荐的注册中心，想必这两个一定各有优点。
eureka是基于AP设计的。eureka集群是一个去中心化的架构，没有master/slave的区分。这样的好处就是即使eureka集群中有一个服务不可用了，那么其他的服务还是可以进行工作的。
缺点就是eureka没有类似zookeeper中的watch机制，服务的注册与发现是通过心跳来判断的。就比如服务端有新增或者剔除操作，客户端需要隔一段时间才能知道。
2. Nacos的不同之处
Nacos 默认登录密码 nacos/nacos
Nacos提供了可视化管理页面，Nacos 控制台主要旨在于增强对于服务列表，健康状态管理，服务治理，分布式配置管理等方面的管控能力，以便进一步帮助用户降低管理微服务应用架构的成本，将提供包括下列基本功能:
- 配置管理
- 多种配置格式编辑
- 编辑DIFF
- 示例代码
- 推送状态查询
- 配置版本及一键回滚
- 服务管理
- 服务列表及服务健康状态展示
- 服务元数据存储及编辑
- 服务流量权重的调整
- 服务优雅上下线
- 命名空间
- 登录管理
2.1 Nacos配置管理
如果有如下需求
- 服务不能重启，修改限流数量。
- 服务太多了，如果数据库连接信息在各个服务中配置，如果有改动怎么办?每个服务都改一下？如果服务不能重启，可不可以实现呢？
- 有测试环境，生产环境，要配置的东西太多了，可不可以统一管理一下呀。
- 配置文件的内容可不可以实现实时的修改呢？
如果只是普通的业务开发，这些需求可能不需要关心，技术大佬想怎么配置就怎么配置，小弟默默跟随就好，但是如果是站在架构师的角度上，这些东西不得不考虑。Nacos提供了配置管理，可以更方便的实现动态更新。
2.1.1 配置列表
zookeeper一般只是用来服务的注册，eureka有config组件，但是没有可视化的配置。
Nacos可视化配置页面
在右边加号即可新增配置或者修改配置
- data Id：Nacos 中的某个配置集的 ID。配置集 ID 是组织划分配置的维度之一。Data ID 通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集，每个配置集都可以被一个有意义的名称标识。Data ID 通常采用类 Java 包（如 com.taobao.tc.refund.log.level）的命名规则保证全局唯一性。此命名规则非强制。
- group: Nacos 中的一组配置集，是组织配置的维度之一。通过一个有意义的字符串（如 Buy 或 Trade ）对配置集进行分组，从而区分 Data ID 相同的配置集。当您在 Nacos 上创建一个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用 DEFAULT_GROUP 。配置分组的常见场景：不同的应用或组件使用了相同的配置类型，如 database_url 配置和 MQ_topic 配置。
官方这么说，搞的我也是有点梦。还是直接上手吧，自己玩玩就直到咋回事了。
有如上配置
dataId：example.properties
group：DEFAULT_GROUP
内容：didispace.title=spring-cloud-alibaba-learning123123
md5: 这个是用来校验客户端配置文件是否与注册中心一致用的，这个不需要我们来修改。（快速比对两条消息是否一致，可以通过消息的hash值来比对，也可以使用md5来比对）
如果想要获取这些配置需要先修改bootstrap.properties,这里注意是哪个配置文件，别改成application.properties了。
#这里是注册中心的地址 spring.cloud.Nacos.config.server-addr=127.0.0.1:8848 #data ID的名字要和这里这两个对应起来，如果是yml格式下面也要改成yml spring.application.name=example spring.cloud.Nacos.config.file-extension=properties
启动：
@SpringBootApplication
public class NacosConfigApplication {
public static void main(String[] args) {
SpringApplication.run(NacosConfigApplication.class, args);
}
@RestController
@RefreshScope
static class TestController {
@Value("${didispace.title}")
private String title;
@GetMapping("/test")
public String hello() {
return title;
}
}
}
通过如上代码即可进行测试。我在这里不多解释，官网直接下载即可使用。
2.1.2 历史版本
Nacos通过提供配置版本管理及其一键回滚能力，帮助用户改错配置的时候能够快速恢复，降低微服务系统在配置管理上的一定会遇到的可用性风险。
不知道是我版本的bug还是哪里的问题，这里必须要输入data Id和group 才能查询到版本历史，默认的列表是没有信息的。
2.1.3 监听者查询
Nacos提供配置订阅者即监听者查询能力，同时提供客户端当前配置的MD5校验值，以便帮助用户更好的检查配置变更是否推送到 Client 端。
可以通过md5或者hash值来快速比对两条数据是否一致。
2.2 Nacos服务管理
服务列表帮助用户以统一的视图管理其所有的微服务以及服务健康状态。整体界面布局是左上角有服务的搜索框和搜索按钮，页面中央是服务列表的展示。服务列表主要展示服务名、集群数目、实例数目、健康实例数目和详情按钮五个栏目。
2.2.1 服务流量权重支持及流量保护
Nacos 为用户提供了流量权重控制的能力，同时开放了服务流量的阈值保护，以帮助用户更好的保护服务服务提供者集群不被意外打垮。如下图所以，可以点击实例的编辑按钮，修改实例的权重。如果想增加实例的流量，可以将权重调大，如果不想实例接收流量，则可以将权重设为0。
2.2.2 服务元数据管理
Nacos提供多个维度的服务元数据的暴露，帮助用户存储自定义的信息。这些信息都是以K-V的数据结构存储，在控制台上，会以k1=v1,k2=v2这样的格式展示。类似的，编辑元数据可以通过相同的格式进行。例如服务的元数据编辑，首先点击服务详情页右上角的“编辑服务”按钮，然后在元数据输入框输入：version=1.0,env=prod。
2.2.3 服务优雅上下线
Nacos还提供服务实例的上下线操作，在服务详情页面，可以点击实例的“上线”或者“下线”按钮，被下线的实例，将不会包含在健康的实例列表里。
官方资料：