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

港控/mmm° 2022-03-16 03:22 2292阅读 0赞

**目录**

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

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

3、中小公司的其他选择：Consul

**1、Eureka官方宣布2.x不再开源**

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

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

然后Netflix这个公司本身一直在做Eureka 2.x版本，结果做着做着，大家万众瞩目很期待的时候。。。

**2018年7月，人家官方就突然宣布Eureka 2.x停止开源计划了，具体如下：**

![20190226113021941.png][]

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

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

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

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

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

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

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

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

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

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

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

![20190226113049924.png][]

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

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

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

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

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

我们来看看架构图，如下所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xjaHExOTk1_size_16_color_FFFFFF_t_70][]

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

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

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

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

大家看下面的图，就示意了这个问题：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xjaHExOTk1_size_16_color_FFFFFF_t_70 1][]

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

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xjaHExOTk1_size_16_color_FFFFFF_t_70 2][]

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

**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作为服务注册中心了，这也是一个不错的选择。

[20190226113021941.png]: /images/20220316/6e24a22fc51f4b9e930f35721c00e342.png
[20190226113049924.png]: /images/20220316/fa989a2a00e242629913862ddebf835f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xjaHExOTk1_size_16_color_FFFFFF_t_70]: /images/20220316/6d15af400ad344049d33ae062dcd366a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xjaHExOTk1_size_16_color_FFFFFF_t_70 1]: /images/20220316/0dce8a9eb423478fb12ccc1f87176f0f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xjaHExOTk1_size_16_color_FFFFFF_t_70 2]: /images/20220316/7e0d53445bd74d4a96c13f7fa909dac7.png