本指南详细介绍如何搭建一个单节点的 Eureka 服务注册中心,并让 Spring Cloud 微服务注册到 Eureka。同时讲解如何搭建 Spring Cloud Config 配置中心(使用 Gitee 代码仓库存放配置),以及客户端微服务如何从配置中心读取远程配置、实现配置更新的自动刷新(利用 Spring Cloud Bus 消息总线)。文中使用 Spring Boot 2.7.x 搭配 Spring Cloud 2021.x 版本作为示例环境spring.iospring.io。示例中每一步都提供关键的 POM 依赖配置和 application.yml 配置片段,并给出注意事项和常见错误的排查方法。
一、搭建单节点 Eureka Server
Eureka Server 是 Netflix 提供的服务注册与发现组件。我们首先搭建一个单节点(非高可用集群)的 Eureka 服务注册中心,用于注册和管理微服务实例。单节点部署时,需要避免 Eureka Server 将自己作为客户端再次注册到自身cnblogs.com。
搭建步骤:
-
创建工程并引入依赖: 创建一个新的 Spring Boot 项目(建议使用 Spring Boot 2.7.x)。在项目的 Maven POM 文件中引入 Eureka Server 的起步依赖和 Spring Cloud BOM。例如:
<dependencyManagement> <dependencies> <!-- 引入 Spring Cloud 2021.x 依赖版本管理 BOM --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>2021.0.5</version> <!-- 示例版本,可按需调整 --> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <!-- Eureka Server 服务端依赖 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId> </dependency> <!-- (可选)Actuator 依赖,用于健康监控等 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> </dependencies>上述依赖引入了 Eureka Server 模块。在 Spring Boot 主类上添加
@EnableEurekaServer注解,开启 Eureka 服务注册中心功能javafullstackdev.medium.comjavafullstackdev.medium.com。 -
配置 Eureka Server 应用参数: 在
src/main/resources下创建应用配置文件,建议使用 application.yml。配置如下:yaml server: port: 8761 # Eureka Server 启动端口(常用8761) spring: application: name: eureka-server # 应用名称(可选) eureka: instance: hostname: localhost # 本机hostname,可换成IP或域名 client: register-with-eureka: false # 单节点时,禁止向自己注册​:contentReference[oaicite:5]{index=5} fetch-registry: false # 单节点时,不从别的 Eureka 拉取注册表​:contentReference[oaicite:6]{index=6}配置解释:将
register-with-eureka和fetch-registry都设置为 false,表示这个 Eureka Server 不作为客户端注册自身,也不去拉取其他 Eureka 节点的服务列表cnblogs.com。hostname可设置为服务注册中心对外公告的地址。在单机环境下,上述配置足以启动一个 Eureka 注册中心。 -
启动并验证: 运行 Eureka Server 应用。在控制台日志看到
Started EurekaServerApplication字样且无错误后,访问http://localhost:8761/可以查看 Eureka Server 的管理界面。初次打开时,由于尚未有微服务注册,界面上应显示没有可用的服务实例。至此,单节点 Eureka Server 注册中心已经成功搭建。
注意: 单节点部署主要用于开发和测试,不需要配置高可用。生产环境若需高可用,可部署多个 Eureka Server 实例组成集群,但那不在本文讨论范围。确保 Eureka Server 所在主机的防火墙放行了8761端口,客户端才能正常注册。
二、配置微服务注册到 Eureka
有了注册中心后,我们需要将各个 Spring Cloud 微服务注册到 Eureka 上。下面以一个示例微服务说明如何进行配置,使其在启动时自动向 Eureka 服务注册中心注册自身。
主要步骤:
-
添加 Eureka Client 依赖: 在微服务的 Maven POM 中引入 Eureka Client 的起步依赖。通常使用
spring-cloud-starter-netflix-eureka-client来包含 Eureka 客户端功能piterjia.github.io。例如:<dependencies> <!-- Eureka Client 客户端依赖 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency> <!-- 一般微服务还需要 Web 和 Actuator 依赖 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> </dependencies>确保该微服务也使用与 Eureka Server 相同的 Spring Cloud BOM 管理依赖版本,以避免版本不兼容问题。
-
启用 Eureka 客户端注解(可选): 在微服务的主启动类上,可以添加
@EnableDiscoveryClient或@EnableEurekaClient注解来显式启用服务发现客户端。piterjia.github.io不过,当引入了 Eureka Client 依赖后,Spring Boot 会自动配置服务注册,添加注解只是出于明确语义,非必需。 -
配置应用名称和 Eureka 注册中心地址: 在微服务的
application.yml中,配置基本参数:应用名、服务端口,以及 Eureka 客户端指向 Eureka Server 的地址。例如:yaml server: port: 8081 # 微服务启动端口,不与其他服务冲突 spring: application: name: order-service # 微服务名称,将作为 Eureka 中的服务ID eureka: instance: prefer-ip-address: true # 可选:注册时优先使用IP地址而非主机名 client: service-url: defaultZone: http://localhost:8761/eureka # Eureka Server 的地址​:contentReference[oaicite:10]{index=10} # 如果有多个配置,可用逗号分隔多个URL配置解释:
spring.application.name设置微服务在 Eureka 中注册的名称;defaultZone指定 Eureka 服务注册中心的访问地址(假定 Eureka Server 部署在本机8761端口)blog.csdn.net。prefer-ip-address: true会让服务注册时使用IP,有助于避免由于主机名解析导致的连接问题。 -
启动并验证注册: 先确保 Eureka Server 已经启动。然后启动该微服务应用。在启动日志中应能看到与 Eureka 交互的日志信息,例如定时发送心跳等。打开 Eureka Server 管理界面刷新页面,应看到 order-service 已出现在“Instances currently registered with Eureka”列表中,状态为 UP。这说明微服务成功注册到了 Eureka。
注意: 微服务启动后每隔30秒会向 Eureka 发送心跳,Eureka 默认90秒收不到心跳则将实例剔除cnblogs.comcnblogs.com。因此确保微服务和 Eureka Server 的时间同步和网络连通。如果微服务没有出现在注册列表:
-
请检查 Eureka Server 地址是否配置正确,网络是否可达。
-
确认微服务的应用名不为空,且依赖和注解配置正确。
-
查看微服务日志中是否有 Eureka 相关错误提示,例如认证错误或连接超时。
三、搭建 Spring Cloud Config Server(使用 Gitee 远程仓库)
Spring Cloud Config Server 用于集中管理分布式系统的配置。我们将搭建一个 Config Server,并使用 Gitee 上的 Git 仓库存放配置。Config Server 会从远程仓库拉取配置文件,供客户端微服务按需获取。
配置中心服务端搭建步骤:
-
创建 Config Server 工程并添加依赖: 新建一个 Spring Boot 应用(可与 Eureka Server 分开部署,也可以作为独立微服务)。在 POM 中引入 Config Server 起步依赖:
<dependencies> <!-- Spring Cloud Config Server 依赖 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-config-server</artifactId> </dependency> <!-- (可选)Eureka Client 依赖,将配置中心注册到 Eureka 以供发现 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency> <!-- (可选)Bus 消息总线依赖,后续用于配置刷新 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-bus-amqp</artifactId> </dependency> </dependencies>引入上述依赖后,在配置中心的启动类上添加
@EnableConfigServer注解,启用配置中心服务端功能cnblogs.comcnblogs.com。如果希望 Config Server 本身也注册到 Eureka,还需确保加了 Eureka Client 依赖和相关配置。 -
准备远程 Git 仓库(Gitee): 在 Gitee 上创建一个用于存放配置的代码仓库(例如 config-repo)。仓库可以选择公开(公开仓库读取无需凭证)或私有。如果是私有仓库,需要配置访问凭证。为了简单,建议初次尝试使用公开仓库。
在该仓库中,根据 Spring Cloud Config 的命名规则添加配置文件。例如,可以创建文件:-
application-dev.yml:全局默认配置(应用名为 "application" 表示通用配置),用于开发环境。 -
或为每个微服务创建独立配置,如
order-service-dev.yml对应 order-service 微服务在 dev 环境的配置。
命名约定: 默认格式为{application}-{profile}.yml(或.properties),其中 application 对应微服务的spring.application.name,profile 是环境名称blog.csdn.net。也可以使用仓库的分支来区分环境(对应 Config Server 请求中的 label 参数)。
-
-
配置 Config Server 连接 Gitee 仓库: 在 Config Server 的
application.yml中,设置 Git 仓库的地址及必要的属性,例如:yaml server: port: 8888 # Config Server 默认端口一般设为8888 spring: application: name: config-server # 配置中心服务名(注册到 Eureka 可用) cloud: config: server: git: uri: https://gitee.com/<你的用户名>/<仓库名>.git # 远程Git仓库URL clone-on-start: true # (可选)启动时立即克隆仓库​:contentReference[oaicite:17]{index=17}​:contentReference[oaicite:18]{index=18} search-paths: config # (可选)搜索路径,如果配置文件不在仓库根目录 username: <用户名> # 私有仓库时的用户名​:contentReference[oaicite:19]{index=19} password: <密码或访问令牌> # 私有仓库访问密码或Gitee个人访问Token​:contentReference[oaicite:20]{index=20} # 如果使用分支存储配置,可加 label 属性指定默认分支,如: # label: master eureka: client: service-url: defaultZone: http://localhost:8761/eureka # (可选)将配置中心注册到 Eureka​:contentReference[oaicite:21]{index=21}配置讲解:
-
spring.cloud.config.server.git.uri指定 Gitee 仓库的 Git 地址。如果仓库是公开的,用 HTTPS URL 即可直接访问;如果是私有仓库,需要同时提供username和password(推荐使用个人访问令牌作为密码,以提高安全性)cnblogs.com。也可以使用 SSH 地址(例如git@gitee.com:用户名/仓库.git),此时需配置 SSH 私钥(spring.cloud.config.server.git.privateKey)cnblogs.com或确保主机已配置相应 SSH 公钥信任blog.csdn.netblog.csdn.net。 -
clone-on-start: true表示 Config Server 启动时立即从远程获取配置github.comgithub.com,避免首次请求时延迟。 -
search-paths若仓库中把配置文件放在子目录下,需要指定。例如上例设为config则会在仓库的 config/ 目录下寻找配置blog.csdn.net。如果配置文件在仓库根目录,可不配置此项。 -
eureka.client.service-url.defaultZone若填写,则 Config Server 将自身作为客户端注册到 Eureka 服务中心,方便其它微服务通过服务发现找到配置中心(需配合客户端的 discovery 配置,后文介绍)。若不需要可省略。
-
-
启动 Config Server 并验证: 启动配置中心应用,观察日志确认成功克隆了远程仓库配置(日志会显示 Git 克隆信息)。访问 Config Server 提供的配置读取接口,例如:
http://localhost:8888/order-service/dev这将返回仓库中 order-service-dev.yml 文件的内容(以JSON格式输出)。如果返回了正确的配置数据,则说明 Config Server 正常工作。若返回错误或找不到文件,请检查仓库URL、凭证以及文件命名是否正确匹配请求的应用名和profile。
注意: 使用 Gitee 私有仓库时:
-
公开仓库无需配置凭证,但私有仓库必须提供认证信息。可采用 HTTP Basic(username/password)方式cnblogs.com,或 SSH 方式cnblogs.com。若使用个人访问令牌(Access Token),在 Gitee 用户设置中生成 Token,然后将其当作密码使用(username填写Gitee用户名)。
-
Gitee 克隆可能需要信任主机密钥。使用 SSH URL 时,可能出现 “
reject HostKey: gitee.com” 错误blog.csdn.net。解决方法是预先在服务器上配置好 SSH 公私钥并将公钥添加到 Gitee 信任,或者在 Config Server 配置中添加spring.cloud.config.server.git.ignoreLocalSshSettings=true和相应的私钥配置cnblogs.com。简单起见,推荐初次尝试使用 HTTPS 加用户名/密码方式。 -
Config Server 默认会缓存从Git拉取的配置,如需强制拉取最新,可以调用刷新端点(后续介绍)或者将
spring.cloud.config.server.git.refreshRate调小。一般无需修改,除非配置更新频繁且不使用通知机制。
四、配置客户端微服务读取远程配置
搭建好 Config Server 后,微服务(Config Client)需要从配置中心获取其配置,而不是使用本地的 application.yml 中硬编码配置。Spring Cloud 提供了 Config Client 来在应用启动时获取远程配置。
客户端配置步骤:
-
引入 Config Client 依赖: 在需要从配置中心获取配置的微服务的 POM 中,加入 Spring Cloud Config 客户端起步依赖:
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-config</artifactId> </dependency>这样应用在启动时即可启用从 Config Server 拉取配置的能力。
-
配置 Config Server 地址: 微服务需要知道配置中心的位置。推荐在启动阶段就获取配置,因此可以使用 bootstrap.yml(在 Spring Boot 2.4+ 也可以使用 application.yml 的
spring.config.import)。为简单起见,这里使用bootstrap.yml:yaml spring: application: name: order-service # 应用名称,要和配置仓库中的文件名匹配 cloud: config: uri: http://localhost:8888 # 配置中心的访问地址(Config Server的URL) profile: dev # 要加载的配置profile(如开发环境dev)​:contentReference[oaicite:33]{index=33}​:contentReference[oaicite:34]{index=34} label: master # 可选:配置仓库的分支名,默认为master # 如果希望通过服务发现找Config Server,可用以下配置替代uri: # discovery: # enabled: true # service-id: config-server # Config Server在Eureka注册的服务名​:contentReference[oaicite:35]{index=35}​:contentReference[oaicite:36]{index=36}配置解释:
-
spring.application.name应用名称必须与配置仓库中相应配置文件的名字部分一致。例如这里是 order-service,则仓库应有 order-service-dev.yml。 -
spring.cloud.config.uri直接指定了 Config Server 的地址和端口。如果 Config Server 也注册到了 Eureka,并且想让客户端通过服务发现动态定位,可以使用discovery.enabled=true和指定service-id(如上注释所示),这样 Config Client 会先从 Eureka 查找名为 config-server 的服务地址github.comgithub.com。需注意此模式下,客户端自身也需要先注册到 Eureka,且可能需要在本地有最基本的 Eureka 配置。一般小型项目直接配置uri更简单。 -
spring.cloud.config.profile指定要加载哪个环境的配置文件,比如 dev、prod 等github.com。当有多个profile时可用逗号分隔或使用 Spring 的多环境激活机制。 -
spring.cloud.config.label指定Git仓库的分支,默认为 master 主分支。如果使用了其他分支存储配置(如 dev 分支保存开发环境配置),需要设置此项匹配。
-
-
启动顺序与验证: 确保配置中心 Config Server 先启动且运行正常。然后启动客户端微服务。在客户端启动日志中,应能看到从配置中心拉取配置的日志,例如“Fetching config from server at: http://localhost:8888”之类的字样。如果获取成功,应用将把远程配置应用到环境中。可以通过输出配置信息或访问Actuator的
/actuator/configprops来验证配置是否生效。若客户端启动时报错无法连接配置中心,可能原因:Config Server 未启动、
spring.cloud.config.uri配置不正确,或网络不通。如果只是配置未生效或部分属性缺失,检查应用名和profile是否匹配仓库中的文件名。注意:默认情况下,如果无法从配置中心获取配置,应用仍会启动(非fail-fast),但会使用本地默认配置或报错。可通过设置spring.cloud.config.fail-fast=true来让获取失败时终止启动,以防止应用在错误配置下运行。 -
使用远程配置: 客户端微服务获取的远程配置会注入到Environment中。业务代码中可以像平时一样使用
@Value或@ConfigurationProperties注解来注入配置值。如果希望在运行过程中刷新配置,需要对相应的Bean使用@RefreshScope注解。比如:@RefreshScope @RestController public class TestController { @Value("${my.custom.prop}") private String myProp; // ... }
注意: 配置文件的组织方式可以灵活调整。例如可在仓库中建立按应用名的子文件夹分类配置,需配合 Config Server 的 search-paths 设置blog.csdn.net。另外,如果多个微服务共享一些通用配置,可以利用 application.yml(应用名为 "application")作为所有服务的默认配置文件,被各客户端自动加载。客户端请求配置时,Config Server 会按顺序返回 {application}.yml 和 {application}-{profile}.yml 合并后的结果blog.csdn.net。
五、实现配置的自动刷新(Spring Cloud Bus)
当我们更新了配置仓库中的配置文件时,希望客户端微服务能够无需重启地刷新加载新的配置。Spring Cloud Bus 利用消息代理(如 RabbitMQ 或 Kafka)广播配置变更事件,实现分布式系统中配置的动态刷新mrbird.cc。下面介绍如何集成 Spring Cloud Bus 来自动拉取配置更新。
步骤与要点:
-
准备消息代理: Spring Cloud Bus 目前支持 RabbitMQ 和 Kafka 两种消息中间件。这里以 RabbitMQ 为例(因为配置相对简单)。请确保环境中已部署 RabbitMQ 服务,并记录其地址、用户名和密码。默认情况下,RabbitMQ 本地安装后用户名密码为
guest/guest,管理端口为 15672,AMQP 端口为 5672github.comgithub.com。 -
引入 Bus 依赖: 在 配置中心 和 所有需要自动刷新的客户端微服务 的 POM 中都添加 Spring Cloud Bus RabbitMQ 的起步依赖(若之前步骤中已添加则无需重复):
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-bus-amqp</artifactId> </dependency>同时确保有 Spring Boot Actuator 依赖,以便暴露刷新端点(前述步骤已经添加过)。引入依赖后,应用会自动加入 Spring Cloud Bus 总线,并通过消息中间件与其他节点通信mrbird.cc。
-
配置 RabbitMQ 连接和 Actuator 端点: 在配置中心和客户端的 application.yml 中,添加 RabbitMQ 的连接信息,以及开启 Bus 刷新端点暴露:
yaml spring: rabbitmq: host: localhost # RabbitMQ 主机 port: 5672 # RabbitMQ 端口 username: guest # 用户名 password: guest # 密码 management: endpoints: web: exposure: include: "bus-refresh,refresh" # 暴露bus-refresh端点(配置中心用),refresh端点(客户端用)​:contentReference[oaicite:46]{index=46}​:contentReference[oaicite:47]{index=47}配置说明:
-
spring.rabbitmq.*部分告知应用如何连接 RabbitMQ。请根据实际安装地址修改,如果 RabbitMQ 不在本机或使用了自定义账户,请调整 host 和认证信息。 -
management.endpoints.web.exposure.include用于开放 Spring Boot Actuator 的HTTP端点。这里在配置中心开启了bus-refresh,在客户端开启了refresh(也可以统一都开启"bus-refresh,refresh")。这样,我们可以调用/actuator/bus-refresh来广播刷新,也可以单独调用某个实例的/actuator/refresh。github.comgithub.com -
确保 Actuator 总线刷新端点受保护(默认情况需要通过POST请求并有合适的权限策略,生产中可考虑安全性,如通过微服务网关或token限制访问)。
-
-
触发配置刷新: 当需要加载新的配置时,有两种方式:手动触发和使用 webhook 自动触发。
-
手动触发: 使用 HTTP 客户端(如
curl或 Postman)发送 POST 请求到 任意一个微服务实例的/actuator/bus-refresh端点。通常选定 Config Server 自身或者某一个服务来触发即可。例如:POST http://localhost:8888/actuator/bus-refreshbash
(如果 Config Server 没有开启 Bus,则可以选择任意一个已引入 Bus 的微服务实例地址替换上述URL)。收到请求后,该实例会从远程仓库拉取最新配置,并通过消息总线将刷新事件广播给其他所有微服务blog.csdn.netblog.csdn.net。各个微服务收到事件后都会重新到配置中心获取新配置并更新自身配置(需要配合
@RefreshScope生效)。整个过程实现了集群配置的“一键刷新”。 -
自动触发(可选): 可以利用代码仓库的 WebHooks 功能。当 Gitee 上的配置仓库有新的提交时,让其自动向应用的
/actuator/bus-refresh发送一个POST请求。这样开发人员每次push配置更改后,系统就能自动完成刷新,而无需手动调用接口blog.csdn.net。配置WebHook时需要提供一个可以访问应用的URL;若应用在内网不可直接访问公网,可以借助代理或公网网关来转发。由于直接暴露敏感端点有安全风险,可以考虑在应用层添加一个自定义受限的刷新接口映射到/actuator/bus-refresh(如将 WebHook 指向一个受保护的URL,再由应用内部转发调用 bus-refresh)blog.csdn.netblog.csdn.net。根据实际需求决定是否启用 WebHook 自动化。
-
-
验证刷新效果: 可在客户端微服务中设置一个接口读取某配置值用于测试。例如创建一个简单的 Controller 返回配置属性值。启动 Eureka、Config Server、RabbitMQ 和两个实例的客户端微服务。修改 Gitee 仓库中的配置文件内容并提交,然后触发
/actuator/bus-refresh。几秒钟后,再次调用客户端的测试接口,应当看到配置值已经更新,且所有客户端实例都同步刷新blog.csdn.netblog.csdn.net。这样就确认了 Spring Cloud Bus 自动刷新配置的功能。
注意:
-
使用 Spring Cloud Bus 需要确保所有相关服务都连接到了同一个消息代理(RabbitMQ/Kafka),否则消息无法传递。启动时可以在 RabbitMQ 管理界面观察到 Spring Cloud Bus 为每个实例创建的队列和交换机github.comgithub.com。
-
如果对安全要求高,不想直接暴露
/bus-refresh给外部,可仅在内部网络调用,或者在触发刷新时要求认证(可以结合 Spring Security 或 Gateway 实现)。 -
对于不频繁更改的配置,也可以不使用消息总线,每次改动后通过手动调用各个实例的
/actuator/refresh接口或重启服务来加载新配置。但在微服务较多时效率低,推荐使用 Bus。 -
若引入 Spring Cloud Bus 后应用启动报 RabbitMQ 连接错误,检查 RabbitMQ 服务是否启动并且配置是否正确。必要时可以在配置中指定
spring.rabbitmq.addresses(含虚拟主机等高级选项)或者使用 Kafka 替代。
六、版本选择和依赖管理
本指南示例采用 Spring Boot 2.7.x + Spring Cloud 2021.x (Jubilee) 版本组合。这是一个经过长期支持(LTS)的稳定组合spring.io。在 Maven 中,可以通过引入 Spring Cloud 2021 的 BOM 来管理依赖版本,以确保 Eureka、Config、Bus 等组件的兼容性javafullstackdev.medium.com。例如,在 pom.xml 中:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.7.15</version> <!-- Spring Boot 2.7.x 最新版本 -->
</parent>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>2021.0.5</version> <!-- Spring Cloud 2021.x 最新发布版本 -->
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
通过以上方式引入依赖,无需手动指定各个 Spring Cloud 组件的版本。Spring Cloud 2021 版与 Spring Boot 2.7.x 完美兼容spring.io。如果需要使用 Spring Boot 3.x,则应升级到 Spring Cloud 2022.x 或更高版本以获得官方支持。由于 Spring Boot 3+ 需要 Java 17 且对部分组件有变更(如不再直接包含 Netflix Eureka,需要单独引入兼容),在此不作展开。对于新项目,2.7.x + 2021.x 组合稳定且社区资料丰富,适合入门实践。
依赖版本推荐: Spring Boot 2.7.15(2025年最新补丁),Spring Cloud 2021.0.5 或 2021.0.6(Jubilee SR版),Spring Cloud Alibaba 2021.x(如果使用阿里巴巴组件,可选)。确保使用 Maven Central 可用的正式版本,并避免混用不兼容的版本。如果不确定版本兼容性,可参考 Spring 官方发布的兼容性说明spring.iospring.io。
七、常见错误及排查方法
在搭建和运行 Eureka 注册中心与配置中心的过程中,可能会遇到一些常见问题。以下列出若干典型错误场景及解决思路:
-
无法连接 Eureka Server: 微服务启动时报错无法注册,或 Eureka 控制台看不到服务。首先检查微服务的 Eureka 客户端配置的
defaultZoneURL 是否正确(地址和端口是否指向 Eureka Server)blog.csdn.net。确保 Eureka Server 已启动且端口开放。其次,查看微服务日志,有没有出现 “Cannot execute request on any known server” 或类似错误。如果有,可能是 Eureka Server 地址不可达或者网络延迟过高。排查服务器防火墙或网络配置。在本地开发环境,注意不要同时启动多个 Eureka Server 实例占用端口。单节点模式下 Eureka Server 日志可能提示自身注册被跳过(因为我们设置了不注册自己),这是正常现象。 -
配置中心无法拉取 Git 仓库: Config Server 启动时报错,常见信息如 “
I/O error on Git operation”、“Authentication failed” 或 “reject HostKey”。-
若是 认证失败,请核实提供的用户名密码是否正确(特别是 Token 是否有正确的权限)。可以尝试用相同的 URL 和凭证在同一台机器上手动执行
git clone,确认仓库可访问blog.csdn.net。如果手动也失败,则问题在于凭证或网络。 -
若是 HostKey 拒绝(使用 SSH方式),按照前文步骤配置本机的 SSH 公私钥,并在 Gitee 上添加公钥blog.csdn.net。或者改用 HTTPS 模式访问。
-
若 Config Server 提示找不到某个配置文件(HTTP 404),检查仓库中是否存在对应的
{application}-{profile}.yml文件,以及 Config Client 请求的 application name 和 profile 是否拼写正确。 -
如果 Config Server 长时间不刷新配置(缓存问题),可以尝试重启 Config Server,或者在其上调用
/actuator/refresh(需要引入 Actuator 并暴露)来强制清除缓存。
-
-
客户端获取配置失败: 如果微服务启动时没有成功从配置中心获取配置,表现为配置没有生效或应用直接启动了默认配置。请检查 Config Client 的
bootstrap.yml是否放置正确(注意:在 Spring Boot 2.4+,默认不再启用 bootstrapContext,需要确保引入了 spring-cloud-starter-bootstrap 或正确配置了spring.config.import)github.comgithub.com。为了简化,可继续使用bootstrap.yml来提前加载。确认其中的spring.cloud.config.uri能访问,并且 profile 和应用名正确。还可以查看微服务启动日志中有没有 "Fetching config from server" 之类的记录;如果完全没有相关日志,可能是 Config Client 没有启用(依赖缺失或配置文件名不对)。另外,若 Config Server 使用了自签名证书的HTTPS,客户端可能需要信任证书。 -
配置刷新无效: 调用了
/actuator/refresh或/actuator/bus-refresh后,发现客户端配置未更新。可能原因:-
没有在需要刷新的 Bean 上添加
@RefreshScope,导致新的配置值拉取后没有注入到现有Bean中。解决办法:对使用配置的组件加上@RefreshScopeblog.csdn.net并确保刷新时该组件会重建或重新读取配置。 -
如果使用 Bus,可能是消息总线未正确配置。检查 RabbitMQ 是否连通,每个服务是否都引入了
spring-cloud-starter-bus-amqp。可以在 RabbitMQ 管理控制台观察springCloudBus交换机下是否有队列绑定github.comgithub.com。如果没有,说明有服务未正确连接总线。 -
/actuator/bus-refresh返回404或无法访问:确认已经在 Config Server 或某个客户端的management.endpoints.web.exposure.include中包含了bus-refreshgithub.com。Spring Boot 2.x默认只开放健康和info,需要手动开放bus-refresh端点。确保使用 POST 请求访问,而非 GET。 -
Gitee 仓库的配置修改后未生效:确认修改已提交推送到远程仓库,并且使用正确的方法触发了刷新(手动调用或 WebHook)。有时忘记推送代码到远程就刷新,会导致 Config Server 仍然返回旧配置。
-
-
其他错误:
-
端口冲突:确保 Eureka Server (8761)、Config Server (默认8888) 和各微服务的端口互不冲突。如果端口被占用,启动会失败或注册不上。调整
server.port配置即可。 -
版本不兼容:如果使用了不匹配的 Spring Boot 和 Spring Cloud 版本,可能出现类找不到或启动报错。请按照上述推荐版本使用,或者参考 Spring Cloud 官方兼容列表确保依赖匹配spring.io。
-
Eureka 自我保护模式:Eureka Server 如果检测到短时间内大量服务心跳丢失,会进入自我保护模式,不清除过期实例。这在网络不稳定时可能导致已下线的服务仍然显示为UP。可以在 Eureka Server 配置中关闭自我保护(
eureka.server.enable-self-preservation: false)用于测试环境,但生产环境建议保留默认保护机制。
-
通过以上步骤和注意事项,基本可以完成一个 Spring Cloud 微服务架构中服务注册中心和配置中心的搭建,并实现配置的集中管理与动态刷新。在实际项目中,根据需要还可以引入网关、负载均衡、熔断等组件,但有了注册中心和配置中心,已经为微服务体系奠定了基础。希望这份资料能帮助你顺利搭建环境,避免踩坑。如遇问题,可结合日志信息及上述排查方法定位解决。祝搭建成功!
528

被折叠的 条评论
为什么被折叠?



