【Java高阶必备】如何优化Spring Cloud微服务注册中心架构?【石杉的架构笔记】

4,803 阅读12分钟

欢迎关注微信公众号:石杉的架构笔记(id:shishan100)

我的新课**《C2C 电商系统微服务架构120天实战训练营》在公众号儒猿技术窝**上线了,感兴趣的同学,可以点击下方链接了解详情:

《C2C 电商系统微服务架构120天实战训练营》

精品学习资料获取通道,参见文末

目录

1、再回顾:什么是服务注册中心?

2、Consul服务注册中心的整体架构

3、Consul如何通过Raft协议实现强一致性?

4、Consul如何通过Agent实现分布式健康检查?

上一篇文章:尴尬了!Spring Cloud微服务注册中心Eureka 2.x停止维护了咋办?,我们给大家说了一下Spring Cloud服务注册中心的一些问题。

如果用Eureka作为其注册中心的话,很多同学都觉得心里没底,所以现在很多公司都开始使用Consul作为其注册中心。

那么这篇文章我们就来给大家说说:Consul这种服务注册中心的架构是如何设计的?

1、再回顾:什么是服务注册中心?

先回顾一下什么叫做服务注册中心?

顾名思义,假设你有一个分布式系统,里面包含了多个服务,部署在不同的机器上,然后这些不同机器上的服务之间要互相调用。

举个现实点的例子吧,比如电商系统里的订单服务需要调用库存服务,如下图所示。

现在的问题在于,订单服务在192.168.31.154这台机器上,库存服务在192.137.1.33这台机器上。

现在订单服务是想要调用库存服务,但是他并不知道库存服务在哪台机器上啊!毕竟人家都是在不同机器上的。

所以这个时候就需要服务注册中心出场了,这个时候你的系统架构中需要引入独立部署在一台机器上的服务注册中心,如下图所示。

然后订单服务、库存服务之类的兄弟,都需要配置上服务注册中心部署在哪台机器上,比如192.168.31.45这台机器。

接着订单服务、库存服务他们自己启动的时候,就得发送请求到到服务注册中心上去进行服务注册。

也就是说,得告诉服务注册中心,自己是哪个服务,然后自己部署在哪台机器上。

然后服务注册中心会把大家注册上来的信息放在注册表里,如下图。

接着订单服务假如想要调用库存服务,那么就找服务注册中心问问:能不能告诉我库存服务部署在哪台机器上?

服务注册中心是知道这个信息的,所以就会告诉订单服务:库存服务部署在192.1371.133这台机器上,你就给这台机器发送请求吧。

然后,订单服务就可以往库存服务的那台机器发送请求了,完成了服务间的调用。

整个过程,如下图所示:

上述就是服务注册中心的作用、地位以及意义,现在大家应该知道服务注册中心的作用了吧。

好!接着我们就来看看Consul作为服务注册中心,他的架构设计原理是什么?

2、Consul服务注册中心的整体架构

如果要基于Consul作为服务注册中心,那么首先必须在每个服务所在的机器上部署一个Consul Agent,作为一个服务所在机器的代理。

然后还得在多台机器上部署Consul Server,这就是核心的服务注册中心。

这个Consul Agent可以用来收集你的服务信息然后发送给Consul Server,还会对你的服务不停的发送请求检查他是否健康。

然后你要发现别的服务的时候,Consul Agent也会帮你转发请求给Consul Server,查询其他服务所在机器。

Consul Server一般要求部署3~5台机器,以保证高可用以及数据一致性。

他们之间会自动实现数据同步,而且Consul Server集群会自动选举出一台机器作为leader,其他的Consul Server就是follower。

咱们看下面的图,先感受一下这个Consul他整体的架构。

3、Consul如何通过Raft协议实现强一致性?

首先上篇文章:尴尬了!Spring Cloud微服务注册中心Eureka 2.x停止维护了咋办?已经说了,Eureka服务注册中心是不保证数据一致性的。

这样的话,很可能你注册的服务,其他人是发现不了的,或者很迟才能发现。

OK,那么这里就来讨论一下Consul是如何实现数据一致性的。

