前文分享etcd框架Go语言的实践,今天分享一下Java客户端的不分。再分享之前,先简单聊一下我查阅的资料的现状,以方便各位再开始Java客户端学习之前,有个心理预期。
etcd本身是Go语言编写的,所以在语言支持上,Go语言是支持的最好的。其他的就差强人意,这种场景有点像 Web3j
,有人再维护,但是从使用便捷程度上,总是不能一帆风顺直接上手。
而且还有一个原因,etcd的Java实现库太多了,各种库之间的细微差异也能让我搜索资料的时候难以准确找到最佳实践及其原理介绍。
大多数实现库都用了大量的异步操作,语法跟 Web3j
类似,我也不确定是哪种设计模式,如果你有 Web3j
使用经验,相信会更加容易上手。
Java 客户端比较
特性 | jetcd | etcd4j | spring-cloud-kubernetes | vertx-etcd-client |
---|---|---|---|---|
维护者 | etcd-io (CoreOS) | jurmous | Spring Cloud | Eclipse Vert.x |
etcd 兼容性 | v3 API | 主要支持 v2 API | v3 API | v3 API |
异步支持 | 是 | 是 | 是 | 是 |
依赖 | gRPC | Netty | Spring Cloud | Vert.x |
特点 | 官方支持,全面的功能 | 轻量级,简单易用 | 与 Spring Cloud 集成 | 与 Vert.x 生态系统集成 |
适用场景 | 大型项目,需要全面功能 | 简单使用,遗留系统 | Spring Cloud 项目 | Vert.x 项目 |
Watch 支持 | 是 | 是 | 是 | 是 |
事务支持 | 是 | 有限 | 通过 Spring 抽象 | 是 |
性能 | 高 | 中等 | 依赖 Spring 抽象 | 高 |
社区活跃度 | 高 | 低 | 高 | 中等 |
文档质量 | 详细 | 一般 | 详细 | 详细 |
学习曲线 | 中等 | 低 | 高(如果不熟悉 Spring) | 中等 |
详细比较
- jetcd
- 优点:
- 官方支持,与 etcd 版本同步更新
- 全面支持 etcd v3 API
- 性能优秀,适合大规模生产环境
- 缺点:
- 依赖较重(gRPC)
- 学习曲线可能稍陡
- 优点:
- etcd4j
- 优点:
- 轻量级,容易集成
- API 简单直观
- 缺点:
- 主要支持 etcd v2 API,对 v3 支持有限
- 社区更新较慢
- 不适合需要 v3 API 特性的新项目
- 优点:
- spring-cloud-kubernetes
- 优点:
- 与 Spring Cloud 和 Kubernetes 生态系统深度集成
- 提供服务发现和配置管理功能
- 缺点:
- 依赖 Spring 生态系统,不适合非 Spring 项目
- 可能引入不必要的复杂性(如果只需要简单的 etcd 客户端)
- 优点:
- vertx-etcd-client
- 优点:
- 与 Vert.x 生态系统集成
- 非阻塞 API,适合高并发场景
- 缺点:
- 与 Vert.x 绑定,不适合非 Vert.x 项目
- 社区相对较小
- 优点:
Java 客户端实践
下面我选择 jetcd
作为实现库,首先我们添加依赖项目:
如果你再运行当中遇到了 Exception in thread "main" java.lang.NoClassDefFoundError:
此类错误,请检查服务端版本,gRPC版本,客户端版本,以及依赖项缺失。这也是劝退的原因之一。
接下来我们来看Case,除了读写以外,我增加了监听的用例。总体来讲,语法比较熟悉 (我用过 Web3j
),下面是两个简单的例子,用来演示 jetcd
的基本使用。
下面我们来依次执行两个方法:
下面是控制台打印:
可以看到是满足预期的。但是问题来了,JVM进程就是不退出,比较尴尬,即使我们加上关闭客户端的方法 client.close()
也不行,打开线程转储之后发现好几个 RUNNABLE
的线程,还有一个 forkjoin
线程池,现象跟 Web3j
很像,但是这次跟 Netty
相关,我也懒得深究原因了。