1，而不是Eureka。Eureka正式宣布2.x不再开源。如果你对SpringCloud微服务技术体系有一定的了解，那么一开始肯定知道SpringCloud原生支持和推荐的服务。注册中心是国外视频网站Netflix开源的Eureka。这个Eureka分为所谓的1.x版本和2.x版本。过去国内生产环境使用较多的是1.x版本的Eureka。然后Netflix公司本身就一直在做Eureka2.x版本，结果大家期待的时候，大家都在期待。..2018年7月，人们正式宣布Eureka2.x将停止开源计划。如果您将.x版本的代码部署到生产环境，请自行承担一切后果。大概就是这个意思，就是我不打算把这件事做大做强。当然Eureka1.x版本其实也有很多公司在生产环境中使用，基本处于可以使用的状态。基本功能还是很正常的，应付很多常规场景也足够了。但事实却是，这番表态让所有人都心寒。为什么感觉这个Eureka有点不靠谱呢？我们还敢继续用吗？是的，很多朋友都有这种感觉。2、各大互联网公司的基本架构：自研服务注册中心在这里，给大家说个题外话。BAT、TMD等一线互联网公司，包括一些具有一定研发能力的中大型互联网公司，都曾自主研发过微服务技术。架构中的服务注册表。或者基于Eureka等开源项目做二次开发，自己优化内部架构，解决遇到的问题。所以对于有基础设施团队的公司来说，这个问题相对来说没有那么严重。因为大厂的基础架构团队完全可以把常见的开源服务注册中心的源代码全部看完，然后通过大量严格的测试，找出每一种开源技术的优缺点。最终决定是从头开发服务注册中心，还是基于开源技术进行二次开发和优化。比如Eureka1.x，作为服务注册中心，有一个非常典型的架构问题。虽然他可以部署集群架构，但是集群中的每个Eureka实例都是平等的。每个Eureka实例都包含所有的服务注册表。当每个Eureka实例收到服务注册/下线请求时，会同步转发给集群中的其他Eureka实例，实现集群数据同步。看下图，大概是一个暗示。那么这里有一个问题：如果是支持超大规模的服务集群，这样的模型能行得通吗？每台机器的内存是有限的，集群中服务的数量越来越多，可能有几十万个服务实例在运行。那么，服务注册中心越来越大，超过了单机内存支持的极限怎么办？这时候如果开发自己的服务注册中心，可以参考大数据领域Hadoop的架构。Hadoop的设计思想是将注册表分段存储，分布在多台机器上，每台机器存储一部分注册表数据。然后可以为每台服务器添加一个slave节点进行热备份，避免单机挂掉导致registry数据丢失。我们来看一下架构图，如下图：在实际生产环境中使用Eureka时，会遇到很多实际问题。比如上面提到的，Eureka本身是基于简单的同步机制来实现集群架构的，但是在集群之间进行同步的时候，其实是异步的，使用的是最终一致性协议。这可能会导致说你的某个服务注册到一个EurekaServer实例上，但是需要异步复制到其他EurekaServer上，这需要时间。所以可能会导致其他EurekaServer看不到新注册的服务实例。可以看下图来说明这个问题：但是如果采用类似Hadoop的datasharding的思路，在一台机器上有一个registrydatashard，这台机器负责提供服务注册。而发现，那么此时就可以达到很强的一致效果。也就是说，只要你注册了，马上就会被别人发现，如下图。这里只是几个例子。改造开源系统有很多想法。其实大厂商可以做很多开源技术的自研、定制、改造，来解决线上生产的问题，让服务注册中心朝着他们心中期待的效果发展，所以其实对他们来说不是什么大问题。3.中小企业的其他选择：Consul只针对很多中小企业，可能没有基础设施团队的支持，或者没有太多的人力物力投入自建开发中间件和开源系统的二次开发。那么此时可以考虑选择其他开源的服务注册中心技术。比如Consul，也是SpringCloud支持的，目前是很多公司的选择。这里我们简单介绍一下Consul。后面可以考虑写一篇文章介绍一下Consul的架构原理和使用。来看一下，可以作为服务注册技术选型的参考：服务注册与发现（一）Consul当然是可以作为服务注册中心，可以用于服务注册与发现的微服务架构。（2）同时在这里可以告诉大家，Consul的服务注册机制选择了基于Daft协议的强一致性，并没有像Eureka那样使用最终一致性的效果。健康检查(1)Consul可以支持非常强大的健康检查功能。什么是健康检查？（2）简单来说就是不断的向你的服务发送请求，检查他是不是死了，是不是还健在。这称为健康检查。kv存储(1)Consul不仅支持服务注册和发现，还支持简单的kv存储。(2)它允许你以键值对的形式存储一些信息和提取查询，是不是很神奇？安全的服务通信(1)Consul支持在你的服务之间进行授权，以限制哪些服务可以通信和连接。多数据中心支持其实老实说，在做技术选型的时候，很关键的一点就是看社区是否活跃。所以虽然上面说了很多，其实大家可以看看下面EurekaGithub和ConsulGithub的更新活跃度对比。我们很明显会发现，Eureka1.x版本的最新更新是几个月甚至几年前的事了，而Consul的最新更新很多是几天前的事了。因此，SpringCloud官方的技术栈本身也支持Consul。在Eureka开源社区逐渐不活跃之后，自然有很多中小型公司开始选择使用功能更强大、社区更新更活跃的Consul作为服务注册中心。这也是一个不错的选择。
