标签：Feign 服务 请求 spring Eureka 组件 cloud

我在spring boot & spring cloud关系？里曾说到下次讲spring cloud的核心组件。那为什么说到spring cloud就要提到spring cloud的核心组件呢？

spring cloud都提供了分布式系统一整套解决方案。相信大家刚接触微服务，刚接触spring cloud的时候，经常会看到这句话吧。那这句话究竟是什么意思？什么叫分布式系统？什么又叫一整套解决方案呢？

什么是分布式系统？

简单来说，一个项目变的越来越大后，越来越难维护。然后就会把一个项目拆成多个项目或者叫服务。这样一个大项目大系统就变成了分布式系统。项目和服务间的差别大概是大小间的差别吧。微服务应该比分布式系统拆分的粒度更小吧。慢慢的，分布式系统和微服务差别不大吧，或者说微服务本来就是属于分布式系统。一个微服务也相当于是一个系统。

什么又叫一整套解决方案？

一整套解决方案是针对一个完整的系统来说的。一个大型的项目拆成多个服务，会涉及很多问题。比如说服务间如何调用？比如说知道服务的地址后，一个服务要自己写一大堆代码，跟其他服务建立网络连接，然后构造一个复杂的请求，接着发送请求过去，最后对返回的响应结果再写一大堆代码来处理吗？那这样，微服务不是复杂度还提高了吗？等等等。所以说一整套解决方案解决的就是多个服务间这一系列的问题。所以说，这也是为什么要提到spring cloud的核心组件，因为核心组件解决的就是这些问题。

假设一个大的项目我把它拆成了这些服务。

那么，问题1： 一个服务想要调其他服务时，不知道ip端口，我该怎么调用呢？而且其他服务这么多，该怎么记呢？

 Eureka

Eureka 是微服务架构中的注册中心，专门负责服务的注册与发现。

Eureka Client：负责将这个服务的信息注册到 Eureka Server 中。

Eureka Server：注册中心，里面有一个注册表，保存了各个服务所在的机器和端口号。

当所有服务共用一个Eureka Server时，每个服务对应的Eureka Client会把该服务信息注册到Eureka Server。然后一个服务想要调用其他服务时，该服务的Eureka Client 组件会找 Eureka Server 问一下要调用的服务信息，然后该服务就有其他服务的信息了，就可以进行调用了。

那么问题又来了，难道一个服务要自己写一大堆代码，跟其他服务建立网络连接，然后构造一个复杂的请求，接着发送请求过去，最后对返回的响应结果再写一大堆代码来处理吗？

Feign

前面的问题显然是不用的，因为框架的目的本来就是简化开发，要真那样的话，开发变的那么复杂，又何必要使用框架呢！

那解决方案呢，就是使用spring cloud的另一个组件Feign。直接就是用注解定义一个 Feign Client 接口，然后调用那个接口就可以了。

 Feign 的一个关键机制就是使用了动态代理。当对某个接口定义了 @FeignClient 注解，Feign 就会针对这个接口创建一个动态代理。如果要调用那个接口，本质就是会调用 Feign 创建的动态代理（Feign的动态代理会根据你在接口上的 @RequestMapping 等注解，来动态构造出你要请求的服务的地址），这是核心中的核心。针对动态代理的这个地址，发起请求、解析响应。相当于就解决了最开始提及的问题（难道一个服务要自己写一大堆代码，跟其他服务建立网络连接，然后构造一个复杂的请求，接着发送请求过去，最后对返回的响应结果再写一大堆代码来处理吗）。

Ribbon

所以说到这，还有什么问题吗，Feign能调服务，Eureka能找到服务。微服务间主要的调用问题解决全了吗？一个大型的服务，我可以部署到多台服务器上，一个挂了还能用另一个。那微服务呢？当然也是一样的。也可以把一个服务部署到多台机器上。那现在再想想，是不是又出现问题了，一个服务在多台机器上，我用哪个机器上的服务呢？Feign 怎么知道该请求哪台机器呢？

Ribbon 就是专门解决这个问题的。它的作用是负载均衡，会帮你在每次请求时选择一台机器，均匀的把请求分发到各个机器上。它有自己默认的算法，也可以自定义算法。其实Feign里是集成了Ribbon的，用的就是Ribbon默认的随机策略。

Ribbon  Feign  Eureka 工作

首先 Ribbon 会从 Eureka Client 里获取到对应的服务注册表，也就知道了所有的服务都部署在了哪些机器上，在监听哪些端口号。然后 Ribbon 就可以使用默认的 Round Robin 算法，从中选择一台机器。Feign 就会针对这台机器，构造并发起请求。

Hystrix

前面说到服务会挂。一个工程是由多个服务组合而成，那么服务调用过程中，某个服务出现故障时，会导致整个功能出现问题，那么怎么解决这个问题呢，就需要用到Hystrix组件。

服务熔断

服务调不通时，执行其他方法。

例子：

 @HystrixCommand(fallbackMethod = "getDefaultUser")
    @GetMapping("getUser")
    public String getUser(Integer id) {
        String url = "http://user-service/provider/getUser?id=" + id;
        return restTemplate.getForObject(url, String.class);
    }

    public String getDefaultUser(Integer id) {
        System.out.println("熔断，默认回调函数");
        return "{\"id\":-1,\"name\":\"熔断用户\",\"password\":\"123456\"}";
    }

服务降级

服务降级时在客户端实现完成，服务降级出现原因是：服务熔断会导致方法膨胀（与服务相关的方法都要有对应的服务熔断）。

服务降级目的：让客户端在服务端不可用时（把服务关掉，让其他服务用足够的资源）也会获得提示信息而不会挂起耗死服务器。

//表示"user-service"的服务，指定fallback
@FeignClient(value = "user-service", fallback = UserFeginFailBackImpl.class)
public interface UserFeginService {

    @RequestMapping(value = "/provider/getUser")
    public String getUser(@RequestParam("id") Integer id);
}

Fallback类会执行相应操作，让项目继续运行，不会导致系统耗死。

Zuul

前端调后端系统时，请求统一从 Zuul 网关进入，由 Zuul 网关转发请求给对应的服务（会进行配置）。现在一般都是前后端分离，一般不把真实路径暴露给前端，所以前端请求通过zuul网关转发到对应配置的具体服务就解决了这个问题。

但是如果后端服务多达十几个的时候，每一个都这样配置也挺麻烦的，spring cloud zuul已经帮我们做了默认配置。默认情况下，Zuul会代理所有注册到Eureka Server的微服务，并且Zuul的路由规则如下：http://ZUUL_HOST:ZUUL_PORT/微服务在Eureka上的serviceId/**会被转发到serviceId对应的微服务。

有一个网关之后，还有很多好处，比如可以做统一的降级、限流、认证授权、安全。

spring cloud组件协作图

今天写的全部都是理论，具体实现，下次吧。

标签：Feign,服务,请求,spring,Eureka,组件,cloud
来源： https://blog.csdn.net/qq_40726316/article/details/104710052

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。