SpringCloud+MySql+Redis+ES+security选型-注册中心和ES选型(二)

作者:青山常在人不老   阅读 (1484)  |  收藏 (0)  |  点赞 (0)

摘要

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


原文链接:SpringCloud+MySql+Redis+ES+security选型-注册中心和ES选型(二)

服务注册中心选型

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

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

FeatureConsulzookeeperetcdeuerka
服务健康检查服务状态,内存,硬盘等(弱)长连接,keepalive连接心跳可配支持
多数据中心支持
kv存储服务支持支持支持
一致性raftpaxosraft
capcpcpcpap
使用接口(多语言能力)支持http和dns客户端http/grpchttp(sidecar)
watch支持全量/支持long polling支持支持 long polling支持 long polling/大部分增量
自身监控metricsmetricsmetrics
安全acl /httpsaclhttps支持(弱)
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 ClientTransportClientJestClientSpring 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

博客标签    SpringCloud搭建  

评论