[[419659]]

絮叨

前面一節我們學習了一下eureka,我們來回顧一下，首先它是一個cs架構，分為客戶端和服務端，

客戶端 也分為 生成者和消費者，也就是服務提供方和服務消費方，具體客戶端的作用如下

• 當客戶端啟動的時候向服務端注冊當前服務
• 并和服務端維持心跳，用的是后臺線程
• 拉取服務端的各個節點集合，然后定時更新服務的信息到本地，因為客戶端也是會緩存服務節點信息的
• 當服務掛掉的時候，監聽shutdown 然后上報自己掛掉的狀態給服務端

服務端

• 啟動后，從其他節點獲取服務注冊信息。
• 運行過程中，定時運行evict任務，剔除沒有按時renew的服務(包括非正常停止和網絡故障的服務)。
• 運行過程中，接收到的register、renew、cancel請求，都會同步至其他注冊中心節點，分布式數據同步(AP)
• 運行過程中，自我保護機制。等等
• SpringCloud原理之eureka

什么是Feign

Feign是一種聲明式、模板化的HTTP客戶端(僅在Application Client中使用)。聲明式調用是指，就像調用本地方法一樣調用遠程方法，無需感知操作遠程http請求。Spring Cloud的聲明式調用, 可以做到使用 HTTP請求遠程服務時能就像調用本地方法一樣的體驗，開發者完全感知不到這是遠程方法，更感知不到這是個HTTP請求。Feign的應用，讓Spring Cloud微服務調用像Dubbo一樣，Application Client直接通過接口方法調用Application Service，而不需要通過常規的RestTemplate構造請求再解析返回數據。它解決了讓開發者調用遠程接口就跟調用本地方法一樣，無需關注與遠程的交互細節，更無需關注分布式環境開發。

Feign是聲明性Web服務客戶端。它使編寫Web服務客戶端更加容易。要使用Feign，請創建一個接口并對其進行注釋。它具有可插入注釋支持，包括Feign注釋和JAX-RS注釋。Feign還支持可插拔編碼器和解碼器。Spring Cloud添加了對Spring MVC注釋的支持，并支持使用HttpMessageConvertersSpring Web中默認使用的注釋。當使用Feign時，Spring Cloud集成了Ribbon和Eureka以提供負載平衡的http客戶端。

使用Feign開發時的應用部署結構

Feign是如何設計的?

原生的Feign

雖然我們用SpringCloud全家桶比較多，但是其實呢?他只是對原生的fegin做了一些封裝，所以刨根問底的話，我們還是多了解了解原生的Fegin,對于我們理解Spring Cloud feign是很有幫助的

Feign使用簡介

基本用法

基本的使用如下所示，一個對于canonical Retrofit sample的適配。

interface GitHub { 
 // RequestLine注解聲明請求方法和請求地址,可以允許有查詢參數 
 @RequestLine("GET /repos/{owner}/{repo}/contributors") 
 List<Contributor> contributors(@Param("owner") String owner, @Param("repo") String repo); 
} 
static class Contributor { 
 String login; 
 int contributions; 
} 
public static void main(String... args) { 
 GitHub github = Feign.builder() 
            .decoder(new GsonDecoder()) 
            .target(GitHub.class, "https://api.github.com"); 
 // Fetch and print a list of the contributors to this library. 
 List<Contributor> contributors = github.contributors("OpenFeign", "feign"); 
 for (Contributor contributor : contributors) { 
  System.out.println(contributor.login + " (" + contributor.contributions + ")"); 
 } 
} 

自定義

Feign 有許多可以自定義的方面。舉個簡單的例子，你可以使用 Feign.builder() 來構造一個擁有你自己組件的API接口。如下:

