經過前兩天的環境搭建與基礎概念梳理,Day3的實戰正式進入了微服務的核心環節——服務注冊與發現。本以為照著教程能一帆風順,沒想到卻踏入了一個又一個“坑”,但也正是這些坑,讓我對Eureka、Nacos這些組件的理解從“知道”深化到了“懂得”。
1. Eureka Server 搭建:相對順利,主要配置了服務端端口、關閉自我保護模式(為了在測試環境更直觀地看到服務剔除)和實例名。
`yaml
server:
port: 8761
eureka:
instance:
hostname: localhost
client:
register-with-eureka: false # 單機版server,不自我注冊
fetch-registry: false
service-url:
defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
`
spring-cloud-starter-netflix-eureka-client依賴,并在配置文件中指向Eureka Server地址。RestTemplate或OpenFeign通過服務名進行調用。坑1:服務實例IP顯示異常,顯示為“127.0.0.1”或主機名
現象:Eureka控制臺的服務實例鏈接不可點,或指向錯誤地址。
原因:Eureka客戶端默認獲取的主機信息可能不正確,尤其是在Docker或多網卡環境中。
* 解決:在服務提供者的application.yml中強制指定IP地址和實例名。
`yaml
eureka:
instance:
prefer-ip-address: true
ip-address: 你的本機實際IP(如192.168.1.100)
instance-id: ${spring.cloud.client.ip-address}:${server.port} # 用IP:端口作為實例ID,更清晰
`
坑2:消費者無法通過服務名解析到提供者,報“UnknownHostException”
現象:訂單服務使用RestTemplate調用http://PRODUCT-SERVICE/product/1時,提示未知主機。
原因:RestTemplate默認沒有負載均衡能力,無法將服務名解析為具體的實例地址。
解決:有兩種方案:
方案A(使用LoadBalanced):在創建RestTemplate的Bean上添加@LoadBalanced注解。
`java
@Bean
@LoadBalanced // 關鍵注解!
public RestTemplate restTemplate() {
return new RestTemplate();
}
`
@EnableFeignClients,并編寫接口。坑3:OpenFeign接口編寫后,注入調用報“BeanCreationException”
現象:FeignClient接口定義無誤,但啟動時Spring容器創建Bean失敗。
原因:最常見的原因是依賴缺失或掃描路徑問題。
* 解決:
1. 檢查是否引入了spring-cloud-starter-openfeign依賴。
@EnableFeignClients注解的包掃描范圍能覆蓋到你的FeignClient接口。如果接口不在主類子包下,需指定:@EnableFeignClients(basePackages = "com.example.api")。坑4:服務下線后,Eureka控制臺仍有殘留(自我保護機制)
現象:手動停掉一個服務實例后,Eureka頁面仍顯示該實例,狀態為“DOWN”但未被剔除。
原因:Eureka Server的自我保護機制。當短時間內丟失過多客戶端(如網絡故障),Eureka會進入自我保護模式,保留所有實例,防止“誤殺”。這在生產環境是優點,在測試環境卻會造成困惑。
解決(僅供測試環境):
Server端:關閉自我保護,并縮短清理間隔。
`yaml
eureka:
server:
enable-self-preservation: false # 關閉自我保護
eviction-interval-timer-in-ms: 3000 # 清理間隔(毫秒)
`
* Client端:加快心跳和續約間隔。
`yaml
eureka:
instance:
lease-renewal-interval-in-seconds: 5 # 客戶端向服務端發送心跳的間隔(默認30秒)
lease-expiration-duration-in-seconds: 10 # 服務端收到最后一次心跳后等待時間,超時剔除(默認90秒)
`
今天的踩坑經歷,讓我深刻體會到開發與運維的緊密關聯。在微服務架構下:
instance-id、prefer-ip-address這樣的配置,直接決定了服務在注冊中心的“可觀測性”和“可維護性”。清晰的命名和準確的IP是后續進行日志追蹤、服務治理的基礎。成功打通服務調用后,明天將向更深處進發:
---
****:Day3是一場從“連接失敗”的焦慮到“調用成功”的狂喜的旅程。每一個Bug都不是絆腳石,而是通往更深層理解的階梯。微服務之路,道阻且長,行則將至。
如若轉載,請注明出處:http://m.goldentyre.cn/product/61.html
更新時間:2026-02-16 04:56:38