目录
微服务之间的相互调用的几种实现方式
一、HTTP
HTTP/RESTful API调用工作原理
二、RPC
设计理念与实现方式
协议与传输层
RPC远程调用工作原理
应用场景与性能考量
特点
三、Feign
设计理念与实现方式
协议与传输层
Feign调用的基本流程
Feign调用的工作原理
特点
应用场景与性能考量
四、几种调用方式的区别与联系
Feign与HTTP的关系和区别
RPC与HTTP的关系和区别
RPC和openfeign的关系和区别
在微服务架构中,远程调用、HTTP/RESTful API和Feign是实现微服务之间通信的不同方式。在构建分布式系统和微服务架构时,选择合适的服务间通信技术至关重要。
微服务之间的相互调用的几种实现方式
在Java多模块项目中实现微服务架构时,微服务之间的相互调用通常可以通过以下几种方式实现:
根据具体的业务需求、性能要求、开发团队技术栈等因素,可以选择合适的调用方式来进行微服务间的通信。通常情况下,会根据项目的具体情况,结合多种调用方式来实现不同的功能和需求。
一、HTTP
详情请移步我的另一篇博客HTTP协议简单介绍-CSDN博客
HTTP/RESTful API调用工作原理
HTTP/RESTful API调用是通过HTTP协议进行通信的一种方式,它的工作原理是客户端发送HTTP请求到服务器,服务器接收到请求后处理并返回HTTP响应。下面是HTTP/RESTful API调用的工作原理和代码示例。
工作原理:
- 客户端发送请求:客户端(例如浏览器、移动应用、或其他服务器)创建一个HTTP请求,并指定请求方法(例如GET、POST、PUT、DELETE等)、URL地址、请求头、请求体等信息。
- 服务器接收请求:服务器接收到客户端发送的HTTP请求,并根据请求中的信息确定要执行的操作。
- 服务器处理请求:服务器根据请求中的信息执行相应的操作,可能包括查询数据库、处理业务逻辑、生成动态内容等。
- 服务器返回响应:服务器处理完请求后,会生成一个HTTP响应,包括状态码、响应头、响应体等信息。然后将该响应发送回客户端。
- 客户端接收响应:客户端接收到服务器发送的HTTP响应后,根据响应中的信息进行相应的处理,可能是渲染页面、解析响应体中的数据等。
代码示例:下面是一个简单的使用Java进行HTTP GET请求的示例代码,使用的是java.net.HttpURLConnection。这段代码发送一个HTTP GET请求到https://jsonplaceholder.typicode.com/posts/1
,并输出响应码和响应体。
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.net.HttpURLConnection;
import java.net.URL;
public class HttpGetExample {
public static void main(String[] args) {
try {
// 创建URL对象,指定要请求的URL地址
URL url = new URL("https://jsonplaceholder.typicode.com/posts/1");
// 打开连接
HttpURLConnection connection = (HttpURLConnection) url.openConnection();
// 设置请求方法为GET
connection.setRequestMethod("GET");
// 获取响应码
int responseCode = connection.getResponseCode();
System.out.println("Response Code: " + responseCode);
// 读取响应内容
BufferedReader reader = new BufferedReader(new InputStreamReader(connection.getInputStream()));
StringBuilder response = new StringBuilder();
String line;
while ((line = reader.readLine()) != null) {
response.append(line);
}
reader.close();
// 打印响应内容
System.out.println("Response Body:");
System.out.println(response.toString());
// 关闭连接
connection.disconnect();
} catch (Exception e) {
e.printStackTrace();
}
}
}
二、RPC
RPC,即 Remote Procedure Call(远程过程调用)是一个计算机通信协议,是指一个服务通过网络向另一个服务发送请求,以获得数据或执行操作。
RPC是一种跨网络进程间通信技术,其目标是使远程服务调用如同本地调用一样透明。 该协议允许运行于一台计算机的程序调用另一台计算机的子程序,而程序员无需额外地为这个交互作用编程。说得通俗一点就是:A计算机提供一个服务,B计算机可以像调用本地服务那样调用A计算机的服务。
远程调用的实现方式有多种,包括但不限于HTTP REST API、gRPC、SOAP等。
- 传统的RPC实现基于自定义协议和传输层(如TCP)
- 而现代RPC框架如gRPC则采用HTTP/2作为传输层,支持更高效的数据交换。
RPC框架通常内置服务发现、负载均衡、序列化/反序列化等高级功能,适用于高性能、低延迟的内部服务通信。
设计理念与实现方式
设计哲学:追求透明的远程调用体验,尽可能隐藏网络通信细节。
实现机制:更灵活的协议选择,支持自定义或标准协议(如gRPC使用HTTP/2)。通常包括序列化/反序列化层,以高效传输数据。
协议与传输层
多样化,既有基于TCP/UDP的自定义协议,也有采用HTTP/2等现代网络协议的实现,如gRPC,以实现更高效的二进制数据传输。
RPC远程调用工作原理
远程过程调用(RPC)是一种通过网络在不同计算机之间进行通信的方式,使得一个计算机程序可以调用另一个计算机上的函数或方法,就像调用本地函数一样。下面是RPC的工作原理和一个简单的Java代码示例。
工作原理:
- 定义接口:首先,在服务端和客户端都需要定义相同的接口,接口中包含了需要远程调用的方法。
- 序列化参数:当客户端调用远程方法时,客户端将方法名和参数序列化成字节流,然后通过网络发送到服务端。
- 网络传输:服务端接收到客户端发送的请求后,将请求反序列化成方法名和参数,然后在服务端执行对应的方法。
- 执行方法:在服务端执行方法后,将方法的返回值序列化成字节流,然后通过网络发送给客户端。
- 反序列化返回值:客户端接收到服务端发送的返回值后,将返回值反序列化成方法的返回值,然后将其返回给调用方。
代码示例:以下是一个简单的RPC示例,包括服务端和客户端的代码:
(1)服务端代码,
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.net.ServerSocket;
import java.net.Socket;
public class RpcServer {
public static void main(String[] args) {
try {
// 创建ServerSocket,并指定端口号
ServerSocket serverSocket = new ServerSocket(8888);
System.out.println("Server started...");
while (true) {
// 监听客户端连接
Socket socket = serverSocket.accept();
System.out.println("Client connected: " + socket.getInetAddress());
// 创建ObjectInputStream和ObjectOutputStream
ObjectInputStream inputStream = new ObjectInputStream(socket.getInputStream());
ObjectOutputStream outputStream = new ObjectOutputStream(socket.getOutputStream());
// 读取客户端发送的方法名和参数
String methodName = inputStream.readUTF();
int a = inputStream.readInt();
int b = inputStream.readInt();
// 调用方法
int result = 0;
if ("add".equals(methodName)) result = add(a, b);
// 将方法的返回值写回客户端
outputStream.writeInt(result);
outputStream.flush();
// 关闭流和Socket
inputStream.close();
outputStream.close();
socket.close();
}
} catch (IOException e) {e.printStackTrace();}
}
public static int add(int a, int b) {return a + b;}
}
(2)客户端代码,
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.net.Socket;
public class RpcClient {
public static void main(String[] args) {
try {
// 连接服务端的Socket,并指定IP地址和端口号
Socket socket = new Socket("localhost", 8888);
// 创建ObjectInputStream和ObjectOutputStream
ObjectOutputStream outputStream = new ObjectOutputStream(socket.getOutputStream());
ObjectInputStream inputStream = new ObjectInputStream(socket.getInputStream());
// 发送方法名和参数到服务端
outputStream.writeUTF("add");
outputStream.writeInt(10);
outputStream.writeInt(20);
outputStream.flush();
// 读取服务端发送的返回值
int result = inputStream.readInt();
System.out.println("Result: " + result);
// 关闭流和Socket
outputStream.close();
inputStream.close();
socket.close();
} catch (IOException e) {e.printStackTrace();}
}
}
应用场景与性能考量
在需要高性能、低延迟通信的场景中更为常见,如内部服务间的密集通信,特别是在游戏、金融等领域。现代RPC框架如gRPC,凭借其高性能和跨语言特性,也逐渐应用于更广泛的分布式系统中。
特点
- 直接调用:服务通过网络协议(如HTTP、gRPC等)直接调用其他服务的API。
- 灵活性:可以使用不同的协议和库来实现,比如使用
RestTemplate
、HttpClient
等。 - 手动管理:开发者需要手动处理请求的构建、响应的解析以及异常处理等。
三、Feign
Feign是一个轻量级的Java库,专为简化HTTP API客户端调用而生。通过动态代理和接口注解,Feign使得调用远程服务如同调用本地方法一样直观便捷。它常用于Spring Cloud等微服务框架中,与服务发现、负载均衡等服务治理组件紧密集成,提供了一种声明式的HTTP客户端解决方案,用于简化微服务之间的HTTP调用。
OpenFeign是Spring Cloud提供的一个声明式的伪Htp客户端,它使得调用远程服务就像调用本地服务一样简单,只需要创建一个接口并添加一个注解即可。通过使用注解,开发者可以轻松地定义调用其他服务的接口,而不需要编写大量的底层代码。
设计理念与实现方式
设计哲学:面向接口编程,通过接口定义和服务注解,抽象出简洁的调用逻辑。
实现机制:利用JVM的动态代理机制生成客户端代理类,自动处理请求构造、发送和响应解析。
协议与传输层
基于HTTP协议,利用HTTP的标准化和易穿透网络特性,支持RESTful风格的API交互。
Feign调用的基本流程
如果不了解 SpringCloud 中 Feign 核心原理,不会真正的了解 SpringCloud 的性能优化和配置优化,也就不可能做到真正掌握 SpringCloud。
Feign远程调用,核心就是通过一系列的封装和处理,将以JAVA注解的方式定义的远程调用API接口,最终转换成HTTP的请求形式,然后将HTTP的请求的响应结果,解码成JAVA Bean,放回给调用者。
Feign远程调用的基本流程,大致如下图所示。
从上图可以看到,Feign通过处理注解,将请求模板化,当实际调用的时候,传入参数,根据参数再应用到请求上,进而转化成真正的 Request 请求。通过Feign以及JAVA的动态代理机制,使得Java 开发人员,可以不用通过HTTP框架去封装HTTP请求报文的方式,完成远程服务的HTTP调用。
Feign调用的工作原理
Feign调用的工作原理是通过动态代理技术将接口方法的调用转换为HTTP请求,并发送到远程服务。下面是Feign调用的一般工作流程:
- 定义Feign客户端接口:在客户端项目中定义一个Java接口,该接口用于描述要调用的远程服务的API。接口的方法对应了远程服务的不同接口或资源路径。
- 创建Feign客户端:使用@FeignClient注解标注接口,指定要调用的远程服务的名称或URL。Feign根据该注解创建一个动态代理对象,该代理对象实现了接口定义的方法。
- 调用远程服务方法:在客户端代码中直接调用Feign客户端接口的方法,就像调用本地方法一样。Feign客户端会拦截这些方法调用,并将它们转换为HTTP请求。
- HTTP请求转换:当调用Feign客户端接口的方法时,Feign会根据方法的注解(如@GetMapping、@PostMapping等)以及方法的参数,构建对应的HTTP请求。
- 例如,根据@GetMapping注解指定的路径和方法参数,生成一个GET请求。
- 发送HTTP请求:Feign客户端将生成的HTTP请求发送到远程服务的URL。这个URL通常是通过服务注册与发现机制获取的,或者是在@FeignClient注解中指定的硬编码URL。
- 接收响应:远程服务接收到HTTP请求后,处理请求并返回响应。Feign客户端接收到响应后,将其转换为Java对象(如果有需要)并返回给调用方。
总体来说,Feign通过动态代理技术将接口方法调用转换为HTTP请求,并将这些请求发送到远程服务。这种方式使得调用远程服务变得简单、直观,并且隐藏了底层HTTP通信的细节,提高了开发效率。
Feign是一个声明式的HTTP客户端,它简化了使用HTTP API的调用。Feign的工作原理是通过动态代理技术,将接口方法的调用转换为HTTP请求,并发送到远程服务。以下是使用Feign调用远程服务的具体Java代码示例:
假设有一个名为UserService的微服务,其中包含了一些用户相关的接口,我们希望在另一个微服务中调用这些接口。
(1)首先,我们需要在调用方的项目中添加Feign的依赖,
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>
(2)创建一个Feign客户端接口,定义要调用的远程服务的API。假设UserService提供了一个获取用户信息的API,我们可以定义一个Feign接口如下:
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
@FeignClient(name = "user-service") // 指定要调用的微服务名称
public interface UserFeignClient {
@GetMapping("/user/info") // 指定远程服务的URL路径
String getUserInfo(@RequestParam("userId") Long userId); // 定义要调用的远程方法
}
(3)在调用方的代码中注入Feign客户端接口,并使用该接口来调用远程服务的方法:
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
@Service
public class UserService {
@Autowired
private UserFeignClient userFeignClient; // 注入Feign客户端接口
public String getUserInfo(Long userId) {
return userFeignClient.getUserInfo(userId); // 调用远程服务的方法
}
}
在这个示例中,UserFeignClient接口定义了一个名为getUserInfo的方法,该方法对应了远程服务的/user/info接口。然后在UserService中注入了UserFeignClient接口的实例,并在getUserInfo方法中调用了远程服务的方法。Feign会根据接口定义动态生成一个代理对象,负责将方法调用转换为HTTP请求并发送到远程服务。
需要注意的是,为了使Feign能够正常工作,我们需要确保调用方项目中已经配置了Spring Cloud的相关组件,例如服务注册与发现(Eureka、Consul等)和负载均衡(Ribbon等)等功能。
特点
- 声明式:使用注解定义RESTful API调用,减少了样板代码。
- 自动处理:OpenFeign自动处理请求的构建、响应的解析和错误处理等,简化了开发过程。
- 与Spring Cloud集成:OpenFeign通常与Spring Cloud结合使用,支持负载均衡、熔断、服务发现等特性。
应用场景与性能考量
非常适合RESTful风格的微服务架构,特别是集成在Spring Cloud生态中,提供服务治理能力的同时,保持了与Web服务的良好兼容性。
四、几种调用方式的区别与联系
以下是Feign、HTTP/RESTful API调用、RPC调用它们三个之间的区别与联系。
区别:
- Feign:
- Feign是一个声明式的HTTP客户端,用于简化基于HTTP的RESTful服务调用。它通过接口的方式描述远程服务的API,使得调用远程服务更加简单直观,无需编写底层的HTTP通信代码。
- Feign通常与Spring Cloud等微服务框架集成,可以与服务注册中心配合使用,实现服务发现、负载均衡等功能。
- HTTP/RESTful API调用:
- HTTP/RESTful API调用是一种基于HTTP协议的通信方式,每个微服务提供RESTful API,其他微服务通过发送HTTP请求来调用服务。这是一种最基本的微服务间通信方式,使用HTTP协议进行数据传输。
- RPC调用:
- RPC(远程过程调用)是一种实现微服务之间直接方法调用的方式,无需处理HTTP协议的细节。通过RPC框架,可以使得一个计算机程序可以调用另一个计算机上的函数或方法,就像调用本地函数一样。
Feign与HTTP的关系和区别
Feign与HTTP之间的关系在于,Feign是一个用于Java语言的声明式HTTP客户端库,它简化了HTTP请求的编写过程,特别适用于构建微服务架构中的服务间调用。简单来说,Feign允许开发者通过定义接口的方式来实现HTTP请求的发送,而不需要手动创建请求体、设置URL、处理响应等繁琐工作。
在技术层面,Feign背后实际上是对HTTP协议的封装和抽象。当使用Feign定义一个接口并添加相应的HTTP注解(如@GetMapping, @PostMapping等)时,Feign会根据这些注解和接口方法的定义,动态生成实现类。这个实现类会在运行时执行HTTP请求,与远程服务进行通信。Feign内部可以配置不同的HTTP客户端实现来进行实际的网络IO操作,比如默认使用Java的HttpURLConnection,也可以配置为使用Apache HttpClient或者OkHttp等其他库来执行这些请求。
因此,可以说Feign与HTTP是工具与协议的关系,Feign作为一种工具或框架,基于HTTP协议实现了更高层次的抽象,提供了更为便捷的服务调用方式。
总结就是,Feign和HTTP/RESTful API调用都是基于HTTP协议进行通信的,它们之间的联系是Feign实质上是在HTTP/RESTful API调用的基础上进行了封装和简化。Feign是一种更加高级、简化的HTTP/RESTful API调用方式,隐藏了底层的HTTP通信细节,提供了声明式的接口来描述远程服务的API,让开发人员可以像调用本地方法一样来调用远程服务。
RPC与HTTP的关系和区别
相同点是底层通讯都是基于socket,都可以实现远程调用,都可以实现服务调用服务。
不同点:
RPC调用虽然不直接依赖于HTTP协议,但它也可以在HTTP协议的基础上实现。一些RPC框架(例如gRPC)可以使用HTTP/2作为底层传输协议,从而具备更高的性能和效率。
RPC调用是一种更加底层、直接的远程方法调用方式,无需处理HTTP协议的细节,通常具有更高的性能和效率,但需要引入RPC框架,并在系统中进行服务治理和管理。
既然两种方式都可以实现远程调用,我们该如何选择呢?
- 速度来看,RPC要比http更快,虽然底层都是TCP,但是http协议的信息往往比较臃肿。
- 难度来看,RPC实现较为复杂,http相对比较简单。
- 灵活性来看,http更胜一筹,因为它不关心实现细节,跨平台、跨语言。
RPC和openfeign的关系和区别
联系:
- 目的相同:两者都是为了实现微服务之间的通信。
- 可以结合使用:OpenFeign可以看作是远程调用的一种实现方式,使用OpenFeign可以简化远程调用的实现过程,使开发者更加专注于业务逻辑。
区别:
在微服务架构中,远程调用是一个广义的概念,而OpenFeign是实现远程调用的一种特定方式。OpenFeign通过声明式的方式简化了远程调用的复杂性,适合用于需要频繁进行微服务调用的场景。开发者可以根据项目需求选择适合的方式进行服务间通信。
Feign和RPC各有千秋,选择应基于项目的具体需求、性能指标、团队熟悉度以及生态系统的集成能力。在微服务架构中,两者并非互斥,甚至可根据不同服务的特点,在同一系统中灵活搭配使用。理解它们的核心差异,有助于做出更贴合实际的技术决策。