EnableDiscoveryClient与EnableEurekaClient的区别、Cloud-2.0以后无需增加

SpringCloudDalston版本后服务注册自动配置变化
文章讲述了SpringCloudDalston及后续版本中,EurekaClient和EnableDiscoveryClient在服务注册方面的变化。Dalston版本后,无需显式声明相关注解,自动注册功能由eureka-clientjar包控制。Edgware及以上版本,自动配置启用服务注册,不再依赖EnableDiscoveryClient注解。

结论:Dalston版本后,无需手动声明@EnableDiscoveryClient或EnableEurekaClient,eureka-client jar包引入后会自动进行服务注册,若要禁用注册功能,配置 eureka.client.enabled=false

Spring Cloud版本:Angle -> Brixton -> Camden -> Dalston -> Edgware -> Finchley

Cloud代号

Boot版本(train)

Boot版本(tested)

lifecycle

Angle

1.2.x

incompatible with 1.3

EOL in July 2017

Brixton

1.3.x

1.4.x

2017-07卒

Camden

1.4.x

1.5.x

Dalston

1.5.x

not expected 2.x

Edgware

1.5.x

not expected 2.x

Finchley

2.x

not expected 1.5.x

一、Dalston或更早期的版本
 为了启用服务注册发现功能。需要在主启动类上增加@EnableDiscoveryClient或者@EnableEurekaClient注解,例如以下代码:

@EnableEurekaClient
@SpringBootApplication
public class ScjzfpRestApplication {

    public static void main(String[] args) {
        SpringApplication.run(ScjzfpRestApplication.class, args);
    }
}

EnableEurekaClient源码:

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@EnableDiscoveryClient
public @interface EnableEurekaClient {

}

 EnableEurekaClient 中使用了EnableDiscoveryClient。因此,从使用角度来看两者已经没有什么区别了,官方建议使用EnableDiscoveryClient。
区别:
 @EnableDiscoveryClient注解是基于spring-cloud-commons依赖,并且在classpath中实现。
 @EnableEurekaClient注解是基于spring-cloud-netflix依赖,只能为eureka作用。
 @EnableEurekaClient只适用于Eureka作为注册中心,@EnableDiscoveryClient 可以是其他注册中心。
 从Spring Cloud 1.0.0.RC1版本开始,就已经不推荐使用EnableEurekaClient和EnableHystrix了。服务注册发现功能被抽象后放入spring-cloud-commons库,该库的EnableDiscoveryClient可以取代旧的EnableEurekaClient,使用注解EnableDiscoveryClient就能启用服务注册发现功能。 同理,EnableHystrix也被EnableCircuitBreaker取代了。
二、Edgware或者更新的版本
EnableEurekaClient源码:

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
public @interface EnableEurekaClient {

}

 之前版本中的@EnableDiscoveryClient注解已经取消了,而且也没有用到任何@Import注解,因此,在代码不用再添加EnableEurekaClient注解。
 EnableDiscoveryClient注解现在也没用了 。只要依赖了以spring-cloud-starter-netflix为前缀的库(例如spring-cloud-starter-netflix-eureka-client),就启用了服务注册发现功能。使用配置项spring.cloud.service-registry.auto-registration.enabled=false即可禁止服务注册发现功能。spring容器在查询spring.factories的过程中,如果找到了EnableDiscoveryClient的配置,就会实例化该配置对应的服务注册发现:例如eureka、consul、zookeeper等。
 EnableDiscoveryClient不是必须的,只要classpath中存在DiscoveryClient的实现就可以保证将应用注册到注册中心了,只依赖以spring-cloud-starter-netflix为前缀的库(例如spring-cloud-starter-netflix-eureka-client),就启用了服务注册发现功能,利用spring容器通过META-INF/spring.factories文件加载配置的能力。
 打开工程spring-cloud-netflix-eureka-client(Edgware版对应的该工程版本号为1.4.0.RELEASE),去看src\main\resources\META-INF目录下的spring.factories文件,发现在springboot的自动配置项中,出现了一个关键配置EurekaDiscoveryClientConfiguration,如下图:
在这里插入图片描述
 服务注册发现功能是否启动,是由配置类EurekaDiscoveryClientConfiguration控制的,在Edgware版本中,如果开启了springboot的自动配置,那么EurekaDiscoveryClientConfiguration就会生效,因此不是靠EnableDiscoveryClient注解来控制了;
 Dalston版的Spring Cloud,其spring-cloud-netflix-eureka-client工程的版本号为1.3.6.RELEASE,打开该工程下面的spring.factories文件,内容如下:
