1.dubbo Դ?码分????
2.Java教程：dubbo源码解析-网络通信
3.Dubbo源码解析：网络通信
4.Dubbo源码之rpc的调用流程分析
dubbo Դ?????
某天，运营反馈称，码分执行一次保存操作后，码分后台出现3条数据，码分我立刻怀疑可能存在代码问题。码分为了确保不会误判，码分USDT 源码我要求暂停操作，码分保留现场，码分以便我进行排查。码分
查看新增代码，码分发现是码分同事三歪进行的改动，他将原有的码分dubbo XML配置方式改为了注解方式。我询问其改动详情，码分得知他是码分更改了模块的配置方式。于是码分，我决定深入研究，找出问题所在。
dubbo配置方式多样，最常见的为XML配置与注解配置。我已初步推测原因，接下来将进行详细的调试过程。
我使用dubbo版本2.6.2进行调试。首先，针对采用@Reference注解条件下的重试次数配置，我发现调用接口时，跑腿APP及其源码会跳转到InvokerInvocationHandler的invoke方法。继续跟踪，最终定位到FailoverClusterInvoker的doInvoke方法。在该方法中，我关注到获取配置的retries值，发现其默认值为null，导致最终计算出的重试次数为3。
采用dubbo:reference标签配置重试次数时，同样在获取属性值后，发现其默认值为0，与注解配置一致，最终计算出的重试次数为1。对比两种配置方式，我总结了以下原因：
在@Reference注解形式下，dubbo会在注入代理对象时，通过自定义驱动器ReferenceAnnotationBeanPostProcessor来注入属性。在标签形式下，虽然也使用了Autowired注解，但dubbo会使用自定义名称空间解析器DubboNamespaceHandler进行解析。
在注解形式下，当配置retries为0时，属性值在注入过程中并未被解析为null，但进入buildReferenceBean时，因nullSafeEquals方法的hdmi输出音频源码处理，导致默认值和实际值不一致，最终未保存到map中。而标签形式下，解析器能够正确解析出retries的值为0，避免了后续的问题。
总结发现，采用@Reference注解配置重试次数时，dubbo在注入属性过程中存在逻辑处理上的问题，导致默认值与实际值不一致。此为dubbo的一个逻辑bug。建议在不需要重试时，设置retries为-1，以确保接口的幂等性。需要重试时，设置为1或更大值。
问题解决后，我优化了文件操作，将其改为异步处理，从而缩短了主流程的时间。最终，数据出现3条的状况得以解决。
此问题已得到解决，并在后续dubbo版本2.7.3中修复，确保了在注解配置方式下，明星97源码组建nullSafeEquals方法能够正确处理默认值与实际值一致的情况。
Java教程：dubbo源码解析-网络通信
在之前的内容中，我们探讨了消费者端服务发现与提供者端服务暴露的相关内容，同时了解到消费者端通过内置的负载均衡算法获取合适的调用invoker进行远程调用。接下来，我们聚焦于远程调用过程，即网络通信的细节。
网络通信位于Remoting模块中，支持多种通信协议，包括但不限于：dubbo协议、rmi协议、hessian协议、ty进行网络通讯，NettyClient.doOpen()方法中可以看到Netty的相关类。序列化接口包括但不限于：Serialization接口、Hessian2Serialization接口、Kryo接口、FST接口等。
序列化方式如Kryo和FST，性能往往优于hessian2，能够显著提高序列化性能。这些高效Java序列化方式的引入，可以优化Dubbo的序列化过程。
在配置Dubbo RPC时，才招聘系统源码引入Kryo和FST非常简单，只需在RPC的XML配置中添加相应的属性即可。
关于服务消费方发送请求，Dubbo框架定义了私有的RPC协议，消息头和消息体分别用于存储元信息和具体调用消息。消息头包括魔数、数据包类型、消息体长度等。消息体包含调用消息，如方法名称、参数列表等。请求编码和解码过程涉及编解码器的使用，编码过程包括消息头的写入、序列化数据的存储以及长度的写入。解码过程则涉及消息头的读取、序列化数据的解析以及调用方法名、参数等信息的提取。
提供方接收请求后，服务调用过程包含请求解码、调用服务以及返回结果。解码过程在NettyHandler中完成，通过ChannelEventRunnable和DecodeHandler进一步处理请求。服务调用完成后，通过Invoker的invoke方法调用服务逻辑。响应数据的编码与请求数据编码过程类似，涉及数据包的构造与发送。
服务消费方接收调用结果后，首先进行响应数据解码，获得Response对象，并传递给下一个处理器NettyHandler。处理后，响应数据被派发到线程池中，此过程与服务提供方接收请求的过程类似。
在异步通信场景中，Dubbo在通信层面为异步操作，通信线程不会等待结果返回。默认情况下，RPC调用被视为同步操作。Dubbo通过CompletableFuture实现了异步转同步操作，通过设置异步返回结果并使用CompletableFuture的get()方法等待完成。
对于异步多线程数据一致性问题，Dubbo使用编号将响应对象与Future对象关联，确保每个响应对象被正确传递到相应的Future对象。通过在创建Future时传入Request对象，可以获取调用编号并建立映射关系。线程池中的线程根据Response对象中的调用编号找到对应的Future对象，将响应结果设置到Future对象中，供用户线程获取。
为了检测Client端与Server端的连通性，Dubbo采用双向心跳机制。HeaderExchangeClient初始化时，开启两个定时任务：发送心跳请求和处理重连与断连。心跳检测定时任务HeartbeatTimerTask确保连接空闲时向对端发送心跳包，而ReconnectTimerTask则负责检测连接状态，当判定为超时后，客户端选择重连，服务端采取断开连接的措施。
Dubbo源码解析：网络通信
在之前的章节中，我们探讨了消费者如何通过内置的负载均衡找到服务提供者以及服务暴露的原理。本节重点关注的是消费者如何通过网络与提供者进行远程调用的详细过程，涉及Dubbo框架的网络通信机制。
网络通信主要在Dubbo的Remoting模块中实现，Dubbo支持多种协议，包括自定义的Dubbo协议、RMI、Hessian、HTTP、WebService、Thrift、REST、gRPC、Memcached和Redis等，每种协议有其特点。例如，Dubbo协议利用NIO异步通信，适合处理大量并发小数据量的场景，而RMI采用阻塞式短连接，适合Java RMI应用。
序列化在通信中起着至关重要的作用，Dubbo支持多种序列化方式，如Hessian2、Java、Fastjson等，其中Hessian2是默认选择。近年来，高效序列化技术如Kryo和FST不断涌现，它们的性能优于Hessian2，可通过配置引入以优化性能。
数据在网络传输中需要解决粘包拆包问题，Dubbo通过定义私有RPC协议，消息头包含魔数、类型和长度等信息，以确保数据的正确接收。在消费者发送请求时，首先会生成一个封装了方法和参数的Request对象，经过编码后通过Netty发送。提供方则通过Netty接收请求，解码后执行服务逻辑并返回Response对象。
双向通信中，服务提供方和消费方都通过心跳机制来检查连接状态，客户端和服务端都设有定时任务，确保数据的及时交互。在异步调用中，Dubbo通过CompletableFuture实现从异步到同步的转换，并处理并发调用时的数据一致性问题。
Dubbo源码之rpc的调用流程分析
Dubbo源码中rpc的调用流程，以2.7.6版本为例，可以分为以下三个阶段：阶段一：用户调用与服务选择
1. 用户代码通过RpcInvocation封装rpc请求，通过InvokerInvocationHandler#invoke触发，然后交给DubboInvoker处理。2. Cluster层中的ClusterInterceptor扩展点会对Invoker进行扩展，如隐式传参特性，接着是AppContextClusterInterceptor的上下文管理。
3. ClusterInvoker通过Directory#list和AbstractClusterInvoker#initLoadBalance选择一个服务提供者，结合LoadBalance算法，如默认的RandomLoadBalance。
阶段二：服务提供者处理与响应
1. 服务提供者端，ProtocolInvoker接收请求后，经过Filter链，最终执行实际的rpc服务。2. 通讯层负责序列化请求（如DubboCountCodec）并发送给provider。
3. 接收端，通讯层反序列化响应，将业务请求提交到业务线程池，通过HeaderExchangeHandler处理并返回。
阶段三：消费者接收响应
1. consumer端的ThreadlessExecutor等待响应，从通讯层获取反序列化的Response，取消超时检测并设置future结果。2. RpcInvocationHandler#invoke从future获取结果，并返回给用户代码。
同步rpc调用的关键在于业务线程与io线程的协作，通过队列机制实现阻塞等待，使得同步调用得以实现。负载均衡算法并非完全随机，而是考虑了权重因素，如warmup时权重减半以优化性能。
