在业界,常规的微服务有两种类型:一种是基于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: 8071
eureka:
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
@Slf4j
public 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接口时候,第一次调用会因为超时而导致调用失败,所以需要设置超时时长