核心服务-注册中心
原创
©著作权归作者所有：来自51CTO博客作者wx58c2b58cac641的原创作品，请联系作者获取转载授权，否则将追究法律责任
前言
ZK功能
文件系统
数据存储是文件机制非文件存储
所有节点在zk中都是一个树
通知机制
分布式程序协调服务
节点选主
图1
上图是应该基于zk选主的模式
zk内部主从模式：本身主节点挂了 使用ZAB协议选主
配置管理
zk的叶子节点当然也可以存储超时时间等配置信息 只是不优雅
粗力度分布式锁
zk和etcd都可以做分布式锁
etcd社区比较活跃 性能较好
主备高可用切换
主节点挂了 从节点选主的过程 类似图1
主挂了 zk心跳知道主挂了
从3个slave节点中 选择主
谁写成功 谁就是主
服务注册发现
注册和发现不是zk擅长的 用的比较多
前面几点才是zk擅长的 但用的不多
服务注册和发现产品比较
1、ZAB是Paxos轻量级实现
2、Euraka追求数据最终一致性 所以不需要一致性保证
(apollo配置中心内部是用euraka做的)
3、多数据中心就是多机房
在多个机房中只部署了一套zk
一旦出现了网络划分 整个zk节点就不可用
只有consul可用 基于同步协议Gossip来做的
redis cluster也是用的Gossip协议来实现的
(Gosship 是明文传呼 可以先加密数据再通过该协议传输或者内部服务之间明文传输也没有关系)
4、所有CP模型都是支持KV存储的
5、
a、zk服务健康检查其实很弱
仅仅支持心跳 实质tcp层面的ping
服务假死情况 它发现不了
b、consual服务健康检测做的比较好
c、euraka最弱
默认配置不支持 必须要显示做一些配置
d、metrics 埋的一些点 记录请求响应时间 耗时情况
Long Polling
zk不是服务发现领域最佳选择
1、服务注册发现是AP模型 ZK是CP模型
2、几百台zk集群 最多1000台 没有问题
超过了一定的数量比如几万台 zk就会不堪重负
服务注册发现是AP模型还是CP模型?要从数据一致性需求分析
注册中心作用：丢给注册中心一个 server name返回一个对应的ip和port
如果调用方获取到的服务器给的ip不一样 会有什么影响？
服务注册发现对数据一致性要求不高 最终一致性即可
在多个机房中只部署了一套zk
一旦出现了网络划分 整个zk节点就不可用
假设 机房3突然和机房2和机房1的网络断了
即机房3出现了网络分区 网络划分
机房间网络划分
机房3 机房内还是通的
理论层zk集群还可以用
实际情况整个zk集群都不可用了
一旦网络发生分区 就会选举多个主节点 就会不一致了
原因是
ServerB2作为新服务 此时注册ZK不成功
因为机房3中的ZK节点已经脱离了ZK集群
不能通过ZK对服务进行扩容、重启、部署
期望的效果
期望的是跨机房不可用但机房3中的ServiceA调用ServiceB是可以用的
虽然说有多机房 很多情况下更鼓励在同一个机房内服务之间调用
机房内服务调用 服务内响应延迟会变的很低
服务每个机房都成了孤岛 每个机房调用只拿到本机房的服务列表
反而有更好的服务链路调用效果
千万不能因为自身的任何问题 破坏了服务之间的联通性
原生ZK
但原生的ZK同机房的服务调用也不可用
因为ZK是CP模型
为了保证网络分区下P （脑裂下）C一致性 A的可用性也让它不可用
ZK存储了大量的信息
1、写到zk里面的任何一个写操作 为了保证cp
都会在从节点上都会在写一份
2、keepalive 、心跳信息、节点注册 全部都会在集群中同步
3、服务发布大量注册写请求
4、毫秒级服务健康状态的写请求
ZK集群最多支持1000台
zk是分布式的
根据paxios协议 选zk主 zk从
zk主 是写入单点 不能水平扩展
从节点可以扩展
类似mysql 主从
主只能有一个
zk集群规模不能很多 1000台撑死了
集群有1万台 就会不堪负载
根据业务功能 垂直拆分集群?
根据业务功能 垂直拆分集群
58 房产、招聘、二手车
房产有自己的zk集群
招有自己的zk集群
二手车有自己的zk集群
破坏了公司整体服务的连通性
彼此不可以调用了
业务整合联通性不可预知
比如搜索业务1000台机器zk
推荐业务1000台机器zk
若将搜索和推荐做一个集群
zk 2000台 就不行了
为什么zk 到1000台就不行了？
有大量的持久化存储和事务
ZK 2PC 两阶段提交事务
leader和其他节点数据提交 全部是二阶段提交 2PC(Propose ACK Commit)
强一致性 每一步都是2pc 同步阻塞写
ZK探活机制
track机制即tcp长连接 向网络发一个ping命令
logic1服务死了 zk不知道
因为zk的KeepAline机制太弱了 太浅层了
应该怎么处理?
1、tcp活性探测即每隔段时间心跳检测 如果服务死了就踢出
2、服务健康与否的逻辑开放给服务方 让服务方自定义
zk server只管服务方定制的状态
具体死活 zk不需要判断
注册中心容灾
zk原生客户端有很多问题
zk clinet和zk server很多情况下是弱依赖
很多情况下 不需要与zk强依赖
zk的ip节点存在本地 每次启动会从zk拉取
如果拉不到 用本地ip
需要强依赖的场景就是服务发布、上下线、扩容
zk原生客户端没有缓存数据机制(没有缓存ip列表)
综上:zk完全不适合做注册中心
ZK使用场景
这些组件的分布式协调器都是zk
如何模拟网络异常
如果模拟服务假死
自研数据中心如何设计
注册中心业务流程及熔断机制
1、服务管理平台：服务展示、调用关系展示（梳理服务之间调用关系）以及入口、参数配置（超时时间、熔断规则、降级规则、IP:Port）、控制中心注册信息、
有自己的db存储
2、服务发现不需要直接连接控制中心
3、熔断极端情况下 熔断不了 影响也不大 可损
4、
服务管理平台不需要和业务逻辑层交互
业务逻辑层需要和服务管理平台交互
（服务质量情况 监控 流量情况）
5、服务控制：注册信息存储、指令下发
6、控制中心（服务版本信息、ip:port、服务名称） 无状态化 多个节点 多个控制中心之间 指令同步
控制中心多个节点服务相互探活
7、全部都是服务集群 熔断其中一台数据访问层
推送给业务逻辑层的所有集群
8、服务发现方第一次获取服务列表 若拿不到就采用本地配置
上线的时候 肯定是知道 下游是哪一台
拿到的信息更新本地配置
9、推送指令有没有到达业务逻辑层？
ccp和控制中心通讯
长连接推送
给ack
没有给ack再推送
10、服务管理平台也会在内存中缓存一份
缓存有脏数据 无所谓 流量不均衡而已
11、服务管理平台还是控制中心 全是去中心化的
12、熔断是针对api粒度的
服务权重配置
机器配置高 允许流量高 权重配置高些 比如10 其他就是8
服务分组
物理隔离
后续
