Http和Rpc重试机制

重试机制定义:

重试机制是在设置的超时时间到了之后没有返回结果或者服务端出现异常后服务调用端进行再次调用。

首先,不是所有接口都适合重试,如果一个服务是不等幂,那么不适合重试的机制,因为会存在重复提交的问题,否则是可以进行重试的。比如提交一个订单的接口是不能进行重试的,而把订单信息推给wms系统接口是可以重试的。

一般两个部署在不同网段的系统不能通过dubbo的rpc调用,只能用最原始的http调用,比如在占用库存的时候调用库存中心或者将配送信息推送给wms时,由于网络的波动或者商品数量多导致处理时间长等原因,需要对调用接口进行重试,具体代码如下:

private final int MAX_RETRY = 4;
int retries = 1;
JSONObject jsonObject = null;
do {
    long startTime = System.currentTimeMillis();
    jsonObject = HttpServer.httpPostFormEntity(url, params, httpClient);
    long endTime = System.currentTimeMillis();
    float seconds = (endTime - startTime) / 1000F;
    logger.info(order_id + "=== 执行时间:" + seconds + "s");
    logger.info(order_id + "=== 推送订单到wms出参:{}", new Object[]{jsonObject});
    if (jsonObject.get("returnCode").equals("0")) {
        long waitTime = DateHelper.getWaitTime(retries);
        try {
            Thread.sleep(waitTime);
        } catch (InterruptedException e) {
            logger.error("Error", e);
        }
    } else {
        return jsonObject;
    }
} while (retries++ < MAX_RETRY);
return jsonObject;
//waitTime按幂重试
public static long getWaitTime(int retryTime) {
    long waitTime = (long)Math.pow(2.0D, (double)retryTime) * 1000L;
    return waitTime;
}

以上是http调用的重试机制,比较简单。

DUBBO通过rpc调用时消费端设置额超时时间不能随心所欲,需要根据业务实际情况来设定,太短导致在设定的超时时间内无法完成正常的业务处理。太长的话会造成进程假死。就是所有的进程都在等待状态。

当消费端达到超时时间,dubbo会进行重试机制(如果配置了dubbo.reference.retries>1),重试机制大于1次会给服务提供端带来压力,而压力是正常值*dubbo.reference.retries倍,最终dubbo的消费端会出现RpcException提示retry了多少次还是失败。这种情况就是没有合理设置接口超时时间带来的问题。 

