服务注册与发现

传统单体架构与分布式架构

单体架构的不足：

1. 所有的服务都集中在一个应用中，一个服务出错，可能导致整个系统宕机
2. 随着用户越来越多，程序承受的并发越来越高，单体应用的并发能力有限。
3. 数据库瓶颈，大量读写操作会直接干死数据库。

分布式架构服务之间调用问题

1. 采用restTemplate或者httpClient等远程调用工具，直接写死服务地址。
2. 直接写死地址，请求永远都只会打到一台服务器，如果提供服务是集群模式，提供服务的只有一台机器
3. 这是可以在集群的机器上加上负载地址来解决直接写死地址的问题。
4. 当集群增加一台机器时，则需要对负载配置更改。

当服务越来越多的时候，服务之间的调用越来约复杂，此时，则需要一个东西用来解决服务的注册问题，将所有服务集中管理。

服务注册与发现理论

​ 如A服务有多台机器，则通过注册中心，将所有的服务注册到注册中心，注册中心维护一张注册表。

​ 当B服务想要调用A服务时，通过注册中心拉取注册表信息，通过负载算法获取一台存活的A服务机器，调用A服务。

当A服务有变动时，

1. 当新增A服务时，通过给注册中心注册服务，注册中心实时更新注册表信息

2. 当减少A服务时，注册中心通过一个健康检查机制更改注册中心注册表信息。

可实时更改A服务可提供服务的数量，地址等信息

关于健康检测机制:

​ 每个服务都会开启一个定时任务，定期向服务注册中心发送一个心跳请求。如果超过指定时间没有发送到服务注册中心，则注册中心会认为这个服务暂时不可用。

二次确认，当服务暂时不可用之后，设定一个时间，如果这个时间内，这个服务还未有心跳请求，则注册中心会认为该服务挂掉了。则从注册表中删除该服务。

服务每次调用之前是否都需要向注册中心拉取可用服务

每次都去请求一次服务地址，大大的降低的效率，所以需要一个机制去更新这些地址。

每个服务都应该有一个调用服务的缓存列表，将所有的服务都缓存起来。每次调用之前从本地缓存中通过负载均衡获取一个服务调用。

常见注册中心

	NACOS	EUREKA	CONSUL	COREDNS	ZOOKEEPER
一致性协议	CP+AP	AP	CP	–	CP
健康检查	TCP/HTTP/MYSQL/CLIENT BEAT	CLIENT BEAT	TCP/HTTP/GRPC/CMD	–	KEEP ALIVE
负载均衡策略	权重/metadata/selector	Ribbon	Fabio	RoundRobin	–
雪崩保护	有	有	无	无	无
自动注销实例	支持	支持	支持	不支持	支持
访问协议	HTTP/DNS	HTTP	HTTP/DNS	DNS	TCP
监听支持	支持	支持	支持	不支持	支持
多数据中心	支持	支持	支持	不支持	不支持
垮注册中心同步	支持	不支持	支持	不支持	不支持
SpringCloud集成	支持	支持	支持	不支持	支持
Dubbo集成	支持	不支持	支持	不支持	支持
K8S集成	支持	不支持	支持	支持	不支持