Dubbo

前言 记录一次 Dubbo 线上故障排查和原因分析。 线上 Dubbo 消费者启动有错误日志如下，但是不影响服务启动。 紧接着，消费者发起 RPC 调用，偶发性报错如下： 消费者尝试重启，RPC 调用

前言 Apache Dubbo 3.3 对 Triple 协议做了升级，现在 Dubbo 不仅可以处理东西向流量，也可以处理南北向流量。 **东西向流量（East-West Traffic） ** 指

前言 Dubbo3 发布了基于 HTTP1、HTTP2、HTTP3 的 triple 通信协议，相较于之前的 dubbo 私有化协议，triple 协议在跨语言、云原生、服务治理方面有显著优势。

前言 Dubbo 框架采用“微内核+插件”的开发机制，序列化就是以插件的形式存在的。 Dubbo 支持很多常用的序列化方式，例如：protobuf、hessian2、kryo、fastjson2 等。

前言 随着越来越多的应用逐渐微服务化后，分布式服务之间的RPC调用使得异常排查的难度骤增，最明显的一个问题，就是整个调用链路的日志不在一台机器上，往往定位问题就要花费大量时间。如何在一个分布式网络中把

1. 前言 前面的文章已经分析了，Dubbo在做集群调用时，Directory会先根据Router做路由规则过滤，最后幸存下来的Invoker才会对它们做负载均衡。 ​ LoadBalance是Dub

1. 前言 前面的文章分析了Dubbo集群容错层之Cluster和ClusterInvoker，我们已经知道，Directory会提供可调用的服务列表，Cluster会将这一组服务聚合成单个具备集群容

1. 前言 线上服务很少会单机部署，它不满足互联网三高架构的需求。服务一旦挂了，高可用就无从谈起，另外Dubbo单机默认最大200的并发处理也不满足所谓的高并发、高性能。所以，作为一款优秀的分布式服务

1. 前言 之前的文章分析了Provider线程模型，本文开始分析客户端Consumer的线程模型，其实两者还是有很多相似之处的。 ​ Consumer同样有IO线程和业务线程两类，IO线程负责和服务

1. 前言 前面的文章分析了Dubbo Provider是如何处理RPC调用请求的，整个处理链路是清晰了，但是关于线程模型却一笔带过，Dispatcher也只是简单介绍了一下，本篇文章会全面分析Pro

1. 前言 前面的文章分析了Consumer是如何发起RPC调用，以及请求对象Request是如何从客户端编码然后经过网络发送到服务端，服务端再解码的一个过程，接下来，开始分析服务端Provider是

1. 前言 前面分析了Consumer是如何发起远程服务调用的，最终DubboInvoker会利用ExchangeClient客户端发送网络请求。Dubbo会将网络请求封装为Request对象发送，但

1. 前言 之前的文章对Dubbo服务暴露和引用流程进行了分析，再然后了解了Dubbo网络通讯协议的设计细节，现在终于到了最激动人心的时刻，我们将分析Dubbo是如何实现服务调用的。篇幅原因，文章会拆

1. 前言 前面已经分析了Dubbo是如何暴露以及引用远程服务的，接下来自然是服务调用的实现细节了，但是在那之前，有必要先了解Dubbo的网络通信协议。 ​ 在单机系统中，调用本地方法获取结果很简单，

1. 前言 DubboBootstrap启动时，首先会通过initialize()方法完成初始化，装配各种Config对象，为后续的服务暴露和引用准备好环境。 ReferenceConfig是Dubb

1. 前言 DubboBootstrap启动时，首先会通过initialize()方法完成初始化，装配各种Config对象，为后续的服务暴露和引用准备好环境。 ​ ServiceConfig对象就是D

1. 前言 Dubbo一般很少单独使用，更多的是和Spring框架做集成，但是不管怎样，Dubbo最终都是创建并启动DubboBootstrap。Dubbo系列文章只研究Dubbo，因此不会和Spri

1. 前言 Dubbo服务框架采用了「微内核+插件」的设计原则，Dubbo自身的核心功能点也是通过扩展点实现的，这意味着Dubbo几乎所有的功能点都可以由用户自定义的扩展和替换，这也大大的提高了Dub