前言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 能力、具备动态选择扩展实现的能力等。

Apache APISIX 是 Apache 软件基金会下的云原生 API 网关，它具有多平台支持、精细化路由、运维友好和插件支持的优点特点。

本文主要介绍 JDK/Spring/Dubbo 中的 SPI 机制。

随着瓜子业务的不断发展，系统规模在逐渐扩大，目前在瓜子的私有云上已经运行着数百个 Apache Dubbo （ 下文简称 Dubbo ）应用，上千个 Dubbo 实例。瓜子各部门业务迅速发展，版本没有来得及统一，各个部门都有自己的用法。随着第二机房的建设，Dubbo 版本统一的需求变得越发迫切。几个月前，公司发生了一次与 Dubbo 相关的生产事故，成为了公司 基于社区 Dubbo 2.7.3 版本升级的诱因。