注册中心
注册中心不提供负载均衡功能, 只提供一致性功能
注册中心介绍
无注册中心业务分析
说明:
1.使用传统的架构设计,所有的请求都经过NGINX负责中转,则nginx负载很大,如果nginx出现了问题,则直接影响用户.
2.如果服务器的数量改变了,则必然要修改nginx的配置文件.
需求: 1.保证nginx负载压力不要太高.
2.如果服务器数量发生变化,则可以自动的更新配置.,无需人为的干预
注册中心原理说明
原理说明:
1).当服务器启动时,会将自己的服务名称/IP:PORT写入注册中心.
2).当注册中心接收提供者数据时,会动态的维护服务列表数据.
3).当消费者服务器启动时,会链接注册中心.获取服务列表数据.
4).当请求注册中心之后,则将服务列表保存到本地(消费者内存中),方便以后使用.
5).根据已知的服务提供者 利用负载均衡机制挑选其中一个进行访问.
6).当注册中心利用心跳检查机制发现服务提供者宕机时,会"同步更新"注册列表,并且"同步所有消费者的服务列表".
为什么集中的节点数量是奇数台
公式: 剩余的主节点 > N/2 N为节点数量, 即主机数
分析: 以下计算中减一代表宕机一台主机
1个节点能否搭建集群? 1-1 > 0.5 假 不能搭建集群
2个节点能否搭建集群? 2-1 > 1 假 不能搭建集群
3个节点能否搭建集群? 3-1 > 1.5 真 可以搭建集群
4个节点能否搭建集群> 4-1 > 2 真 可以搭建集群
分析集群宕机的条件:
3个节点最多允许宕机1台. 奇数
4个节点最多允许宕机1台 偶数
奇数台和偶数台容灾能力相同.所以为了节省资源,一般集群都是奇数台.
结论:
- 搭建集群最小单位 3台.
- 一般集群搭建都是奇数台.
zookeeper
关于zookeeper注册中心的简介及在linux上安装, 请 [查看这里]
扩展: 微服务注册中心对比
为什么需要注册中心？
在RPC服务和微服务诞生的时候，就已经有了注册中心的需求了。
在最初的架构体系中，集群的概念还不那么流行，且机器数量也比较少，此时直接使用DNS+Nginx就可以满足几乎所有RESTful服务的发现。相关的注册信息直接配置在Nginx。但是随着微服务的流行与流量的激增，机器规模逐渐变大，并且机器会有频繁的上下线行为，这种时候需要运维手动地去维护这个配置信息是一个很麻烦的操作。所以开发者们开始希望有这么一个东西，它能维护一个服务列表，哪个机器上线了，哪个机器宕机了，这些信息都会自动更新到服务列表上，客户端拿到这个列表，直接进行服务调用即可。这个就是注册中心
CAP理论
CAP理论是分布式系统中一个很重要的理论，它描述的是一个分布式系统最多只能满足CAP中的两个条件，不可能同时满足三个条件
- C（Consistency）：这里指的是强一致性。保证在一定时间内，集群中的各个节点会达到较强的一致性，同时，为了达到这一点，一般会牺牲一点响应时间。而放弃C也不意味着放弃一致性，而是放弃强一致性。允许系统内有一定的数据不一致情况的存在
- A (Avalibility)：可用性。意味着系统一直处于可用状态。个别节点的故障不会影响整个服务的运作
- P（Partition Tolerance)：分区容忍性。当系统出现网络分区等情况时，依然能对外提供服务。想到达到这一点，一般来说会把数据复制到多个分区里，来提高分区容忍性。这个一般是不会被抛弃的
市面上比较流行注册中心有：Zookeeper，Eureka，Consul，Nacos
| 对比项目 | 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集成 | 支持 | 不支持 | 支持 | 支持 | 不支持 |
上图可以描述市面流行注册中心的一些特性
Zookeeper
Apache Zookeeper所选择的是CP，也就是放弃了高可用性。
为了达到C，Zookeeper采用的是自己的ZAB协议。这个协议的介绍之前写过一篇博客聊过，就不再赘述了
总得来说，Zookeeper集群在进行消息同步的时候，必须有一半以上结点完成了同步才会返回；而当Master结点挂了或者集群中有过半的结点不能工作了，此时就会触发故障恢复，重新进行Master选举。在这个过程中，整个Zookeeper集群无法对外提供服务，从而实去了A（可用性）
对于大多数的分布式环境来说，特别是数据储存的环境，数据一致性是非常重要的标准。但对于服务发现来说，其实并没有那么严格。就算一个注册中心没有及时获取到实时的服务实例状态，直接把服务列表（可能存在错误）发给客户端，也不会导致灾难性的错误。因为对于客户端来说会有重试机制，少数的实例无法访问不会导致大问题。
Eureka
Spring Cloud Eureka所选择的是AP，放弃了强一致性。
从使用角度来看，Eureka的特点就是使用Java语言来开发的，并且也是Spring Cloud的子项目，所以可以直接通过引入jar包的方式来集成Eureka，这点非常方便
而在架构上，Eureka集群采用的是去中心化结构。也就是说Eureka集群中的各个结点都是平等的，没有主从的概念。通过互相注册的方式来进行消息同步和保证高可用。并且一个Eureka Server结点挂掉了，还有其他同等的结点来提供服务，并不会引发服务的中断。从而来保证A
而在消息同步上，Eureka并不会对消息同步进行保证，既不保证消息正确地传播出去，也不保证接收者一定能接受消息。所以从服务注册角度来说，Eureka的速度是非常快的。但同样的也会带来一定的不一致性。但是之前也说了，在服务注册这种场景，一致性的要求其实并没有很高
另外，Eureka还有一个自我保护机制，用来应对网络问题导致的服务不可用，从而能更进一步地保证可用性。这一点我也在之前的博客有提到
Consul
Consul是HashiCorp公司推出的一个开源工具。它和Eureka一个区别就似乎，Consul是用Go语言编写的，所以无法像Eureka那样直接引入jar包就能集成，它还需要去服务器中进行额外的安装。
Consul的功能相比于Eureka来说也更加强大，因为除了注册中心的功能之外，Consul还能起到配置中心的作用。而Eureka只能当注册中心，想搞配置中心的话，还得搭配Spring Cloud Config+Spring Cloud Bus。其中后者支持Rabbiimq和Kafka两种模式。
Consul它保证的是CP，使用raft协议，要求必须有过半的结点都写入成功才算是注册成功了，并且它也有Master和Follower的概念，在Master挂掉后，也需要自己内部进行新一轮Master选举，在此期间，Consul服务不可用
Nacos
Nacos是阿里巴巴旗下的开源项目，在2018年开源。是Spring Cloud Alibaba的子项目。Nacos一大特性是即支持CP，也支持AP。可以根据需要灵活选择。
Nacos除了注册中心之外，也能充当配置中心的作用。且配置中心可以按照namespace，group等维度来进行数据隔离，来达到不同环境之间配置隔离的功能。
另外值得一提的是，Nacos作为配置中心的持久化机制可以依赖于Mysql来完成（默认依赖于内置数据库）。只需要将Nacos目录下的sql脚本放到mysql中执行（会生成11个表），然后在nacos配置文件里面配一下mysql的账号密码即可。这样使用mysql作为数据源的方式相比于nacos内置数据库来说更容易管理