负载均衡之feign与ribbon的比较

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

负载均衡之feign与ribbon的比较

猜你喜欢