服务注册与发现
传统单体架构与分布式架构
单体架构的不足：
- 所有的服务都集中在一个应用中，一个服务出错，可能导致整个系统宕机
- 随着用户越来越多，程序承受的并发越来越高，单体应用的并发能力有限。
- 数据库瓶颈，大量读写操作会直接干死数据库。
分布式架构服务之间调用问题
- 采用restTemplate或者httpClient等远程调用工具，直接写死服务地址。
- 直接写死地址，请求永远都只会打到一台服务器，如果提供服务是集群模式，提供服务的只有一台机器
- 这是可以在集群的机器上加上负载地址来解决直接写死地址的问题。
- 当集群增加一台机器时，则需要对负载配置更改。
当服务越来越多的时候，服务之间的调用越来约复杂，此时，则需要一个东西用来解决服务的注册问题，将所有服务集中管理。
服务注册与发现理论
如A服务有多台机器，则通过注册中心，将所有的服务注册到注册中心，注册中心维护一张注册表。
当B服务想要调用A服务时，通过注册中心拉取注册表信息，通过负载算法获取一台存活的A服务机器，调用A服务。
当A服务有变动时，
当新增A服务时，通过给注册中心注册服务，注册中心实时更新注册表信息
当减少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集成 | 支持 | 不支持 | 支持 | 支持 | 不支持 |