在这里插入图片描述
在Dalston版本下,使用注解EnableDiscoveryClient才会使配置EurekaDiscoveryClientConfiguration生效;

1、在Edgware版本中,官方建议使用spring-cloud-netflix-eureka-client作为starter。
2.、在Dalston版本中,官方建议使用spring-cloud-starter-eureka作为starter。
 由于spring-cloud-starter-eureka的间接依赖,spring-cloud-netflix-eureka-client会出现在classpath中。
 因此spring启动时会扫描到spring-cloud-netflix-eureka-client.jar包中的spring.factories文件。
 如果当前工程使用了EnableDiscoveryClient注解,按照spring.factories中的配置,配置类EurekaDiscoveryClientConfiguration会生效,进而开启服务注册发现功能。

三、总结:
在Spring Cloud的Dalston及其之前的版本中:
 1、从2014年的Spring Cloud 1.0.0.RC1版本开始,官方就推荐使用EnableDiscoveryClient来取代EnableEurekaClient。
 2、EnableEurekaClient源码中使用了注解EnableDiscoveryClient,因此如果要使用eureka的注册发现服务,两者功能是一样的。
 3、EnableDiscoveryClient注解在spring.factories配置中通过配置项EurekaDiscoveryClientConfiguration来开启服务注册发现功能;

在Dalston之后的版本中(不含Dalston):
 1、在spring.factories配置中,配置类EurekaDiscoveryClientConfiguration被配置到springboot的自动配置注解中,与EnableDiscoveryClient注解没有关系了,也就是说只要开启了springboot的自动配置,服务注册发现功能就会启用。
 2、 EnableEurekaClient源码中没有使用注解EnableDiscoveryClient,此时EnableEurekaClient已经没用了。

<think>好的,用户遇到了Git克隆仓库时的认证失败问题。首先,我需要分析可能的原因。错误信息显示“HTTPBasic: Access denied”,所以问题应该出在认证环节。 用户使用的是HTTP协议,可能需要用户名和密码。但有时候,仓库可能需要SSH密钥或者更复杂的认证方式。不过这里明确提示了Basic认证失败,所以应该先检查用户名和密码是否正确。 接下来,用户可能没有在URL中提供凭证,导致Git弹出认证对话框,但可能自动填充的缓存凭证有误。这时候需要清除旧的凭证。在Windows上,可以指导用户去控制面板的凭据管理器里删除相关的Git凭证,然后重新尝试克隆,这样会提示输入新的用户名和密码。另外,用户可能使用了错误的分支名或者仓库地址,但错误信息明确指向认证问题,所以地址和分支的可能性较低。不过还是需要确认一下仓库是否存在以及分支是否正确。 还有一种情况是服务器端配置问题,比如权限设置不正确,但用户可能没有权限处理这个,所以优先考虑客户端的解决方案。 最后,建议用户使用SSH方式克隆,如果可能的话,因为SSH密钥更安全,避免每次输入密码。不过需要用户生成并添SSH密钥到Git服务器。这可能稍微复杂一点,但可以作为备选方案。 总结下来,步骤应该是:检查URL是否正确,清除旧凭证,重新输入正确的用户名密码,或者改用SSH方式。</think>出现 "Authentication failed" 错误表示 Git 无法通过 HTTP Basic 认证访问仓库。以下是解决方案: 1. **清除已保存的错误凭证** Windows 系统打开 `控制面板 > 用户账户 > 凭据管理器`,在 "Windows 凭据" 中删除所有 `http://192.168.101.123:5600` 相关的条目。 2. **显式添认证信息** 在 URL 中直接包含用户名(推荐临时使用): ```bash git clone http://<你的用户名>@192.168.101.123:5600/fcset/charge-cloud-fcset-parent-2.0.git ``` 系统会提示输入密码(注意密码输入时不显示字符) 3. **使用 SSH 协议替代 HTTP**(长期推荐) - 生成 SSH 密钥:`ssh-keygen -t rsa -C "your_email@example.com"` - 将公钥(`.ssh/id_rsa.pub` 内容)添到 Git 服务器账户 - 修改克隆命令为 SSH 地址: ```bash git clone git@192.168.101.123:fcset/charge-cloud-fcset-parent-2.0.git ``` 4. **验证网络访问权限** 尝试在浏览器中访问 `http://192.168.101.123:5600`,确认是否能正常打开 Git 仓库页面
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值