有性能问题，上HeapDump性能社区

上个月公司zk集群发生了一次故障，然后要求所有项目组自检有无使用Dubbo编程式/泛化调用，强制使用@Reference生成Consumer。具体原因是线上某服务访问量在短时间大量访问zk并创建了240万+的节点，导致zk所有节点陆续崩溃导致，多个应用因无法连接到zk报错。原因是听说泛化调用时候，p

导读：服务端在向外提供接口服务时，不管是对前端提供HTTP接口，还是面向内部其他服务端提供的RPC接口，常常会面对这样一个问题，就是如何优雅的解决各种接口参数校验问题？早期大家在做面向前端提供的HTTP接口时，对参数的校验可能都会经历这几个阶段：每个接口每个参数都写定制校验代码、提炼公共校验逻辑

说明：本文场景基于dubbo-2.5.3版本。 如果你对StackOverflowError有一定的了解，就可以知道出现这个问题的主要原因就是调用栈太深，比如常见的无限递归调用。那本文要介绍的Dub

前言dubbo是一个成熟且被广泛运用的框架。饶是如此,在某些极端条件下基于dubbo的应用还会出现无法重连zookeeper的问题。由于此问题容易导致比较大的故障，所以笔者费了一番功夫去定位，现将排查

大家好，我是tin，这是我的第16篇原创文章​ 真正开始深入阅读Dubbo的原理和核心源码前，今天先讲讲Dubbo的一些基本理解

前言笔者最近解决了一个困扰了业务系统很久的问题。这个问题只在发布时出现，每次只影响一两次调用，相较于其它的问题来说，这个问题有点不够受重视。由于种种原因，使得这个问题到了业务必须解决的程度，于是就到了

前言笔者最近完成了一个非常有意思的隧道机制(已在产线运行)，可以让注册到不同zookeeper之间的dubbo集群之间能够正常进行通信。如下图所示: 例如图中A/B两个网络隔离的集群，两者只能通过专线

前言前几天在测试环境碰到一个非常奇怪的与 ```dubbo``` 相关的问题，事后我在网上搜索了一圈并没有发现类似的帖子或文章，于是便有了这篇。希望对还未碰到或正在碰到的朋友有所帮助。 现象现象是这样

前言某天业务方的同事和我反馈,说系统出现了StackOverflowError.坦白说,Exception见得过了,但是Error倒是很少出现,此时他的心情是这样的 一波猛如虎的操作我们先来看血淋淋的

Dubbo在国内微服务界的名气不用我说大家应该都知道，它有很多的突出的设计点，其中，扩展机制就是一个。如何给Dubbo自定义加一个扩……