Dubbo的内核中只包含了服务调用、集群管理、路由策略等最基础的核心功能。而除了核心之外的其他功能，全都通过扩展实现。包括：序列化、协议、负载均衡、过滤器等。

每个扩展都有一个对应的接口定义，具体实现可以自定动态加载和替换，这样插件式的设计，可以根据不同的业务选择不同的实现，灵活多变。

本篇文章，和大家分享一下之前发生在生产环境的一次问题排查与分析过程，这个问题本身并没有特别复杂，但需要排查的同学足够的细心谨慎，能从监控及日志中提取关键信息，一步步缩小问题范围并最终定位到问题点，这个问题点一般都可以具体到一行确定的代码，即问题代码。但”问题代码“往往并不一定是”错误代码“，由于运行时因为一些其他因素，导致这行看上去完全正确的代码，运行出了不符合预期的结果，而这个结果也可能是偶发的，即它没有固定的发生条件，比如发生时间、发生节点和发生数据等等，这也是大部分疑难故障难以直接通过review代码的方式来定位的原因。

因此，我们排查问题时，切勿想当然，而是要严格基于现有的数据”大胆假设小心求证“，并适当使用排除法，真相一定只有一个。

代码中的maxBufferSize + extraMaxBufferSize默认大小为2M，而异常中的Unreasonable length = 10053968已经达到了9.58M，远超2M，故抛出异常。

经过搜索，发现该值由系统变量jute.maxbuffer配置，它指定了znode中可以存储的数据的最大大小。

随即将该值调整至20M后，重启所有节点，集群恢复。

那么，这个9.58M大小的数据到底是什么？

Apache Dubbo 是一款高性能的 Java RPC 框架，主要用于构建分布式服务。

微服务应用在下线过程中存在服务无损的问题。在高并发下，直接下线服务提供端应用实例会导致服务消费端无法实时感知下游实例的状态，继续将请求转发到已下线的实例，导致请求报错和流量损失。为解决这个问题，可以采取两个步骤：1.通过注册中心提供的主动注销接口通知服务下线；2.在注销前手动向注册中心发起注销请求，关闭流量入口。这样能避免请求发送到已下线的实例，并保证流量的正常转移。在Spring+Dubbo架构下，需要拦截下线命令，不直接执行Shutdown操作，并在销毁前手动向注册中心发起注销请求。

笔者支持过程中多次发现诡异的Dubbo接口异常问题，抓耳挠腮最后定位到代码上和代码外的原因，事后只感觉脑瓜子嗡嗡的。考虑到这不是第一次，也绝不会是最后一次出现类似问题，下面笔者将尽可能详细的梳理、总结一下该问题的现象和本质。

本文对发现线上Dubbo调用异常、排查、处理流程进行了详细介绍。

对于一些 Thread pool is EXHAUSTED 异常，本文基于框架原理和网络原理进行逻辑推导，给出了合理的解释。

自 JDK 1.6 以后，Java 提出了 SPI，一种服务提供发现机制，可以用来启用框架扩展和替换组件。其主要目的是将装配控制权移到程序之外，模块化设计中这个机制尤其重要。其核心思想是解耦。

本文主要介绍在vivo内部针对Dubbo路由模块及负载均衡的一些优化手段，主要是异步化+缓存，可减少在RPC调用过程中路由及负载均衡的CPU消耗，极大提升调用效率。

通过CompletableFuture可以将复杂的业务逻辑从Dubbo线程池（大小默认200）切换到用户自定义的业务线程来执行，提升Dubbo线程池请求的处理能力，同时增加自定义业务线程池，提升服务器的资源利用率。

本文将以 Dubbo 源码为例，和您讨论如何使用 Lambda 和面向对象两种方法，对 Java 应用进行重构。并以实例展示了两者结合，写出简洁优雅的代码。

本文介绍了Go 微服务体系发展与选型，过去一年优雅上下线以及对未来的展望。

本文我们将介绍 Apache Dubbo 灵活的多协议设计原则。

本文通过分析Dubbo中ZooKeeper注册中心的实现ZooKeeperResitry的继承体系结构，详细介绍了Dubbo中ZooKeeper注册中心的实现原理。

Dubbo 中的扩展能力是从 JDK 标准的 SPI 扩展点发现机制加强而来，用户能够基于 Dubbo 提供的扩展能力，可以很方便的实现：按需加载、增加扩展类的 IOC 能力、增加扩展类的 AOP 能力、具备动态选择扩展实现的能力等。