interface Bank { 
 @RequestLine("POST /account/{id}") 
 Account getAccountInfo(@Param("id") String id); 
} 
... 
// AccountDecoder() 是自己實現的一個Decoder 
Bank bank = Feign.builder().decoder(new AccountDecoder()).target(Bank.class, https://api.examplebank.com); 

Feign 動態代理

Feign 的默認實現是 ReflectiveFeign，通過 Feign.Builder 構建。再看代碼前，先了解一下 Target 這個對象。

public interface Target<T> { 
  // 接口的類型 
  Class<T> type(); 
 
  // 代理對象的名稱，默認為url,負載均衡時有用 
  String name(); 
  // 請求的url地址，eg: https://api/v2 
  String url(); 
} 

其中 Target.type 是用來生成代理對象的，url 是 Client 對象發送請求的地址。

public Feign build() { 
    // client 有三種實現 JdkHttp/ApacheHttp/okHttp，默認是 jdk 的實現 
    SynchronousMethodHandler.Factory synchronousMethodHandlerFactory = 
        new SynchronousMethodHandler.Factory(client, retryer, requestInterceptors, logger, 
                                             logLevel, decode404, closeAfterDecode, propagationPolicy); 
    ParseHandlersByName handlersByName = 
        new ParseHandlersByName(contract, options, encoder, decoder, queryMapEncoder, 
                                errorDecoder, synchronousMethodHandlerFactory); 
    return new ReflectiveFeign(handlersByName, invocationHandlerFactory, queryMapEncoder); 
} 

總結：介紹一下幾個主要的參數：

• Client 這個沒什么可說的，有三種實現 JdkHttp/ApacheHttp/okHttp
• RequestInterceptor 請求攔截器
• Contract REST 注解解析器，默認為 Contract.Default()，即支持 Feign 的原生注解。
• InvocationHandlerFactory 生成 JDK 動態代理，實際執行是委托給了 MethodHandler。

生成代理對象

public <T> T newInstance(Target<T> target) { 
    // 1. Contract 將 target.type 接口類上的方法和注解解析成 MethodMetadata， 
    //    并轉換成內部的MethodHandler處理方式 
    Map<String, MethodHandler> nameToHandler = targetToHandlersByName.apply(target); 
    Map<Method, MethodHandler> methodToHandler = new LinkedHashMap<Method, MethodHandler>(); 
    List<DefaultMethodHandler> defaultMethodHandlers = new LinkedList<DefaultMethodHandler>(); 
 
    for (Method method : target.type().getMethods()) { 
        if (method.getDeclaringClass() == Object.class) { 
            continue; 
        } else if (Util.isDefault(method)) { 
            DefaultMethodHandler handler = new DefaultMethodHandler(method); 
            defaultMethodHandlers.add(handler); 
            methodToHandler.put(method, handler); 
        } else { 
            methodToHandler.put(method, nameToHandler.get(Feign.configKey(target.type(), method))); 
        } 
    } 
 
    // 2. 生成 target.type 的 jdk 動態代理對象 
    InvocationHandler handler = factory.create(target, methodToHandler); 
    T proxy = (T) Proxy.newProxyInstance(target.type().getClassLoader(), 
                                         new Class<?>[]{target.type()}, handler); 
 
    for (DefaultMethodHandler defaultMethodHandler : defaultMethodHandlers) { 
        defaultMethodHandler.bindTo(proxy); 
    } 
    return proxy; 
} 

總結：newInstance 生成了 JDK 的動態代理，從 factory.create(target, methodToHandler) 也可以看出 InvocationHandler 實際委托給了 methodToHandler。methodToHandler 默認是 SynchronousMethodHandler.Factory 工廠類創建的。

MethodHandler 方法執行器

ParseHandlersByName.apply 生成了每個方法的執行器 MethodHandler，其中最重要的一步就是通過 Contract 解析 MethodMetadata。

public Map<String, MethodHandler> apply(Target key) { 
    // 1. contract 將接口類中的方法和注解解析 MethodMetadata 
    List<MethodMetadata> metadata = contract.parseAndValidatateMetadata(key.type()); 
    Map<String, MethodHandler> result = new LinkedHashMap<String, MethodHandler>(); 
    for (MethodMetadata md : metadata) { 
        // 2. buildTemplate 實際上將 Method 方法的參數轉換成 Request 
        BuildTemplateByResolvingArgs buildTemplate; 
        if (!md.formParams().isEmpty() && md.template().bodyTemplate() == null) { 
            // 2.1 表單 
            buildTemplate = new BuildFormEncodedTemplateFromArgs(md, encoder, queryMapEncoder); 
        } else if (md.bodyIndex() != null) { 
            // 2.2 @Body 注解 
            buildTemplate = new BuildEncodedTemplateFromArgs(md, encoder, queryMapEncoder); 
        } else { 
            // 2.3 其余 
            buildTemplate = new BuildTemplateByResolvingArgs(md, queryMapEncoder); 
        } 
        // 3. 將 metadata 和 buildTemplate 封裝成 MethodHandler 
        result.put(md.configKey(), 
                   factory.create(key, md, buildTemplate, options, decoder, errorDecoder)); 
    } 
    return result; 
} 

總結：這個方法由以下幾步：

Contract 統一將方法解析 MethodMetadata(*)，這樣就可以通過實現不同的 Contract 適配各種 REST 聲明式規范。buildTemplate 實際上將 Method 方法的參數轉換成 Request。將 metadata 和 buildTemplate 封裝成 MethodHandler。

這樣通過以上三步就創建了一個 Target.type 的代理對象 proxy，這個代理對象就可以像訪問普通方法一樣發送 Http 請求，其實和 RPC 的 Stub 模型是一樣的。了解 proxy 后，其執行過程其實也就一模了然。

Feign 調用過程

FeignInvocationHandler#invoke

private final Map<Method, MethodHandler> dispatch; 
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { 
    ... 
    // 每個Method方法對應一個MethodHandler 
    return dispatch.get(method).invoke(args); 
} 

總結：和上面的結論一樣，實際的執行邏輯實際上是委托給了 MethodHandler。

SynchronousMethodHandler#invoke

// 發起 http 請求，并根據 retryer 進行重試 
public Object invoke(Object[] argv) throws Throwable { 
    // template 將 argv 參數構建成 Request 
    RequestTemplate template = buildTemplateFromArgs.create(argv); 
    Options options = findOptions(argv); 
    Retryer retryer = this.retryer.clone(); 
 
    // 調用client.execute(request, options) 
    while (true) { 
        try { 
            return executeAndDecode(template, options); 
        } catch (RetryableException e) { 
            try { 
                // 重試機制 
                retryer.continueOrPropagate(e); 
            } catch (RetryableException th) { 
                ... 
            } 
            continue; 
        } 
    } 
} 

總結：invoke 主要進行請求失敗的重試機制，至于具體執行過程委托給了 executeAndDecode 方法。

// 一是編碼生成Request；二是http請求；三是解碼生成Response 
Object executeAndDecode(RequestTemplate template, Options options) throws Throwable { 
    // 1. 調用攔截器 RequestInterceptor，并根據 template 生成 Request 
    Request request = targetRequest(template); 
    // 2. http 請求 
    Response response = client.execute(request, options); 
 // 3. response 解碼 
    if (Response.class == metadata.returnType()) { 
        byte[] bodyData = Util.toByteArray(response.body().asInputStream()); 
        return response.toBuilder().body(bodyData).build(); 
    } 
    ... 
} 
 
Request targetRequest(RequestTemplate template) { 
    // 執行攔截器 
    for (RequestInterceptor interceptor : requestInterceptors) { 
        interceptor.apply(template); 
    } 
    // 生成 Request 
    return target.apply(template); 

這個是原生feign的調用過程，總的來說分為2部 一個是 客戶端的封裝，一個調用方法的封裝

Spring Cloud Feign 的原理解析

我們前面看了原生的feign之后呢?對于Spring Cloud的Feign的話理解起來就很簡單了，我們知道Spring cloud 是基于SpringBoot SpringBoot 又是基于Spring,那么Spring就是一個膠水框架，它就是把各個組件把它封裝起來，所以呢，這樣就簡單很多了嘛

小六六在這邊就不一一的給大家演示SpringCloud 是如何使用Feign的了，小六六默認大家都懂，哈哈，那么就直接說原理吧

工作原理

我們來想想平時我們使用feign的時候，會是一個怎么樣的流程

• 添加了 Spring Cloud OpenFeign 的依賴
• 在 SpringBoot 啟動類上添加了注解 @EnableFeignCleints
• 按照 Feign 的規則定義接口 DemoService， 添加@FeignClient 注解
• 在需要使用 Feign 接口 DemoService 的地方， 直接利用@Autowire 進行注入
• 使用接口完成對服務端的調用

那我們基于這些步驟來分析分析，本文并不會說非常深入去看每一行的源碼

• SpringBoot 應用啟動時， 由針對 @EnableFeignClient 這一注解的處理邏輯觸發程序掃描 classPath中所有被@FeignClient 注解的類， 這里以 XiaoLiuLiuService 為例， 將這些類解析為 BeanDefinition 注冊到 Spring 容器中
• Sping 容器在為某些用的 Feign 接口的 Bean 注入 XiaoLiuLiuService 時， Spring 會嘗試從容器中查找 XiaoLiuLiuService 的實現類
• 由于我們從來沒有編寫過 XiaoLiuLiuService 的實現類， 上面步驟獲取到的 XiaoLiuLiuService 的實現類必然是 feign 框架通過擴展 spring 的 Bean 處理邏輯， 為 XiaoLiuLiuService 創建一個動態接口代理對象， 這里我們將其稱為 XiaoLiuLiuServiceProxy 注冊到spring 容器中。
• Spring 最終在使用到 XiaoLiuLiuService 的 Bean 中注入了 XiaoLiuLiuServiceProxy 這一實例。
• 當業務請求真實發生時， 對于 XiaoLiuLiuService 的調用被統一轉發到了由 Feign 框架實現的 InvocationHandler 中， InvocationHandler 負責將接口中的入參轉換為 HTTP 的形式， 發到服務端， 最后再解析 HTTP 響應， 將結果轉換為 Java 對象， 予以返回。

所以我們基于原生的feign來分析分析，其實就是多了2步，前面的原生feign會幫助我們生成代理對象，這個是我們調用方法的主體，也是這個代理對象才有能力去請求http請求，那么spring就想辦法，把這一類的對象放到spring的上下文中，那么我們下次調用的時候，這個對象當然就有了http請求的能力了。

結束

我是小六六，三天打魚，兩天曬網，今天我的分享就到了。