尴尬了！Spring Cloud微服务注册中心Eureka 2.x中止维护了咋办？【石杉的架构笔记】

欢迎关注我的公众号：石杉的架构笔记（ID:shishan100）

周一至周五早8点半！精品技术文章准时送上！

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

目录

一、Eureka官宣2.x版本再也不开源

二、互联网大厂的基础架构：自研服务注册中心

三、中小公司的其余选择：Consul

一、Eureka官方宣布2.x再也不开源

以前写过一篇文章：拜托！面试请不要再问我Spring Cloud底层原理！，文章介绍了Spring Cloud微服务技术体系的一些基础知识和架构原理。

若是对Spring Cloud微服务技术体系有必定了解了以后，确定就知道Spring Cloud最开始原生支持和推荐的服务注册中心是国外的一个视频网站Netflix开源的Eureka。

这个Eureka呢，又分红了所谓的1.x版本和2.x版本，以前在国内比较经常使用在生产环境中的都是Eureka的1.x版本。

而后Netflix这个公司自己一直在作Eureka 2.x版本，结果作着作着，你们万众瞩目很期待的时候。。。

2018年7月，人家官方就忽然宣布Eureka 2.x中止开源计划了，具体以下：

用中文给你们翻译一下，这里的意思就是说：Eureka 2.0的开源工做已经中止了，若是你要用Eureka 2.x版本的代码来部署到生产环境的话，一切后果请自负。

大概就是这个意思，就是不打算把这个事儿作大作强下去了。

固然如今其实Eureka 1.x的版本也有很多公司在生产环境用，并且基本也还算能用的状态，基本功能还算正常，应付不少常规的场景也足够了。

可是现实就是这个声明发出来，让大伙都内心一凉，怎么感受这个这个Eureka有点不太靠谱了呢，咱还敢继续用么，没错，不少小伙伴就是这感受。

二、互联网大厂的基础架构：自研服务注册中心

这里给你们说一句题外话，BAT、TMD等一线互联网公司，包括一些有必定研发实力的中大型互联网公司，都是自研了微服务技术架构中的服务注册中心。或者是基于开源的Eureka之类的项目来作二次开发，自行优化里面的架构，解决遇到的问题。

因此对于有基础架构团队的公司而言，这个问题相对来讲还没那么严重。

由于大厂的基础架构团队，彻底能够把常见的开源服务注册中心的源码都深刻看一遍，而后通过大量严谨的测试找到各个开源技术的优势和缺点。最后决定是从0开始自研一个服务注册中心，仍是说基于某个开源的技术来进行二次开发和优化。

好比说Eureka 1.x做为一个服务注册中心，有一个很是典型的架构问题。

虽然他能够部署集群架构，可是集群中每一个Eureka实例都是对等的。每一个Eureka实例都包含了所有的服务注册表，每一个Eureka实例接收到了服务注册/下线等请求的时候，会同步转发给集群中其余的Eureka实例，实现集群数据同步。

你们看下面的图，大概就是一个示意。

那么这里就有一个问题了：若是是支持超大规模的服务集群，这样的模式能行么？

每台机器的内存是有限的，集群里的服务数量愈来愈多，可能有几十万个服务实例在运行，那么服务注册表愈来愈大，最后超过单机内存支撑的极限怎么办？

这个时候若是本身研发服务注册中心，就能够参考大数据领域的Hadoop的架构思想。

Hadoop的设计思想是把注册表分片存储，分布式存储在多台机器上，每台机器存储部分注册表数据。

而后每一个Server能够加上一个从节点作热备份，避免单机挂掉致使注册 表数据丢失。

咱们来看看架构图，以下所示：

实际在生产环境使用Eureka的时候，你还会碰到不少现实的问题。

好比说上面讲了，Eureka自己是基于简单的同步机制实现集群架构的，可是这里在集群之间进行同步的时候，实际上是异步进行的，采用的是最终一致性的协议。

这就可能会致使说，你某个服务注册到了一个Eureka Server实例上去，可是他须要异步复制到其余的Eureka Server，这中间是须要时间的。

因此可能致使其余的Eureka Server是看不到那个刚新注册的服务实例的。

你们看下面的图，就示意了这个问题：

可是若是是采起了相似Hadoop的那种数据分片思想的话，一个注册表数据分片就在一台机器上，由这台机器负责提供服务的注册和发现，那么此时就能够实现强一致的效果。

也就是说，只要你注册了，立马就会被别人发现，以下图。

这里只是说其中几个例子罢了，改造开源系统的思路是不少的，实际上大厂彻底能够对开源技术作不少的自研、定制和改造，解决线上的生产问题，让服务注册中心朝着他们内心指望的效果去发展，因此对他们来讲其实问题并不大。

三、中小公司的其余选择：Consul

只是对于不少中小型公司而言，可能自己没有基础架构团队的支撑，或者是没有过多的人力物力投入到自研中间件、开源系统二次开发中去。

