1.搭建pay-server工程
2.匯入相關依賴，註冊到eurekaserver (拷貝order-server相關**進行修改)
3.匯入feign的依賴
4.pay-server的主配置類開啟feign ： @enablefeignclients
5.pay-server編寫fiegn的客戶端介面:userfeignclient
6.pay-server編寫controller注入userfeignclient呼叫服務
前面的可以發現當我們通過resttemplate呼叫其它服務的api時，所需要的引數須在請求的url中進行拼接，如果引數少的話或許我們還可以忍受，一旦有多個引數的話，拼接請求字串就會效率低下。
1.2.什麼是feign2.1.建立工程
1.建立工程 springcloud-pay-server-1040，用來整合feign
2.2.匯入依賴
1.匯入eurekaclient的包--
>
org.springframework.cloud<
/groupid>
spring-cloud-starter-netflix-eureka-client<
/artifactid>
<
/dependency>
<
!--web包--
>
org.springframework.boot<
/groupid>
spring-boot-starter-web<
/artifactid>
<
/dependency>
<
!--user-common--
>
cn.itsource.springboot<
/groupid>
springcloud-user-common<
/artifactid>
<
/dependency>
<
/dependencies>
/**
* 支付的啟動類
* @enablefeignclients :開啟feign支援
*/@enableeurekaclient
public
class
}
#註冊到eurekaserver
#使用ip位址進行註冊
instance:
prefer-ip-address:
true
#要指定服務的例項id
instance-id: pay-server:
1040
server:
port:
1040
spring:
name: pay-server #服務名
3.1.加入依賴
org.springframework.cloud<
/groupid>
spring-cloud-starter-openfeign<
/artifactid>
<
/dependency>
主配置類增加@enablefeignclients標籤
/**
* 支付的啟動類
* @enablefeignclients :開啟feign支援
*/@enableeurekaclient
@enablefeignclients
("cn.itsource.springboot.feignclient"
)public
class
}
寫乙個userfeignclient 類（用來呼叫user服務的）
@feignclient
("user-server"
)public
inte***ce
userfeignclient
",method = requestmethod.get)
user getbyid
(@pathvariable
("id"
)long id)
;}
方法直接從目標服務controller中拷貝
3.4.編寫controller
//支付服務的controller
@restcontroller
public
class
paycontroller")
public user getbyid
(@pathvariable
("id"
)long id)
}
springcloud feign定製負載均衡
背景 開發，測試環境都使用了乙個註冊中心，所以在開發，測試環境不想進行負載均衡 原因 自己本地除錯方便，可能會負載到同事的機器上 註冊中心使用nacos 實現原理 獲取本機ip，從服務列表中獲取相同ip的服務例項進行呼叫 配置步驟 1 自定義負載策略 slf4j public class myrib...
springcloud（Ribbon負載均衡）
搭建步驟 1.使用者服務的集群 2.訂單服務整合ribbon 2.1.匯入ribbon的依賴 2.2.在resttemplate的bean定義方法上加上 loadbalanced註解 2.3.把訂單的controller向使用者發起呼叫的resttemplate的url使用服務名呼叫，如 http ...
SpringCloud Ribbon 負載均衡
ribbon eureka都是netflix旗下的專案，eureka client內建了ribbon，用於實現負載均衡，預設使用輪詢。輪詢是最簡單的負載均衡演算法，每次呼叫服務拿到節點列表後，從前往後依次輪詢類表中的每個節點，誰空閒就呼叫誰。測試時往往都是呼叫列表的第乙個節點，因為重新整理的手速遠遠...