SpringCloud注册中心集群化及如何抗住大型系统的高并发访问

一、场景引入

本人所在的项目由于直接面向消费者,迭代周期迅速,所以服务端框架一直采用Springboot+dubbo的组合模式,每个服务由service模块+web模块构成,service模块通过公司API网关向安卓端暴

露restful接口,web模块通过dubbo服务向service模块获取数据渲染页面。测试环境dubbo的注册中心采用的单实例的zookeeper,随着时间的发现注册在zookeeper上的生产者和消费者越来越多,测试

人员经常在大规模的压测后发现zookeeper挂掉的现象。因为自己用过springcloud,所以想由此谈一下springcloud是如何对注册中心集群化以及如何应对高并发场景的。

二、Spring Cloud的注册中心 Eureka

首先看一下Spring Cloud的架构,整个架构图在抽象之后大概就是这个样子。Spring cloud Eureka是Spring Cloud Netflix 微服务套件中的一部分,它基于 Netflix做了二次封装,主要负责完成

微服务架构中的服务治理功能。不同于dubbo注册中心的是:dubbo的注册中心是第三方组件,可以是zookeeper、可以是Redis。而Spring Cloud的注册中心不是第三方组件,而是自身二次封装专门用于服

务注册与服务发现的注册中心,在使用时只需要依赖相应的jar包即可。

三、注册中心集群化

在微服务这样的分布式架构中,我们要考虑故障发生的场景,所以在生产环境中要对各组件进行高可用部署,即集群化。故springcloug的注册中心也一样,生产环境中单节点的注册中心显然是十

分不安全的,我们需要构建高可用的服务注册中心以增强系统的可用性。

EurekaServer在设计之初就考虑到了高可用问题,在Eureka的服务治理设计中,所有节点既是服务提供者同时也是服务消费者。Eureka  Server的高可用实际上就是将自己作为服务向其他服务注

册中心注册自己,从而形成一组互相注册的服务注册中心,因此能够实现服务清单的互相同步,达到服务高可用的效果,例如构建一个双节点的注册中心:

? 创建application-dev1.properties作为注册中心1的配置,并将serviceUrl指向注册中心2(dev2):

? 创建application-dev2.properties作为注册中心2的配置,并将serviceUrl指向注册中心1(dev1):

然后分别启动两个服务即可组成双节点的注册中心,若集群不止两个实例,只需要在eureka.client.serviceUrl.defaultZone配置项后面用","隔开然后启动项目即可。此时启动服务提供者与服务消费

者,客户端是分别注册到每一个注册中心的实例上的,若此时断开一个或者几个注册中心实例,只要集群中还有实例存活就依然可以提供正常服务,从而实现了服务注册中心的高可用。

四、注册中心与高并发

Spring Cloud的架构体系中,Eureka扮演着一个至关重要的角色,所有的服务注册与服务发现都是依赖着Eureka。上面介绍了注册中心的集群化,那真正的生产环境中注册中心到底要部署多少台?Eureka能不能抗住系统中大量的并发访问?想要弄清楚这个,先从注册中心与客户端的工作原理说起。

首先,各个服务内的Eureka Client在默认情况下每隔30s发送一个请求到Eureka Server来拉取最近有变化的服务信息

举个栗子~

电商的支付模块原本是部署在1台机器上,现在增加部署实例,部署到3台机器上,并且都已经注册到Eureka Server上,然后Eureka Client会每隔30s去Eureka Server拉取注册表信息的变化,看

服务的地址有没有变化。

   其次,Eureka有一个心跳机制,各个Eureka Client每隔30s会发送一次心跳数据到Eureka Server,告诉注册中心自己还活着。如果某个Eureka Client很长时间没有发送心跳数据给Eureka

Server,那么就说明这个实例已经挂了!

在另一方面,服务注册中心这种组件在一开始设计的时候,它的拉取频率及心跳发送机制就已经兼顾到了一个大型系统的各个服务请求的压力,每秒能够承受多大的请求量。默认的30s时间间隔

其实是经过理论上研究后得出的。一个上百个服务,几千台机器的服务系统,按照这个体量请求Eureka Server,日请求量大概在千万级,每秒的访问量大概在160次左右,再加上一些其他的请求操

作,每秒在200次左右。所以通过设置一个拉取注册表及心跳发送机制来保证高并发下场景下Eureka Server的压力不会太大。

那么问题来了,Eureka Server是如何抗住每秒200次的请求的呢?

这个问题其实看源码即可一目了然,Eureka Server注册表的核心是一个CocurrentHashMap,也就是说整个注册表的数据时完全存储在内存里的,各个服务的注册、下线、故障、全部会在内存中维护

和更新。也就是说,Eureka Client每隔30s拉取注册信息和发送心跳数据也是完全基于内存,这个是能抗住每秒200次并发重要原因之一!

通过以上分析,Eureka通过设置适当的请求频率(拉取注册信息30s间隔,发送心跳数据30s间隔)可以保证一个大规模的系统每秒的请求在200次左右,同时通过内存维护注册表信息,保证了所

有的请求都在内存中处理,确保了性能。所以在生产环境中到底需要部署多少台注册中心的实例,还是要根据自身系统的访问体量大小决定。

原文地址:https://www.cnblogs.com/gtblogs/p/10036171.html

时间: 11-28

SpringCloud注册中心集群化及如何抗住大型系统的高并发访问的相关文章

