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