SpringCloud+MySql+Redis+ES+security选型-注册中心和ES选型（二）|SpringCloud搭建CDCN-码上中国博客

摘要

本文主要讲述使用SpringCloud+MySql+Redis+ES+scurity搭建一个环境选择哪些Spring Cloud的组件，以及为什么要选择这些组件。

服务注册中心选型

spring cloud的服务注册中心，该选择谁？我们应该首先了解下他们的特性。目前我们经常使用的服务发现产品有如下几种：Feature、Consul、zookeeper、etcd、euerka。

他们之间的差异如下（当然，我们创建SpringCloud还是会在Consul 和euerka中选取，其他服务只是拿来比较以下）：

Feature	Consul	zookeeper	etcd	euerka
服务健康检查	服务状态，内存，硬盘等	(弱)长连接，keepalive	连接心跳	可配支持
多数据中心	支持	—	—	—
kv存储服务	支持	支持	支持	—
一致性	raft	paxos	raft	—
cap	cp	cp	cp	ap
使用接口(多语言能力)	支持http和dns	客户端	http/grpc	http（sidecar）
watch支持	全量/支持long polling	支持	支持 long polling	支持 long polling/大部分增量
自身监控	metrics	—	metrics	metrics
安全	acl /https	acl	https支持（弱）	—
spring cloud集成	已支持	已支持	已支持	已支持

大概解释下上面的部分特性：

所谓CAP，是指：

a) Consistency：一致性；就是在分布式系统中的所有数据备份，在同一时刻是否同样的值

b) Availability：可用性；就是负载过大后，集群整体是否还能响应客户端的读写请求

c) Partition tolerance ：分区容错性，就是高可用性；一个节点挂了，并不影响其它的节点

需要注意的是，三者不可能同时满足，最多只能满足其中两项；P是一定要满足的，不满足P是不可接受的；那么在C一致性和A可用性之间，就存在取舍。很显然，更多时候，我们更看重A可用性，而不需要实时的一致性，只需要最终一致即可；所以，满足AP更符合绝大多数项目的实际；

Zookeeper和Consul ：满足CP，保证了一致性，集群搭建的时候，某个节点失效，则会进行选举行的leader，或者半数以上节点不可用，则无法提供服务，因此可用性无法满足

Eureka：满足AP，无主从节点，一个节点挂了，自动切换其他节点可以使用，去中心化

从实际而言，一般除了一些特殊行业需要强调C一致性（例如金融、银行）以外，其他的系统更注重A可用性,

那么，我们就可以得出以下结论：对于金融类似的特殊行业有C一致性的强烈需求的，用Consul ；其他的，统统用Eureka；

在本文中，由于我们设计到的项目并非金融类产品，因此我们采用Eureka。

Elasticsearch java 客户端选型

目前elasticsearch 官方提供了两种java客户端，分别为java api（TransportClient）,java rest client(java rest又分为两种版本Java Low REST客户端和Java High Level REST Client）：

elasticsearch java 客户端选型

当然，我们经常使用的还包括一些其他的客户端，例如JestClient、Spring Data Elasticsearch

下面我们就来比较一下他们之间的特性：

	Java Low REST客户端	Java High Level REST Client	`TransportClient`	JestClient	Spring Data Elasticsearch
后续支持性	官方，支持	官方，支持，在6.0.0-beta1中添加	在7.0.0中弃用，8.0.0将删除，替代者为Java High Level REST Client	根据其托管在github上的代码显示，最近更新是在12个月之前（github）	pring Cloud 官方的一套ES方案，且宣称会一直支持最新版的ES，目前可支持到7.6.2版本的ES
对不同版本ES的支持性	兼容所有版本	-	不再评价-	向下兼容所有ES版本	Spring Cloude 和es的版本对应关系可以参见下面的图片或者官方说明
功能	依赖小，支持负载均衡，故障转移等	基于Java Low REST 客户端	不再评价-	对外宣称的优于ES官方API的安全、Rest、版本兼容问题，ES在自身Rest API中一并解决了	配置简单，配置化实现
API	基础API	在基础API上扩展了更多高级API用法，很丰富	不再评价-	丰富	丰富，阅读性差
性能	相同	相同	不再评价-	-	不错
交互方式	http		不再评价-	http	-
官方文档	详细	详细	不再平价	可在GitHub中查看	不是太详细
分析	基于http,因此依赖某些http的jar，同时使用ip+端口进行APi操作。	提供了快照、集群、机器学习等丰富的API，并且提供了迁移策略API，使用起来更加方便	不再评价-	ElasticSearch 已经具备应用于 Elasticsearch 内部的 Java API ，但是 Jest 弥补了 ES 自有 API 缺少 Elasticsearch Http Rest 接口客户端的不足但是目前一个现实是，ES已经有了个版本的rest版本。查看GitHub上的issue，返现很多人在询问jest client不支持更高版本的es(7.x)的解决方案，但是没人回应。jest Client 前途未仆啊。	SpringCloud目前官方文档不是太详细，且官方API文档阅读性并不是太好。

附图，pring Cloud 对elasticsearch的支持性

Sprign Cloud elasticsearch 版本支持

综上所述，我打算在实际生产开发中优先选择使用REST API的High-level API。

分类 Spring boot 开发

字数 2277

摘要

服务注册中心选型

Elasticsearch java 客户端选型

评论