继续浏览精彩内容
慕课网APP
程序员的梦工厂
打开
继续
感谢您的支持,我会继续努力的
赞赏金额会直接到老师账户
将二维码发送给自己后长按识别
微信支付
支付宝支付

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

石杉的架构笔记
关注TA
已关注
手记 138
粉丝 7623
获赞 1.1万
1、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停止开源计划了,具体如下:


https://img1.mukewang.com/5ca07fb600018ea706690242.jpg


用中文给大家翻译一下,这里的意思就是说:Eureka 2.0的开源工作已经停止了,如果你要用Eureka 2.x版本的代码来部署到生产环境的话,一切后果请自负

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

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

但是现实就是这个声明发出来,让大伙都心里一凉,怎么感觉这个这个Eureka有点不太靠谱了呢,咱还敢继续用么,没错,很多小伙伴就是这感觉。


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

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

所以对于有基础架构团队的公司而言,这个问题相对来说还没那么严重。

因为大厂的基础架构团队,完全可以把常见的开源服务注册中心的源码都深入看一遍,然后经过大量严谨的测试找到各个开源技术的优点和缺点。最后决定是从0开始自研一个服务注册中心,还是说基于某个开源的技术来进行二次开发和优化。

比如说Eureka 1.x作为一个服务注册中心,有一个非常典型的架构问题

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

大家看下面的图,大概就是一个示意。

https://img3.mukewang.com/5ca0804900019bf906430160.jpg

那么这里就有一个问题了:如果是支持超大规模的服务集群,这样的模式能行么?

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

这个时候如果自己研发服务注册中心,就可以参考大数据领域的Hadoop的架构思想。

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

然后每个Server可以加上一个从节点做热备份,避免单机挂掉导致注册 表数据丢失。

我们来看看架构图,如下所示:

https://img2.mukewang.com/5ca0805e00012e7c05480292.jpg

实际在生产环境使用Eureka的时候,你还会碰到很多现实的问题。

比如说上面讲了,Eureka本身是基于简单的同步机制实现集群架构的,但是这里在集群之间进行同步的时候,其实是异步进行的,采用的是最终一致性的协议。

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

所以可能导致其他的Eureka Server是看不到那个刚新注册的服务实例的。

大家看下面的图,就示意了这个问题:

https://img2.mukewang.com/5ca080710001f40606420278.jpg

但是如果是采取了类似Hadoop的那种数据分片思想的话,一个注册表数据分片就在一台机器上,由这台机器负责提供服务的注册和发现,那么此时就可以实现强一致的效果

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

https://img.mukewang.com/5ca080810001b77906410442.jpg

这里只是说其中几个例子罢了,改造开源系统的思路是很多的,实际上大厂完全可以对开源技术做很多的自研、定制和改造,解决线上的生产问题,让服务注册中心朝着他们心里期望的效果去发展,所以对他们来说其实问题并不大。


3、中小公司的其他选择: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架构经验倾囊相授



打开App,阅读手记
0人推荐
发表评论
随时随地看视频慕课网APP