那么此时就能够考虑选择其余的开源服务注册中心的技术了，好比Spring Cloud一样支持的Consul就是目前不少公司的选择。

这儿我们简单介绍一下Consul，后面能够考虑再写文章介绍介绍Consul的架构原理和使用什么的，你们看一下，能够做为一个服务注册中心技术选型的参考：

• 服务注册与发现
• Consul固然是能够做为服务注册中心的了，能够用作微服务架构的服务注册和发现。
• 同时这里能够先给你们说一下，Consul的服务注册机制选择的是基于Daft协议的强一致，没有像Eureka那样使用最终一致的效果。

• 健康检查
• Consul能够支持很是强大的健康检查的功能，啥叫健康检查？
• 简单来讲就是不停的发请求给你的服务检查他到底死了没有，目前是否还健康，这个就是叫作健康检查。

• kv存储
• Consul不光支持服务注册和发现，竟然还能够支持简单的kv存储。
• 他可让你用key-value对的形式存放一些信息以及提取查询，是否是很神奇？

• 安全的服务通讯
• Consul支持让你的服务之间进行受权来限制哪些服务能够通讯和链接

• 多数据中心支持

其实说实话，在作技术选型的时候，很是关键的一点，就是看社区是否活跃。

因此虽然上面说了不少，可是其实你们彻底能够看一眼下面的Eureka Github和Consul Github的更新活跃度的对比。

咱们明显会发现，Eureka 1.x版本最近的更新都在几个月前甚至几年前，可是Consul最近的更新不少都是几天前的。

因此自己Spring Cloud官方技术栈也是支持Consul的，Eureka开源社区慢慢再也不活跃以后，天然不少中小公司开始选择使用功能更增强大，并且社区更新也更加活跃的Consul做为服务注册中心了，这也是一个不错的选择。

End

（封面图源网络，侵权删除）

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

若有收获，请帮忙转发，您的鼓励是做者最大的动力，谢谢！

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

欢迎扫描下方二维码，持续关注：

石杉的架构笔记（id:shishan100）

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

推荐阅读：

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

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

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

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

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

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

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

八、拜托，面试请不要再问我TCC分布式事务的实现原理！

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

十、拜托，面试请不要再问我Redis分布式锁的实现原理！

十一、【眼前一亮！】看Hadoop底层算法如何优雅的将大规模集群性能提高10倍以上？

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

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

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

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

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

1七、七张图完全讲清楚ZooKeeper分布式锁的实现原理

1八、大白话聊聊Java并发面试问题之volatile究竟是什么？

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

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

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

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

2三、互联网公司的面试官是如何360°无死角考察候选人的？（上篇）

2四、互联网公司面试官是如何360°无死角考察候选人的？（下篇）

2五、Java进阶面试系列之一：哥们，大家的系统架构中为何要引入消息中间件？

2六、【Java进阶面试系列之二】：哥们，那你说说系统架构引入消息中间件有什么缺点？

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

2八、【Java进阶面试系列之三】哥们，消息中间件在大家项目里是如何落地的？

2九、【Java进阶面试系列之四】扎心！线上服务宕机时，如何保证数据100%不丢失？

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

3一、【高并发优化实践】10倍请求压力来袭，你的系统会被击垮吗？

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

3三、亿级流量系统架构之如何在上万并发场景下设计可扩展架构（上）？

3四、亿级流量系统架构之如何在上万并发场景下设计可扩展架构（中）？

3五、亿级流量系统架构之如何在上万并发场景下设计可扩展架构（下）？

3六、亿级流量架构第二弹：你的系统真的无懈可击吗？

3七、亿级流量系统架构之如何保证百亿流量下的数据一致性（上）

3八、亿级流量系统架构之如何保证百亿流量下的数据一致性（中）？

3九、亿级流量系统架构之如何保证百亿流量下的数据一致性（下）？

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

4一、互联网面试必杀：如何保证消息中间件全链路数据100%不丢失（2）

4二、面试大杀器：消息中间件如何实现消费吞吐量的百倍优化？

4三、高并发场景下，如何保证生产者投递到消息中间件的消息不丢失？

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

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

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

4七、若是20万用户同时访问一个热点缓存，如何优化你的缓存架构？

4八、【非广告，纯干货】中小公司的Java工程师应该如何逆袭冲进BAT？

4九、拜托，面试请不要再问我分布式搜索引擎的架构原理！

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

5一、【offer收割机必备】我简历上的Java项目都好low，怎么办？

5二、【offer去哪了】我一连面试了十个Java岗，通通石沉大海！

5三、高阶Java开发必备：分布式系统的惟一id生成算法你了解吗？

5四、支撑日活百万用户的高并发系统，应该如何设计其数据库架构？

做者：石杉的架构笔记 连接：https://juejin.im/post/5c6a9f25518825787e69e70a 来源：掘金 著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。