SpringCloud微服务_3 Eureka注册中心实现原理
作者：田超凡
版权所有，转载请注明原作者，仿冒侵权必究法律责任
1 Eureka注册中心
刚才对注册中心的作用和实现原理进行了简要介绍，那么接下来就开始搭建一个基于SpringCloud2.0 Greenwich S3版本的Eureka注册中心吧。Eureka注册中心始源国外的一个开源视频网站netflix，后来netflix傻乎乎的把组件提供给了SpringCloud研发团队，现在估计哭不出来了。
需要注意的是Eureka目前是闭源的，刚开始在SpringCloud1.0中开始开源的，后来不知道为什么就闭源了，但是不用担心，SpringCloud2.0中直接把Eureka作为内置且官方推荐的注册中心，并且对Eureka注册中心功能进行持续优化和完善，详情可自行去github广场查看最新版本发布情况。
由于我是按照自己的实践理解来默写总结的，只能说是把重点部分做下总结，如果有疏漏和考虑不周的地方，github或者码云call我一下啦。大致说一下Eureka注册中心搭建步骤：
首先，pon.xml新增基本依赖如下：
spring-boot-starter-parent 版本2.0
spring-boot-starter-logging
spring-boot-starter-web
spring-boot-starter-jdbc
spring-boot-starter-aop
spring-cloud-starter-parent Greenwich S3或者Finalize.REALASE，SpringBoot2.0.X则用前者
spring-cloud-starter-netflix-eureka-server
创建启动类，这里有三个要使用的注解做下简单介绍
EnableEurekaServer 应用启动立即加载Eureka注册中心
EnableEurekaClient 应用启动立即联通Eureka注册中心
EnableDiscoveryClient 暴露当前服务
底层实现实际是读取application.yml配置文件并加载配置的注册中心信息到META-INF/spring.factories文件中，应用启动之后SpringApplication内部会基于EnableAutoConfigurationImportSelector扫描配置信息并加载到内存中，然后基于ApplicationRunListener监听服务注册，再通过SpringFactoriesLoader读取生成的spring.factories文件中的EnableAutoConfiguration指向的EurekaServerAutoConfiguration注册Eureka注册中心。具体的可以去查看SpringBoot项目运行加载机制的相关源码解析
创建application.yml配置文件，除SpringBoot应用基本配置项外，新增Eureka注册中心相关配置，重点说下几个重要的配置项：
spring.application.name指定serviceid，全局唯一（不唯一则当做集群处理）
eureka.instance.hostname 注册中心主机ip
eureka.service.uri.defaultZone 注册中心url
eureka.service.register-with-eureka 是否需要把自身注册到Eureka注册中心
eureka.service.fetch-registry 是否需要在Eureka注册中心中查找服务
启动应用访问，默认会直接打开Eureka注册中心，在SpringCloud内置的Eureka注册中心中默认提供了ui组件进行渲染，在页面上可以实时看到服务的注册和运行情况。
2 Eureka注册中心集群实现原理概述
前面我们说了，一般情况下所有微服务架构项目注册中心都不会只有一个，默认都会搭建注册中心集群来容灾。Eureka注册中心集群方式搭建比较简单灵活，采用的实现机制是依赖传递。简单的说，就是同一个集群中的注册中心相互注册从而实现注册中心中的服务在其它注册中心中保持同步。在application.yml指定的注册中心defaultZone中可以指定多个注册中心的url（默认相同集群环境中的所有注册中心此处均保持相同配置从而实现传递注册进而实现服务同步），每个注册中心url之间使用逗号隔开。
同一个集群环境下的所有注册中心spring.application.name必须保持一致，否则将会单独成为注册中心而不是注册中心集群。
注册中心集群环境下可能会后台输出一些无法访问的异常，比如can not connect to serviceid或者can not found eureka instance serviceid等等，这是因为在同一个集群环境下每一个注册中心之间都需要相互注册，刚启动的时候由于依赖的其他注册中心还没有启动成功所以也就无法注册当前注册中心到其他的注册中心。同一个集群中的所有注册中心全部启动成功之后，这个异常就会消失。如果Eureka注册中心集群环境搭建并且启动成功，访问其中任意一个Eureka注册中心都会发现，同一个serviceid对应多个注册中心实例，这就表明我们的Eureka注册中心集群搭建成功。
3 Eureka注册中心备注和补充
SpringCloud微服务框架提供了目前市面上使用频率比较高的注册中心支持，包括但不限于
zookeeper，eureka，consul，redis
注意：
Eureka在SpringCloud2.0中已经闭源，但是目前仍是官方建议推荐的主流注册中心，如果对Eureka源码感兴趣可以参考SpringCloud1.0中的Eureka源码或者参考netflix视频网站中的Eureka源码。
consul是Apache基金会全新发布的一款consul是Apache基金会全新发布的一款Go语言编写的注册中心，由于和由于和Java兼容性不好，所以目前所以目前SpringCloud2.0官方只是把0官方只是把consul当做备选方案，如果后期如果后期netflix和如果后期如果后期netflix和SpringCloud谈不拢的话，SpringCloud官方推荐SpringCloud官方推荐consul也不是不无可能，说白了，其实consul目前只是备胎。
zookeeper是dubbo和dubbox官方推荐并使用的注册中心，优点是跨平台能力强，但是由于体型较大且安装配置方式较为复杂，被被SpringCloud2.0逐渐淡忘了。。。但是但是SpringCloud2.0还是保留了对zookeeper的部分支持，但是在微服务体系中实际并不常用。
redis新推出的注册中心名气较小并且不稳定，还在SNAPSHOT阶段，目前SpringCloud2.0官方并不推荐使用。
补充说明：
基于dubbo/dubbox的SOA架构 PK 基于Eureka的SpringCloud微服务架构
传统SOA架构虽然也是面向服务架构，虽然也可以对服务进行调度管理，但是对于日趋庞大的软件系统而言，缺点也是逐渐显现出来：
服务粒度过粗，大量服务的情况下服务治理出现混乱，服务调用机制缺乏灵活性，服务容灾性差，配置和维护复杂性大，经常性出现牵一发动全身问题，数据传输速率很慢，服务经常宕机。
基于基于SpringCloud2.0的微服务架构则提供了一整套微服务体系治理机制，服务粒度更加精细，专门提供了服务治理和监管机制，最大限度确保服务的弹性，伸缩性，进而提高整个应用系统的容灾性和高可用性。拥有单独的微服务分布式配置中心统一管理所有服务配置信息，采用主流REST数据传输机制进行服务和注册中心，服务和服务之间的高性能RPC远程调用，极大提高了系统轻便和灵活性，进而提高开发的敏捷性。拥有单独的熔断和容灾机制，最大限度减少服务雪崩所带来的蝴蝶效应，对于服务器来说服务访问线程分配更加均衡，也避免了线程阻塞导致项目崩溃问题出现的可能性。所以在面向服务设计的架构体系中，基于SpringCloud2.0的微服务架构得到了开源社区开发同行的广泛认可，也正逐渐成为越来越多大厂开发项目首选架构。
