注册中心原理及选型
2022-03-29 15:49:41 2 举报AI智能生成
注册中心原理及选型
作者其他创作
大纲/内容
注册中心对比
注册中心选型
CP 还是 AP 的选择
选择 AP。因为可用性高于一致性，所以更倾向 Eureka 和 Nacos。
技术体系
etcd和Consul都是Go开发的Eureka、Nacos和Zookeeper都是Java 开发的，可能项目属于不同的技术栈，会偏向选择对应的技术体系；
高可用
这几款开源产品都已经考虑如何搭建高可用集群，有些差别而已；
产品的活跃度
这几款开源产品整体上都比较活跃
注册中心基本概念
注册中心主要角色
服务提供者（RPC Server)
服务消费者（RPC Client）
服务注册中心（Registry）
注册中心需要实现功能
注册中心的API
服务注册接口
服务提供方调用注册接口完成服务注册
服务注销接口
服务提供方调用注销接口完成服务的下线
心跳检查
服务提供方通过心跳汇报接口完成服务状态上报
服务查询
消费者通过订阅或者定时拉去服务列表信息
服务变更查询
当服务发生变更的时候消费者通过变更服务获取到最新的服务信息
服务的高可用
存储格式和位置
服务健康检查
服务变更状态通知
白名单机制
生产隔离
注册中心基础
CAP理论
C 一致性（Consistency）
所有节点在同一时间具有相同的数据
A 可用性（Availability）
每次请求都能获取到正确的响应，但是不保证获取的数据为最新数据。
P 分隔容忍（Partition tolerance）
分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务
分布式系统一致性协议
Paxos 算法
Raft 算法
ZAB 算法
常用注册中心
ZooKeeper
特点介绍
实现原理
RPC 服务注册与发现过程
Eureka
特点介绍
可用性（AP 原则）
去中心化架构
请求自动切换
节点间操作复制
自动注册与心跳
自动下线
保护模式
工作流程
Nacos
特点介绍
服务发现
服务健康监测
动态配置服务
动态 DNS 服务
生态
spring-cloud生态
dubbo生态
k8s生态
nodejs生态(egg/midway)
Consul
主要特征
CP模型，使用 Raft 算法来保证强一致性，不保证可用性；
支持服务注册与发现、健康检查、KV Store 功能；
支持多数据中心，可以避免单数据中心的单点故障，而其部署则需要考虑网络延迟, 分片等情况等；
支持安全服务通信，Consul 可以为服务生成和分发 TLS 证书，以建立相互的 TLS 连接
支持 HTTP 和 DNS 协议接口
官方提供 Web 管理界面
调用过程
多数据中心
etcd
特点介绍
易使用
易部署
强一致
高可用
持久化
快速
安全
ETCD 框架
HTTP Server
Store
Raft
WAL
0 条评论
下一页