首先,大家知道Consul Server是部署集群的,而且他会选举出来一台Server作为Leader。

接下来各个服务发送的注册请求都会落地给Leader,由Leader同步给其他Follower。

所以首先第一点,Leader Server是绝对有最新的服务注册信息的,是不是?

比如库存服务发起注册了,那么Leader Server上一定有库存服务的注册信息。

接着如果比如订单服务要发现库存服务的话,这个查询请求会发送给Leader Server。

这样服务注册和发现,都是通过一台Leader Server来进行的,就可以保证服务注册数据的强一致性了,大家看下图。

接着大家想,假如说库存服务在注册的时候数据刚写到Leader Server,结果Leader Server就宕机了,这时候怎么办?

那么此时这条注册数据就丢失了,订单服务就没法发现那个库存服务了。没关系,这里Consul会基于Raft协议来解决这个问题

首先,库存服务注册到Leader Server的时候,会采取Raft协议,要求必须让Leader Server把这条注册数据复制给大部分的Follower Server才算成功。

这就保证了,如果你认为自己注册成功了,那么必然是多台Consul Server都有这条注册数据了。

如果你刚发送给Leader Server他自己就宕机了,那么这次注册会认为失败。

此时,Consul Server集群会重新选举一个Leader Server出来,你需要再次重新注册。

这样就可以保证你注册成功的数据绝对不会丢,然后别人发现服务的时候一定可以从Leader Server上获取到最新的强一致的注册数据。

整个过程,如下图所示:

上面的图就可以看到,只要你注册的时候基于Raft协议强制同步到大多数Server,哪怕是Leader挂了,也会选举新的Leader。

这样就可以让别人从新的Leader Server来发现你这个服务,所以数据是绝对强一致的。

4、Consul如何通过Agent实现分布式健康检查?

最后说说Consul是如何通过各个服务机器上部署Agent来实现分布式健康检查的。

集中式的心跳机制,比如传统的Eureka,是让各个服务都必须每隔一定时间发送心跳到Eureka Server。

如果一段时间没收到心跳,那么就认为这个服务宕机了。

但是这种集中式的心跳机制会对Eureka Server造成较大的心跳请求压力,实际上平时Eureka Server接收最多的请求之一就是成千上万服务发送过来的心跳请求。

所以Consul在这块进行了架构优化,引入了Agent概念。

每个机器上的Consul Agent会不断的发送请求检查服务是否健康,是否宕机。如果服务宕机了,那么就会通知Consul Server。

怎么样?是不是发现各个服务自己不用再发送心跳请求去Server了?减小了Server这部分的压力吧?

没错,这就是Consul基于Agent实现的分布式健康检查机制,可以大幅度的减小Server端的压力。

这样一来,哪怕你就部署个三五台机器,可以轻松支持成千上万个服务。

咱们再来一张图,一起来看看:

End

(封面图源网络,侵权删除)

扫描下方二维码,备注:“资料”,获取更多“秘制” 精品学习资料

![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/2/18/169007e734f5d1b5~tplv-t2oaga2asx-image.image)

如有收获,请帮忙转发,您的鼓励是作者最大的动力,谢谢!

一大波微服务、分布式、高并发、高可用的原创系列文章正在路上

欢迎扫描下方二维码,持续关注:

![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/1/9/16833096471eb0ef~tplv-t2oaga2asx-image.image)

石杉的架构笔记(id:shishan100)

十余年BAT架构经验倾囊相授

推荐阅读:

1、拜托!面试请不要再问我Spring Cloud底层原理

2、【双11狂欢的背后】微服务注册中心如何承载大型系统的千万级访问?

3、【性能优化之道】每秒上万并发下的Spring Cloud参数优化实战

4、微服务架构如何保障双11狂欢下的99.99%高可用

5、兄弟,用大白话告诉你小白都能听懂的Hadoop架构原理

6、大规模集群下Hadoop NameNode如何承载每秒上千次的高并发访问

7、【性能优化的秘密】Hadoop如何将TB级大文件的上传性能优化上百倍

8、拜托,面试请不要再问我TCC分布式事务的实现原理!

