負載均衡之feign與ribbon的比較
- 摘要：在業界,常規的微服務有兩種型別:一種是基於dubbo的微服務架構、另外一種是基於SpringCloud的微服務架構。從概念上來講,Dubbo和SpringCloud並不能放在一起對比,因為Dubbo僅僅是一個RPC框架,實現Java程式的遠端呼叫,實施服務化的中介軟體則需要自己開發;而SpringCloud則是實施微服務的一系列套件,包括:服務註冊與發現、斷路器、服務狀態監控、配置管理、智慧路由、一次性令牌、全域性鎖、分散式會話管理、叢集狀態管理等。 在一開始做服務消費
-
在業界,常規的微服務有兩種型別:一種是基於dubbo的微服務架構、另外一種是基於Spring Cloud的微服務架構。從概念上來講,Dubbo和Spring Cloud並不能放在一起對比,因為Dubbo僅僅是一個RPC框架,實現Java程式的遠端呼叫,實施服務化的中介軟體則需要自己開發;而Spring Cloud則是實施微服務的一系列套件,包括:服務註冊與發現、斷路器、服務狀態監控、配置管理、智慧路由、一次性令牌、全域性鎖、分散式會話管理、叢集狀態管理等。
在一開始做服務消費者這邊時,就在考慮改用ribbon來做負載均衡好,還是使用feign來做負載均衡好;
我們可以來對比一下兩者之間的寫法:
ribbon:
feign:
最終我選擇了feign來進行負載均衡:
原因有以下幾點:
1. feign本身裡面就包含有了ribbon
2. feign自身是一個宣告式的偽http客戶端,寫起來更加思路清晰和方便
3. fegin是一個採用基於介面的註解的程式設計方式,更加簡便
注意feign裡面開啟熔斷器處理時,需要有以下配置:
server: port: 8071eureka: client: service-url: defaultZone:
http://peer1:8082/eureka/spring: application: name: service-feign hystrix: enabled: true熔斷器的配置就拿一個訂單的熔斷器來說吧,需要繼承相應的訂單feign介面,並且在
註解裡面的@feignclient裡面申明到fallback會呼叫到訂單的熔斷器類
@FeignClient(name = "total-service",fallback = OrderHystrics.class)public interface OrderFeignClient { public static final
String version="/v0/order/"; @RequestMapping(value =version+"sending/order/batch") @ApiOperation(value = "獲取使用者所有的發貨中訂單內容",notes = "獲取使用者所有的發貨中訂單內容") @ApiImplicitParams({ @ApiImplicitParam(name = "sessionKey", value = "sessionKey校驗器key", dataType = "String",paramType = "query"), @ApiImplicitParam(name = "page", value = "頁數", dataType = "int",paramType = "query") }) public List<Object> sendingOrder(@RequestParam(name = "sessionKey") String sessionKey, @RequestParam(name = "page") int page);}
熔斷器部分程式碼:
@Component @Slf4jpublic class OrderHystrics implements OrderFeignClient { @Override public List<Object> sendingOrder(String sessionKey, int page) { Date date=new Date(); log.warn(date.toString()+"sendingOrder出現異常!請管理員儘快處理"); return null; }
}
一般在feign呼叫相應的service介面時候,第一次呼叫會因為超時而導致呼叫失敗,所以需要設定超時時長