<think>我们正在讨论RPCHTTP的区别及使用场景。根据引用内容,我们可以总结如下: 1. RPC(远程过程调用)是一种协议,允许程序调用另一个地址空间(通常是另一台机器)的过程或函数,就像调用本地方法一样。它抽象了网络通信的细节。 2. HTTP是一种应用层协议,用于在客户端服务器之间传输超文本(如网页),基于请求-响应模型。 区别: - 设计目标:HTTP是为通用资源传输设计的(如网页),而RPC是为跨网络的程序间通信设计的。 - 协议层级:HTTP是应用层协议,而RPC可以基于多种传输协议(如TCP、HTTP)实现。 - 通信模型:HTTP使用请求-响应模型,无状态;RPC通常模拟本地方法调用,可以有状态(取决于实现)。 - 性能:RPC通常比HTTP更快,因为RPC可以使用更高效的序列化(如Protocol Buffers)更少的协议开销(HTTP头信息较臃肿)。 - 灵活性:HTTP更通用,支持跨平台、跨语言,且易于通过防火墙;RPC通常需要特定的客户端框架,但现代RPC框架(如gRPC)也支持多语言。 使用场景: - RPC:适合内部服务之间的通信,如微服务架构中的服务调用。因为它性能高,服务治理方便(如负载均衡、熔断等)。 - HTTP:适合对外提供服务,如Web API、移动应用API、第三方接口等,因为其通用性跨平台支持。 根据引用[1]:RPC主要用于公司内部服务调用,性能消耗低,传输效率高,服务治理方便。HTTP主要用于对外的异构环境,浏览器调用,APP接口调用,第三方接口调用等等。 引用[3]也指出:RPC常用于微服务架构中各个服务之间的通信,分布式系统中的服务调用。 因此,我们可以这样组织回答: 1. 定义RPCHTTP 2. 主要区别(协议层级、设计目标、性能、灵活性等) 3. 使用场景(分别适用于什么情况) 4. 如何选择(根据需求) 同时,我们将使用引用来支持我们的观点。</think>### RPCHTTP 的区别及使用场景分析 #### 一、核心区别 | **特性** | **RPC** | **HTTP** | |-------------------|----------------------------------------------|-----------------------------------------------| | **设计目标** | 实现跨网络的**程序间方法调用** | 实现**资源传输**(如网页、API数据) | | **协议层级** | 应用层协议(可基于 TCP/HTTP/自定义协议) | 应用层协议(强制基于 TCP) | | **通信模型** | 模拟本地方法调用(如 `userService.get(id)`) | 请求-响应模型(GET/POST/PUT/DELETE) | | **数据封装** | 高效二进制序列化(Protobuf/Thrift 等) | 文本协议(JSON/XML),头部信息臃肿 | | **性能** | ⭐⭐⭐⭐⭐ 延迟低,吞吐量高 | ⭐⭐⭐ 需要解析头信息,性能较低 | | **灵活性** | ⭐⭐ 需预定义接口,语言绑定强 | ⭐⭐⭐⭐⭐ 跨语言、跨平台,通用性强 | | **服务治理** | 内置负载均衡、熔断、重试机制 | 需额外中间件(如 API 网关)实现治理 | | **典型框架** | gRPC, Dubbo, Thrift | RESTful API, Spring MVC | --- #### 二、使用场景对比 ##### 1. **RPC 的适用场景** - **微服务内部通信** 同一技术栈的服务集群(如 Java 微服务),需高性能调用(延迟 <10ms)[^1] ```mermaid graph LR A[订单服务] -->|RPC| B[支付服务] B -->|RPC| C[库存服务] ``` - **分布式系统调用** 高频调用的核心链路(如交易系统扣减库存)[^3] - **实时数据处理** 流式计算节点间通信(如 Flink JobManager 与 TaskManager) ##### 2. **HTTP 的适用场景** - **对外暴露 API** 面向浏览器/APP/第三方(如开放平台支付接口)[^1] ```mermaid graph LR D[Web浏览器] -->|HTTP| E[API网关] F[手机APP] -->|HTTP| E G[第三方系统] -->|HTTP| E ``` - **异构系统集成** 跨语言、跨组织系统对接(如 Python 调用 Java 服务)[^2] - **资源型操作** RESTful 风格的 CRUD 操作(如管理后台用户增删改查) --- #### 三、关键技术差异 ##### 1. **连接管理** | **机制** | RPC | HTTP | |----------------|------------------------------------|-----------------------------------| | **连接复用** | 长连接复用(减少 TCP 握手开销) | HTTP/1.1 支持 Keep-Alive 但不稳定 | | **多路复用** | gRPC 基于 HTTP/2 支持多路复用 | HTTP/2 支持,HTTP/1.1 不支持 | ##### 2. **数据传输效率对比(示例)** 调用 `getUser(id=123)` 的传输数据量: ```plaintext # RPC (Protobuf 编码) 0A 03 31 32 33 # 总长度: 10字节 # HTTP (RESTful + JSON) POST /user/get Content-Type: application/json {"id": "123"} # 总长度: ~80字节 ``` > 💡 RPC 二进制编码比 HTTP+JSON 节省 **5-10 倍** 带宽[^1] ##### 3. **服务治理能力** | **能力** | RPC 框架内置支持 | HTTP 需额外组件 | |----------------|----------------------------------|------------------------------| | 负载均衡 | ✅ (如 Dubbo 的 Cluster) | 🔶 需 Nginx/API 网关 | | 熔断降级 | ✅ (如 Hystrix 集成) | 🔶 需 Sentinel/Resilience4j | | 链路追踪 | ✅ (透传 TraceID) | 🔶 需手动注入 Header | --- #### 四、如何选择? 1. **选 RPC 当**: - 系统内部服务调用(尤其是高频核心链路) - 要求毫秒级延迟(如金融交易系统) - 服务端客户端技术栈统一 2. **选 HTTP 当**: - 面向公网暴露 API(需跨平台兼容性) - 对接异构系统(不同编程语言) - 需要遵循 REST 资源模型(如 CRUD 操作) > ⚠️ **混合架构建议**: > 微服务架构中常组合使用——**内部服务用 RPC(如 gRPC),对外暴露用 HTTP(RESTful API)**[^1][^3] --- ### 相关问题 1. **gRPC Dubbo 在 RPC 实现上有哪些本质差异?** 2. **HTTP/3 的 QUIC 协议对 RPC 性能会有哪些影响?** 3. **在 Kubernetes 环境中如何优化 RPC 服务的服务发现机制?** 4. **RPC 框架如何实现跨语言调用?以 gRPC 为例说明其多语言支持原理** 5. **HTTP RPC 在安全机制(如 mTLS)实现上有何不同?** [^1]: HTTPRPC的区别 [^2]: Http Rpc 的区别 [^3]: tcp、httprpc的区别 [^4]: RPC与MQ的区别
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值