9、【坑爹呀!】最终一致性分布式事务如何保障实际生产中99.99%高可用?

10、拜托,面试请不要再问我Redis分布式锁的实现原理!

11、【眼前一亮!】看Hadoop底层算法如何优雅的将大规模集群性能提升10倍以上?

12、亿级流量系统架构之如何支撑百亿级数据的存储与计算

13、亿级流量系统架构之如何设计高容错分布式计算系统

14、亿级流量系统架构之如何设计承载百亿流量的高性能架构

15、亿级流量系统架构之如何设计每秒十万查询的高并发架构

16、亿级流量系统架构之如何设计全链路99.99%高可用架构

17、七张图彻底讲清楚ZooKeeper分布式锁的实现原理

18、大白话聊聊Java并发面试问题之volatile到底是什么?

19、大白话聊聊Java并发面试问题之Java 8如何优化CAS性能?

20、大白话聊聊Java并发面试问题之谈谈你对AQS的理解?

21、大白话聊聊Java并发面试问题之公平锁与非公平锁是啥?

22、大白话聊聊Java并发面试问题之微服务注册中心的读写锁优化

23、互联网公司的面试官是如何360°无死角考察候选人的?(上篇)

24、互联网公司面试官是如何360°无死角考察候选人的?(下篇)

25、Java进阶面试系列之一:哥们,你们的系统架构中为什么要引入消息中间件?

26、【Java进阶面试系列之二】:哥们,那你说说系统架构引入消息中间件有什么缺点?

27、【行走的Offer收割机】记一位朋友斩获BAT技术专家Offer的面试经历

28、【Java进阶面试系列之三】哥们,消息中间件在你们项目里是如何落地的?

29、【Java进阶面试系列之四】扎心!线上服务宕机时,如何保证数据100%不丢失?

30、一次JVM FullGC的背后,竟隐藏着惊心动魄的线上生产事故!

31、【高并发优化实践】10倍请求压力来袭,你的系统会被击垮吗?

32、【Java进阶面试系列之五】消息中间件集群崩溃,如何保证百万生产数据不丢失?

33、亿级流量系统架构之如何在上万并发场景下设计可扩展架构(上)?

34、亿级流量系统架构之如何在上万并发场景下设计可扩展架构(中)?

35、亿级流量系统架构之如何在上万并发场景下设计可扩展架构(下)?

36、亿级流量架构第二弹:你的系统真的无懈可击吗?

37、亿级流量系统架构之如何保证百亿流量下的数据一致性(上)

38、亿级流量系统架构之如何保证百亿流量下的数据一致性(中)?

39、亿级流量系统架构之如何保证百亿流量下的数据一致性(下)?

40、互联网面试必杀:如何保证消息中间件全链路数据100%不丢失(1)

41、互联网面试必杀:如何保证消息中间件全链路数据100%不丢失(2

42、面试大杀器:消息中间件如何实现消费吞吐量的百倍优化?

43、高并发场景下,如何保证生产者投递到消息中间件的消息不丢失?

44、兄弟,用大白话给你讲小白都能看懂的分布式系统容错架构

45、从团队自研的百万并发中间件系统的内核设计看Java并发性能优化

46、【非广告,纯干货】英语差的程序员如何才能无障碍阅读官方文档?

47、如果20万用户同时访问一个热点缓存,如何优化你的缓存架构?

48、【非广告,纯干货】中小公司的Java工程师应该如何逆袭冲进BAT?

49、拜托,面试请不要再问我分布式搜索引擎的架构原理!

50、【金三银四跳槽季】Java工程师如何在1个月内做好面试准备?

51、【offer收割机必备】我简历上的Java项目都好low,怎么办?

52、【offer去哪了】我一连面试了十个Java岗,统统石沉大海!

53、高阶Java开发必备:分布式系统的唯一id生成算法你了解吗?

54、支撑日活百万用户的高并发系统,应该如何设计其数据库架构?

55、尴尬了!Spring Cloud微服务注册中心Eureka 2.x停止维护了咋办?

作者:石杉的架构笔记
链接:juejin.cn/post/684490…
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。