~4= -5 怎么来的

step1:4的补码(正数的原码、补码、反码都相同https://baike.baidu.com/item/%E5%8F%8D%E7%A0%81/769985?fr=aladdin)为0100,第一位为符号位,0为正,1为负。

step2 :~为按位取反,包含第一位的符号码,此时补码变为1011,要求该补码对应的十进制数值

step3 :补码=反码+1,反码为1010

原码=反码按位取反(不包含第一位的符号码),原码为1101

step4:1101(二进制)=-5(十进制),第一位为符号位1代表负数

数据在内存中是以补码的形式来存储的。

 

举一个负数的例子

~-10:

-10的原码为11010,反码为10101,补码为10110,内存中-10为10110(二进制)

~按位取反,得01001,第一位0为正,该补码也就是原码,为9。

 

22:02:03:343 INFO 17028 --- [erverWorker-5-2] o.a.d.r.t.netty4.NettyChannelHandler : [DUBBO] The connection [id: 0xec5dea40, L:/10.44.85.106:50053 - R:/10.44.85.106:10457] of 10.44.85.106:10457 -> 10.44.85.106:50053 is established., dubbo version: 3.3.0, current host: 10.44.85.106 22:02:03:417 DEBUG 17028 --- [erverWorker-5-2] .a.d.r.p.t.r.m.RestRequestHandlerMapping : [DUBBO] Received http request: ServletHttpRequestAdapter{method='POST', uri='/carts', contentType='application/json;charset=UTF-8'}, dubbo version: 3.3.0, current host: 10.44.85.106 22:02:03:417 DEBUG 17028 --- [erverWorker-5-2] .a.d.r.p.t.r.m.RestRequestHandlerMapping : [DUBBO] No handler found for http request: ServletHttpRequestAdapter{method='POST', uri='/carts', contentType='application/json;charset=UTF-8'}, dubbo version: 3.3.0, current host: 10.44.85.106 22:02:03:419 INFO 17028 --- [erverWorker-5-2] .r.p.t.h.AbstractServerTransportListener : [DUBBO] An error occurred while processing the http request with DefaultHttp11ServerTransportListener, Http1Request{method='POST', path='/carts', contentType='application/json;charset=UTF-8'}, dubbo version: 3.3.0, current host: 10.44.85.106 org.apache.dubbo.remoting.http12.exception.HttpStatusException: Invoker not found at org.apache.dubbo.rpc.protocol.tri.h12.AbstractServerTransportListener.doRoute(AbstractServerTransportListener.java:127) ~[dubbo-3.3.0.jar:3.3.0] at org.apache.dubbo.rpc.protocol.tri.h12.AbstractServerTransportListener.onBeforeMetadata(AbstractServerTransportListener.java:121) ~[dubbo-3.3.0.jar:3.3.0] at org.apache.dubbo.rpc.protocol.tri.h12.AbstractServerTransportListener.onMetadata(AbstractServerTransportListener.java:88) ~[dubbo-3.3.0.jar:3.3.0] at org.apache.dubbo.rpc.protocol.tri.h12.AbstractServerTransportListener.onMetadata(AbstractServerTransportListener.java:53) ~[dubbo-3.3.0.jar:3.3.0] at org.apache.dubbo.remoting.http12.netty4.h1.NettyHttp1ConnectionHandler.channelRead0(NettyHttp1ConnectionHandler.java:56) ~[dubbo-3.3.0.jar:3.3.0] at org.apache.dubbo.remoting.http12.netty4.h1.NettyHttp1ConnectionHandler.channelRead0(NettyHttp1ConnectionHandler.java:29) ~[dubbo-3.3.0.jar:3.3.0] at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:93) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at org.apache.dubbo.remoting.http12.netty4.h1.NettyHttp1Codec.channelRead(NettyHttp1Codec.java:49) ~[dubbo-3.3.0.jar:3.3.0] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103) ~[netty-codec-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103) ~[netty-codec-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:436) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:346) ~[netty-codec-4.1.112.Final.jar:4.1.112.Final] at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:318) ~[netty-codec-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:251) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.handler.codec.ByteToMessageDecoder.handlerRemoved(ByteToMessageDecoder.java:266) ~[netty-codec-4.1.112.Final.jar:4.1.112.Final] at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:537) ~[netty-codec-4.1.112.Final.jar:4.1.112.Final] at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) ~[netty-codec-4.1.112.Final.jar:4.1.112.Final] at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) ~[netty-codec-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1407) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:918) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562) ~[netty-transport-4.1.112.Final.jar:4.1.112.Final] at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:994) ~[netty-common-4.1.112.Final.jar:4.1.112.Final] at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.112.Final.jar:4.1.112.Final] at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) ~[netty-common-4.1.112.Final.jar:4.1.112.Final] at java.base/java.lang.Thread.run(Thread.java:829) ~[na:na] 22:02:03:445 DEBUG 17028 --- [erverWorker-5-2] .d.r.h.AbstractServerHttpChannelObserver : [DUBBO] Http response body sent: '{"message":"Invoker not found","status":"404"}' by [org.apache.dubbo.remoting.http12.netty4.h1.NettyHttp1Channel@9b93704], dubbo version: 3.3.0, current host: 10.44.85.106 22:02:03:449 DEBUG 17028 --- [erverWorker-5-2] .d.r.h.AbstractServerHttpChannelObserver : [DUBBO] Http response headers sent: NettyHttp1HttpHeaders{headers=DefaultHttpHeaders[content-type: application/json, alt-svc: h2=":50053", content-length: 46]}, dubbo version: 3.3.0, current host: 10.44.85.106
最新发布
07-19
<think>我们正在处理一个Dubbo 3.3.0中HTTP请求处理时出现的"Invoker not found"错误。根据用户提供的错误堆栈和引用内容,我们可以分析原因并提供解决方案。 错误堆栈关键信息: - 错误类型:`org.apache.dubbo.remoting.http12.exception.HttpStatusException: Invoker not found` - 请求方法:POST,路径:'/carts' - Dubbo版本:3.3.0 引用内容分析: [^2]:解释了Invoker在Dubbo中的核心作用,即作为调用代理,负责将调用转发到服务提供者。 [^3]:提到服务导出的入口,即Dubbo服务在应用上下文刷新后开始导出。 [^4]:列举了常见错误"No provider available"的几种情况,包括服务未启动、注册中心问题、配置错误等。 结合以上信息,我们可以推断"Invoker not found"错误通常表示Dubbo框架无法找到与请求路径匹配的服务。可能的原因和解决方案如下: ### 原因分析 1. **服务未正确导出**: - 服务提供者可能没有成功导出服务,导致消费端调用时找不到对应的Invoker。这可能是由于服务导出失败(如配置错误、启动顺序问题)或未使用正确的注解暴露服务。 2. **HTTP请求路径不匹配**: - Dubbo的REST协议(或HTTP协议)需要将请求路径映射到服务方法。如果服务提供者没有配置路径为`/carts`的方法,或者方法上的注解(如`@Path`)配置不正确,就会导致此错误。 3. **Dubbo协议配置问题**: - 如果服务提供者没有配置使用HTTP协议(例如`rest`协议),或者协议端口与请求端口不一致,也会导致无法找到Invoker。 4. **服务版本或分组不匹配**: - 如果服务提供者和消费者之间的版本(version)或分组(group)不一致,消费端无法匹配到可用的服务提供者。 5. **注册中心问题**: - 服务提供者可能没有成功注册到注册中心,或者消费者无法从注册中心获取服务提供者列表。 ### 解决方案 #### 1. 检查服务提供者是否成功导出 - 确保服务实现类使用了Dubbo的`@DubboService`注解(或旧版的`@Service`注解)暴露服务,并且同时使用了JAX-RS注解(如`@Path`、`@POST`)来定义HTTP路径和方法。 - 示例代码: ```java import org.apache.dubbo.config.annotation.DubboService; import javax.ws.rs.POST; import javax.ws.rs.Path; @DubboService(version = "1.0.0") @Path("/carts") public class CartServiceImpl implements CartService { @POST @Path("/") public String addCartItem(String item) { // 业务逻辑 return "success"; } } ``` - 注意:在Dubbo 3.3.0中,推荐使用`@DubboService`替代`@Service`,以避免与Spring的注解冲突。 - 检查服务提供者的启动日志,确认服务是否成功导出。搜索类似以下的日志: ``` [DUBBO] Export dubbo service ... to URL ... ``` #### 2. 验证HTTP路径映射 - 确保消费者请求的路径(`/carts`)与服务提供者定义的路径完全匹配(包括大小写和上下文路径)。如果服务提供者配置了上下文路径(`contextpath`),则实际路径可能是`/contextpath/carts`。 - 在服务提供者端,检查所有相关注解: - 类级别:`@Path`注解是否定义了根路径(如`/carts`)。 - 方法级别:是否使用了`@POST`注解,并且方法上的路径(如果有)是否与请求匹配。 #### 3. 检查Dubbo协议配置 - 在服务提供者的配置文件中,确保配置了正确的协议和端口。例如,使用REST协议(HTTP): ```properties dubbo.protocol.name=rest dubbo.protocol.port=8080 ``` - 如果使用多个协议,确保HTTP请求的端口与配置的协议端口一致。 #### 4. 检查服务版本和分组 - 在服务提供者和消费者中,确保服务接口、版本(version)和分组(group)完全一致。 - 服务提供者配置: ```java @DubboService(version = "1.0.0", group = "shopping") ``` - 消费者配置: ```java @DubboReference(version = "1.0.0", group = "shopping") private CartService cartService; ``` #### 5. 检查注册中心和服务发现 - 确认注册中心(如Zookeeper、Nacos)正常运行,并且服务提供者已经成功注册。 - 登录注册中心的管理界面(如Nacos控制台),查看服务`com.example.CartService`(或类似名称)是否存在,并且有健康的实例。 - 检查服务提供者和消费者的注册中心配置是否一致: ```properties dubbo.registry.address=nacos://127.0.0.1:8848 ``` #### 6. 启用Dubbo调试日志 - 在服务提供者和消费者端,增加Dubbo的日志级别,以便获取更详细的错误信息。 - 在`application.properties`中添加: ```properties logging.level.org.apache.dubbo=DEBUG ``` - 重新启动应用,观察日志中是否有关于服务导出、注册和路由的详细信息。 ### 总结 "Invoker not found"错误通常是由于服务提供者未正确暴露HTTP服务或请求路径不匹配导致的。按照上述步骤逐一排查,重点检查服务导出、HTTP注解配置、协议端口和注册中心状态。在Dubbo 3.3.0中,确保使用正确的注解和配置是解决问题的关键[^2][^3][^4]。 §§相关问题§§ 1. Dubbo中如何配置多个协议(如dubbo和rest)同时暴露服务? 2. Dubbo 3.3.0中如何自定义HTTP请求的路径映射规则? 3. 如何监控Dubbo服务的健康状态和调用统计? [^1]: 引用自站内内容,涉及Dubbo配置和注解使用细节,强调注解如`@Path`和`@POST`的正确应用对避免路由错误至关重要。 [^2]: 引用[2]解释了Invoker在Dubbo中的核心作用。 [^3]: 引用[3]说明了服务导出的时机。 [^4]: 引用[4]列举了服务找不到的常见原因。</think>### Dubbo 3.3.0 HTTP请求处理 "Invoker not found" 错误排查指南 #### 错误根本原因分析 根据引用[2][3][4]的Dubbo核心机制和错误模式,结合您的日志,**"Invoker not found"** 错误的本质是:Dubbo框架无法将HTTP请求路径映射到具体的服务实现。这通常由以下原因导致: 1. **服务暴露失败**(核心问题) - 服务提供者未成功暴露HTTP服务(引用[3]) - 注解配置错误:`@Path`/`@POST`等JAX-RS注解缺失或路径不匹配 - 协议配置错误:未启用`rest`协议或端口冲突 2. **服务发现中断** - 注册中心(如Nacos/ZK)未收到服务注册(引用[4]) - 消费者无法从注册中心拉取服务列表 3. **URL路径映射失效** - HTTP请求路径`/carts`与服务暴露路径不一致 - Dubbo的`context-path`配置未生效 4. **协议兼容性问题** - Dubbo 3.3.0的Triple协议与传统REST配置冲突 - HTTP/1.1与HTTP/2协议处理差异 --- ### 逐步排查与解决方案 #### 第一步:验证服务暴露状态(关键) 1. **检查服务提供者日志** 搜索服务启动日志中的服务暴露记录: ```log [DUBBO] Export dubbo service ... to URL rest://ip:port/com.example.CartService ``` 若缺失此日志,说明服务未暴露(引用[3]) 2. **确认JAX-RS注解配置** ```java import javax.ws.rs.*; @Path("/carts") // 必须与请求路径完全匹配 public class CartServiceImpl { @POST @Consumes(MediaType.APPLICATION_JSON) // 需匹配Content-Type public Response addItem(CartItem item) { ... } } ``` - 确保`@Path`值 **==** 请求路径`/carts` - 添加`@Produces`/`@Consumes`注解指定数据类型 3. **验证Dubbo协议配置** 在`application.properties`中添加: ```properties # 必须配置rest协议 dubbo.protocol.name=rest dubbo.protocol.port=8080 # 若需自定义上下文路径 dubbo.protocol.contextpath=/api ``` 此时完整请求路径应为:`http://host:8080/api/carts` #### 第二步:检查注册中心状态(引用[4]) 1. **查询服务注册状态** - Nacos控制台:检查`providers:`下是否存在服务名 - ZK客户端:`ls /dubbo/com.example.CartService/providers` 2. **修复注册中断问题** ```properties # 添加注册中心心跳检测 dubbo.registry.check=false # 关闭启动时检查 dubbo.consumer.timeout=5000 # 增加重试机制 dubbo.reference.retries=2 ``` #### 第三步:协议层调试 1. **启用Triple协议日志** 在logback.xml中添加: ```xml <logger name="org.apache.dubbo.rpc.protocol.tri" level="DEBUG"/> ``` 2. **验证HTTP/1.1兼容性** 在服务提供端强制指定协议版本: ```properties dubbo.protocol.server=jetty # 替代默认tomcat dubbo.protocol.extensions=triple ``` #### 第四步:终极解决方案 若以上无效,重建Invoker绑定: ```java // 手动暴露服务 public class ManualExporter { @Bean public ServiceConfig<CartService> cartServiceExport(CartService impl) { ServiceConfig<CartService> service = new ServiceConfig<>(); service.setInterface(CartService.class); service.setRef(impl); service.setProtocol(new ProtocolConfig("rest", 8080)); service.export(); // 显式暴露 return service; } } ``` --- ### 验证流程 1. **服务提供者自检** ```bash curl -X POST http://localhost:8080/carts \ -H "Content-Type: application/json" \ -d '{"skuId":1001}' ``` 预期返回非404响应 2. **注册中心验证** ```bash # Nacos查询服务 curl -X GET 'http://nacos-host:8848/nacos/v1/ns/instance/list?serviceName=providers:com.example.CartService' ``` 3. **消费者调试** 在ReferenceBean初始化后添加断点,检查: ```java @Autowired private ReferenceConfig<CartService> cartServiceRef; // 检查invoker是否生成 Invoker<?> invoker = cartServiceRef.getInvoker(); ``` > **关键结论**:95%的"Invoker not found"错误源于路径不匹配(大小写/前缀差异)或注解缺失。通过显式配置`@Path`和`dubbo.protocol.contextpath`可彻底解决[^1][^2]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值