微服务架构(2)——注册中心

目录：

1、为什么需要注册中心
2、注册中心技术组件选型
3、注册中心搭建
4、注册中心原理

为什么需要注册中心

将一个项目拆分成多个服务之后，服务之间就可能会相互进行调用通讯，来完成一个完整的功能。如果A服务要调用B服务，那么A服务是如何知道B服务的地址和端口的呢？总不能在配置文件里面写死吧。这样的话要是B服务增加一个实例，那不是就要去修改这个配置。或是B服务有个实例挂掉了，由于配置文件没有修改，A服务还一直在调用这个挂掉的实例。所以这就需要注册中心了。所有服务启动后都会把地址和端口等相关的信息注册到注册中心里，其它服务需要调用的时候就去注册中心拿这个服务的地址和端口进行调用。当有新的实例增加,注册中心对应的实例服务地址和端口信息也会增加，有实例减少则对应的地址和端口信息会被剔除。

注册中心技术组件选型

目前市面上用的比较多的注册中心大概就是 ZooKeeper、Eureka、Consul、Nacos这四种，我们就基于这四种注册中心来做选型。

数据模型

注册中心最主要的功能就是用来保存服务的名字和服务对应的地址和端口信息（如上一张图所描述的信息），由于一个服务可能会存在多个实例（如上图 服务A和服务B都部署了两个实例）。那么就需要对不健康的实例进行过滤，不可能说有实例挂了注册中心还一直保存着这个实例信息，提供给别的服务进行调用。那这个时候就需要在实例上存储一些例如健康状态的这种信息，表明这个实例是否能正常提供服务。随着用户量的增大，可能我们又会部署更多的实例，而且为了保证服务的高可用，还可能会进行多机房部署。那可能还需要对相同服务但部署在不同机房的实例来做一个区分。

Zookeeper的数据是K-V的形式存储的，因此理论上可以存储任何语义的数据，它并没有针对服务发现设计数据模型，因为它最初的定位并不是作为注册中心来使用的。而Eureka和Consul都是做到了实例级别的数据扩展，这可以满足大部分的场景，一般来说中小型公司已经够用了，不过无法满足大规模和多环境的服务数据存储。Nacos则是服务-集群-实例的三层数据模型，基本可以满足服务在所有场景下的数据存储和管理。

数据一致性

在分布式系统中CAP，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance），要么选择CP,要么选择AP。要想保证一致性那么就要牺牲可用性，想要保证可用性就要牺牲一致性。

Zookeeper是典型的CP模型，Zookeeper会有一个leader节点负责写数据，然后同步数据给其follower节点。follower节点可以进行读，不能进行写。要是leader节点挂了，那么就要从follower节点中选举出leader，然后进行数据同步，等数据都同步完成了，保证所有节点数据是一致的时候才能进行读操作。那么在选举leader和做数据同步这段时间，Zookeeper是不能进行读写操作的，也就是这段时间不可用。

Eureka是AP模型的，Eureka所有节点都可以进行读写,一个节点被写入数据后会异步复制给其它节点，要是有一个节点挂了，其它节点还能够继续提供读写的操作，所以服务对外仍然是可用的。但是要是这个节点接收到一条写的数据后，然后在复制给其它节点的过程中这个节点就挂了，那么就会导致有的节点可能复制成功了，有些节点就没有复制成功，这样就导致了数据的不一致。

Consul CP模型。

Nacos CP模型和AP模型都支持，可以通过配置来决定是使用哪种。

健康检测机制

Zookeeper和Eureka都是基于TTL的机制，就是如果客户端会隔一段时间（例如 10s 发送一次）向注册中心发送心跳，注册中心接受到了这个心跳就任务这个服务是正常的。如果很长一段时间都没有收到客户端发来的心跳（例如 90s 都没有收到心跳了），那么注册中心就任务这个客户端挂了，就会把这个客户端剔除。

Nacos也支持TTL的机制，发送心跳的周期默认是5秒，Nacos服务端会在15秒没收到心跳后将实例设置为不健康，在30秒没收到心跳时将这个临时实例摘除。
但是有些服务无法向注册中心发送心跳，比如说redis,mysql。所以Nacos也添加了TCP,HTTP,和MYSQL的检查方式。
TCP：Nacos会去和某个服务创建连接，500ms后看连接是否创建成功，成功说明这个服务正常。
HTTP：Nacos发送HTTP请求给某个服务，返回200说明服务正常。
MYSQL：Nacos执行一条Sql，看一下执行是否成功，成功说明正常。

Consul的健康检查支持的也挺好，也能支持TTL、TCP和HTTP的方式。

性能与容量

Zookeeper在写性能上能达到上万的TPS，容量也能够达到百万级别，但是当有大量的实例上下线时，Zookeeper的表现并不稳定，并且集群节点增多的时候，就需要同步数据到更多的节点，就会导致写的性能下降。集群节点太少，又会导致读的性能差。

Eureka服务实例规模在5000左右的时候，就会出现服务不可用的问题，甚至在压测的过程中，如果并发的线程数过高，就会造成Eureka crash。不过对于中小型公司来讲这个容量已经够用了。

Nacos在开源版本中，服务实例注册的支撑量约为100万，服务的数量可以达到10万以上。在实际的部署环境中，这个数字还会因为机器、网络的配置与JVM参数的不同，可能会有所差别。

注册中心搭建

经过上面的对比，感觉还是Nacos更胜一筹，下面就基于Nacos搭建注册中心。

拉取代码

从github拉取Nacos代码，地址：https://github.com/alibaba/nacos.git。

拉取速度比较慢，需要耐心等待。

导入idea

在idea中，File —》Ope