Rancher集群化docker管理平台部署、特性及破坏性测试。

rancher是一个docker集群化管理平台,相对于mesos和k8s架构,rancher的部署管理非常简单方便.并且功能丰富.如下为本人绘制的逻辑架构图. 1:部署Rancher管理平台 规划: server:10.64.5.184 agent1:10.64.5.185 agent2:10.64.5.186 agent3:10.64.5.187 agent4:10.64.5.188 部署方式: docker容器启动 server端部署   依赖镜像:rancher/server:latest

RabbitMQ集群化部署

压测环境上RabbitMQ主库采用三台集群化部署,部署在172.16.103.127, 172.16.103.138, 172.16.103.129三台机器上. 安装目录:/opt/rabbitmq/rabbitmq_3.6.2 集群化部署 1.设置hosts解析,所有节点配置相同 vi /etc/hosts 172.16.103.129 mq-n129172.16.103.128 mq-n128172.16.103.127 mq-n127 2.设置节点间认证的cookiescp /root/.

kairosdb+cassandra集群化安装

kairosdb (1)到/conf目录下,找到kairosdb.properties,修改datastore为cassandra (2)设置cassandra的连接方式 (3) 设置用户名密码 4. 启动:到/bin目录下,直接跑./kairosdb.sh start,最后会看到 KairosDB service started   这样一句话,就OK了 172.16.101.25:8080 kairosdb客户端 cassandra 修改cassandra配置文件 conf/cassandr

java架构师课程、性能调优、高并发、tomcat负载均衡、大型电商项目实战、高可用、高可扩展、数据库架构设计、Solr集群与应用、分布式实战、主从复制、高可用集群、大数据

15套Java架构师详情 * { font-family: "Microsoft YaHei" !important } h1 { background-color: #006; color: #FF0 } 15套java架构师.集群.高可用.高可扩展.高性能.高并发.性能优化.Spring boot.Redis.ActiveMQ.Nginx.Mycat.Netty.Jvm大型分布式项目实战视频教程 视频课程包含: 高级Java架构师包含:Spring boot.Spring  clo

ipvsadm集群化管理_学习笔记

ipvsadm:主要功能 管理集群服务:     添加 -A -t|u|f  service-address [-s(调度算法:默认wlc) scheduler]         -t tcp协议集群         -u udp协议集群             service-address:    VIP:Port         -f FirewallMark(防火墙标记:FWM)             service-address:    Mark-Number     修改  -E

【2】微服务架构-kong的集群化部署

一:Kong的集群方案 Kong支持集群方案,可以加入多个Kong节点来保障服务的高可用性以及提高负载的能力,如下面官方图所示,多个kong组成的集群需要使用共享数据库,以保证集群数据的一致性. (1)集群状态 检查集群的状态 $kong cluster reachability 检查群集的成员 $kong cluster members (2)集群配置 集群配置包含以下几项 cluster_listen         用于与群集中其他节点之间通信的地址和端口. 默认值: 0.0.0.0:79

CentOS6.4 高可用集群之基于heartbeat(crm)和nfs的mysql高可用

CentOS6.4 高可用集群之基于heartbeat和nfs的高可用mysql CentOS版本: CentOS release 6.4(Final) 2.6.32-358.el6.i686 效果演示: 使用ssh连接(nod-1.magedu.com)192.168.3.7 并执行以下命令: [[email protected] ha.d]# hb_gui & 说明:hb_gui是heartbeat为了方便管理集群资源而提供的一个图形用户接口 安装heartbeat默认会在系统中创建一个名为

Solrcloud(Solr集群)

Solrcloud(Solr集群) Solrcloud介绍: SolrCloud(solr集群)是Solr提供的分布式搜索方案. 当你需要大规模,容错,分布式索引和检索能力时使用SolrCloud. 当索引量很大,搜索请求并发很高时,同样需要使用SolrCloud来满足这些需求. 不过当一个系统的索引数据量少的时候是没有必要使用SolrCloud的. SolrCloud是基于Solr和Zookeeper的分布式搜索方案.它的主要思想是使用Zookeeper作为SolrCloud集群的配置信息中心

基于Spring Cloud的微服务构建学习-3 服务治理-Spring Cloud Eureka之高可用注册中心

什么叫高可用 高可用一般指服务的冗余,一个服务挂了,可以自动切换到另一个服务上,不会影响到客户体验. 高可用注册中心 在微服务架构这样的分布式环境中,我们需要充分考虑发生故障的情况,所以在生产环境中必须对各个组件进行高可用部署,对于微服务如此,对于服务中心也一样. Eureka Server的设计一开始就考虑了高可用问题,在Eureka的服务治理设计中,所有节点既是服务提供方,也是服务消费方,服务注册中心也不例外.在前一篇随笔中用到过这样的配置: eureka.client.register-w

ZooKeeper集群的安装、配置、高可用测试

Dubbo注册中心集群Zookeeper-3.4.6 Dubbo建议使用Zookeeper作为服务的注册中心. Zookeeper集群中只要有过半的节点是正常的情况下,那么整个集群对外就是可用的.正是基于这个特性,要将ZK集群的节点数量要为奇数(2n+1:如3.5.7个节点)较为合适. ZooKeeper与Dubbo服务集群架构图 服务器1:192.168.1.81  端口:2181.2881.3881 服务器2:192.168.1.82  端口:2182.2882.3882 服务器3:192.