logic1服务死了 zk不知道 因为zk的KeepAline机制太弱了 太浅层了
应该怎么处理?
1、tcp活性探测即每隔段时间心跳检测 如果服务死了就踢出 2、服务健康与否的逻辑开放给服务方 让服务方自定义 zk server只管服务方定制的状态 具体死活 zk不需要判断
注册中心容灾
zk原生客户端有很多问题
zk clinet和zk server很多情况下是弱依赖 很多情况下 不需要与zk强依赖 zk的ip节点存在本地 每次启动会从zk拉取 如果拉不到 用本地ip 需要强依赖的场景就是服务发布、上下线、扩容 zk原生客户端没有缓存数据机制(没有缓存ip列表)
综上:zk完全不适合做注册中心
ZK使用场景
低频事务适合（tps低的）
这些组件的分布式协调器都是zk
如何模拟网络异常
zk集群其中一台机器网络断掉或防火墙进出设置下
如果模拟服务假死
在业务逻辑层while(True)
自研数据中心如何设计
注册中心业务流程及熔断机制
1、服务管理平台：服务展示、调用关系展示（梳理服务之间调用关系）以及入口、参数配置（超时时间、熔断规则、降级规则、IP:Port）、控制中心注册信息、 有自己的db存储 2、服务发现不需要直接连接控制中心 3、熔断极端情况下 熔断不了 影响也不大 可损 4、 服务管理平台不需要和业务逻辑层交互 业务逻辑层需要和服务管理平台交互 （服务质量情况 监控 流量情况） 5、服务控制：注册信息存储、指令下发 6、控制中心（服务版本信息、ip:port、服务名称） 无状态化 多个节点 多个控制中心之间 指令同步 控制中心多个节点服务相互探活 7、全部都是服务集群 熔断其中一台数据访问层 推送给业务逻辑层的所有集群 8、服务发现方第一次获取服务列表 若拿不到就采用本地配置 上线的时候 肯定是知道 下游是哪一台 拿到的信息更新本地配置 9、推送指令有没有到达业务逻辑层？ ccp和控制中心通讯 长连接推送 给ack 没有给ack再推送 10、服务管理平台也会在内存中缓存一份 缓存有脏数据 无所谓 流量不均衡而已 11、服务管理平台还是控制中心 全是去中心化的 12、熔断是针对api粒度的
服务权重配置
机器配置高 允许流量高 权重配置高些 比如10 其他就是8
服务分组
物理隔离
后续
后续会推出配置中心实践
