目录

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

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

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停止开源计划了，具体如下：

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

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

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

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

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

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

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

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

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

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

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

每台机器的内存是有限的，丛集里的服务数量越来越多，可能有几十万个服务例项在执行，那么服务登录档越来越大，最后超过单机内存支撑的极限怎么办？

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

Hadoop的设计思想是把登录档分片储存，分散式储存在多台机器上，每台机器储存部分登录档资料。

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

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

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

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

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

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

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

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

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

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

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

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

一大波微服务、分散式、高并发、高可用系列文章正在路上……文章来源于大神：中华石衫