点击上方"蓝字", 右上角选择“设为星标”
周一至周五早8点半！精品技术文章准时送上！
目录
1、Eureka官宣2.x版本不再开源
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、互联网大厂的基础架构：自研服务注册中心
这里给大家说一句题外话，BAT、TMD等一线互联网公司，包括一些有一定研发实力的中大型互联网公司，都是自研了微服务技术架构中的服务注册中心。或者是基于开源的Eureka之类的项目来做二次开发，自行优化里面的架构，解决遇到的问题。
所以对于有基础架构团队的公司而言，这个问题相对来说还没那么严重。
因为大厂的基础架构团队，完全可以把常见的开源服务注册中心的源码都深入看一遍，然后经过大量严谨的测试找到各个开源技术的优点和缺点。最后决定是从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
推荐阅读
一大波微服务、分布式、高并发、高可用的原创系列文章正在路上。
欢迎扫描下方二维码，持续关注：
石杉的架构笔记（id:shishan100）
十余年BAT架构经验倾囊相授
3049
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
