bilibili/discovery
github 地址: https://github.com/bilibili/discovery
该库定性为: 使用 golang 复刻了下 euerka
介绍该库前,先看下 euerka
euerka
euerka 一个服务发现中间件
与市场上其他产品的比较如下 (摘自 https://www.liangzl.com/get-article-detail-12683.html ) :
Feature | Consul | zookeeper | etcd | euerka |
---|---|---|---|---|
多数据中心 | 支持 | — | — | — |
kv存储服务 | 支持 | 支持 | 支持 | — |
一致性 | raft | paxos | raft | — |
cap | ca | cp | cp | ap |
使用接口(多语言能力) | 支持http和dns | 客户端 | http/grpc | http(sidecar) |
watch支持 | 全量/支持long polling | 支持 | 支持 long polling | 支持 long polling/大部分增量 |
自身监控 | metrics | — | metrics | metrics |
安全 | acl /https | acl | https支持(弱) | — |
对比下特点很明显:简单
bilibili/discovery 与 euerka 比较
-
语言不同
- bilibili/discovery : golang
- euerka : java
-
官方比较,引用 bilibili/discovery 官方文档 如下:
相对Netflix Eureka的改进
- 长轮询监听应用变更(Eureka定期30s拉取一次)
- 只拉取感兴趣的AppID实例(Eureka一拉就是全部,无法区分)
- 合并node之间的同步请求/(ㄒoㄒ)/~~其实还没实现,是个TODO
- Dashboard骚操作~
- 多注册中心信息同步支持
- 更完善的日志记录
PS:Eureka2.0以上功能基本也要实现,但难产很久了/(ㄒoㄒ)/~~
-
补充说明
Dashboard骚操作~
,这是闭源的
工作原理
工作原理图如下(此图来自官方文档: https://github.com/bilibili/discovery/blob/master/doc/arch.md ):
三种身份进程:
- Discovery Server
- discovery 集群,身份为服务器端
- Service Provider
- 相对 discovery 集群,身份为客户端。通常是各种微服务
- Service Consumer
- 相对 discovery 集群,身份为客户端。通常是各种微服务
客户端相关操作 (各种微服务)
- register , 注册客户端信息
- renew ,就是心跳, 30 秒 1 次
- cancel ,反注册
- fetch ,全量拉取某类型服务列表 (实际包含:fetch/all 、 fetch 、fetchs 3 个命令 )
- poll ,增量拉取某类型服务列表(实际包含:poll 、 polls 2 个命令 )
除了图中的,还有以下操作:
- nodes ,获取 discovery 集群信息
- set ,更新客户端信息(比如用于
灰度更新
)
服务器相关操作 (discovery 集群)
- replication
- 客户端发过来的所有操作,都会广播给 discovery 集群内所有其他服务器节点进行数据同步
- 该操作提供了
弱一致性,最终一致性
特性
- evict
- 对心跳超时的客户端做踢除,受 protect 操作影响
- protect
- 网络闪断时自我保护模式。心跳数/客户端数 < 85% 时,判断为
网络闪断
- protect 期间,evict 无效;
- 心跳超时时间到达一个阈值,evict 无视 protect 机制做踢除
- 网络闪断时自我保护模式。心跳数/客户端数 < 85% 时,判断为
discovery 集群数据一致性原理
bilibili/discovery ( euerka ) 是 ap 型服务发现,强调服务可用性
discovery 集群上每个节点数据可能有过时的,但通过客户端请求策略、重试策略,总能找到可用的服务
这种特性通常称之为: 弱一致性或最终一致性
实现这种特性, bilibili/discovery ( euerka ) 做了以下事情:
- 客户端操作(register 、 cancel 、renew )都会广播给集群内其他节点进行数据同步
- 可能会失败,但是没关系
- 客户端定时 renew 操作,保证最终集群内所有节点数据一致
- 防止旧数据覆盖新数据,每次操作都带时间戳,集群中节点上的数据同样带上时间戳
大白话就是,不断的心跳、广播数据,纠正集群节点上错误的数据,最终达到数据一致性
discovery 集群自发现
discovery 集群不需要为自己特殊实现一种自发现方法
discovery 集群中的节点,把自己看作成普通的客户端,向 discovery 集群做 register 、 renew 、cancel 、fetch 、poll 操作,即可实现自发现
bilibili/discovery 特点与应用
- 简单
- 有 bilibili 3W+ 节点生产环境验证 (参见官方文档 https://github.com/bilibili/discovery/blob/master/doc/intro.md 中有提及生产环境服务规模)
- 可能存在过时数据(主要为某已失效节点还在 discovery 集群数据内)
- 客户端做好
重试策略
就可以回避失效节点
- 客户端做好
- 很适合微服务应用
- 网络游戏服务器架构中亦可应用
其他
bilibili/discovery 官方文档: https://github.com/bilibili/discovery/tree/master/doc
下篇做源码分析