上篇文章如果有人问你 Dubbo 中注册中心工作原理，就把这篇文章给他大致了解了注册中心作用以及 Dubbo Registry 模块源码，这篇文章将深入 Dubbo ZooKeeper 模块，去了解如何实现服务动态的发现。ps: 以下将 ZooKeeper 缩写为 zk。一、dubbo zk 数据结构在 ZooKeeper 基本概念分享一文讲道，ZK 内部是一种树形层次结构，节点存在多种类型。而
文章目录前言一、问题分析1、分析日志2、定位原因二、解决方案三、总结 前言 某天早上9点左右收到线上故障报警，超过3个商家反馈“无法正常进入功能页面，点击相关操作提示报错”。 经过排查定位，故障应用线上部署了30台机器（4c8g），由于代码中使用 CompletableFuture不规范引起部分机器（8/30台）dubbo 线程池耗尽出现故障。而我们的dubbo框架采用随机负载均衡策略，导
dubbo 线程模型 上图体现出了在dubbo的服务端，在传输完成接收到客户端的请求之后，是通过Dispatcher分发请求到线程池处理之后，返回结果给客户端，当然，也可以直接由Dispatcher处理并返回结果。官方建议如果事件处理的逻辑能迅速完成，并且不会发起新的 IO 请求，比如只是在内存中记个标识，则直接在 IO 线程上处理更快，因为减少了线程池调度。但如果事件处理逻辑较慢，或者需要发起新
前言：通过之前对provider启动过程的学习，我们知道，提供者默认是以Netty来启动对应协议端口来提供服务的。Netty的标准启动模式下有两个线程组：boss和work线程组。在接收到具体的请求后，如果服务提供者对该请求处理时间比较短，那么直接在work线程上处理即可；如果服务提供者对该请求处理时间比较长，那么如果还在work线程上处理，则会阻塞其他请求的处理，降低了整个provider的处理
对于Dubbo的服务提供者，主要有两种线程池，一种是IO处理线程池，另一种是服务调用线程池。而作为IO处理线程池，由于Dubbo基于Mina、Grizzly和Netty框架做IO组件，IO线程池都是基于这些框架来配置，比如Netty中的boss和worker线程池，Dubbo选择的是“无边界”的CachedThreadPool，这意味着对所有服务请求先做到“来者不拒”，但它进一步限制了IO处理的线
论起微服务，哪能不谈网关，老将有Zuul，后继有Gateway，但这些都和SpringCloud关系密切，其他网关如Kong，因Lua原因，玩起来略不顺手。这不，就来了个Soul，我顺便拿来整进了我在写的项目中，感觉还行，也发现了些问题，表现有待观察，另一方面发现Soul资料略少，我就出点实例供看官参考参考。准备：Idea2019.03/Gradle6.0.1/JDK11.0.4/Lombok0.
Dubbo缺省协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。Dubbo缺省协议，使用基于mina1.1.7+hessian3.2.1的tbremoting交互。连接个数：单连接连接方式：长连接传输协议：TCP传输方式：NIO异步传输序列化：Hessian二进制序列化适用范围：传入传出参数数据包较小（建议小于100K），消费者
在分布式服务当中监控服务的各项指标至关重要，而 dubbo 也提供了一个简单的监控中心(Simple Monito)。Simple Monitor挂掉不会影响到Consumer和Provider之间的调用，所以用于生产环境不会有风险。 并且配置好了之后可以结合 admin 管理后台使用，可以清晰的看到服务的访问记录、成功次数、失败次数等…Simple Monitor 采用磁盘存储统计信息，请注意安
Dubbo的服务消费主要包括两个部分。第一大步是ReferenceConfig类的init方法调用Protocol的refer方法生成Invoker实例，这是服务消息的关键。第二大步是把Invoker通过动态代理转换成实现用户接口的动态代理引用。这里的Invoker承载了网络连接、服务调用和重试等功能。服务暴露起点在消费者的配置文件中存在这个代码：<!-- 生成远程服务代理，可以和本地bea
本文代码摘录的时候，将一些与本流程无关的内容去掉了，如有需要请看源码。如果大家对Dubbo RPC原理原理感兴趣，可以看我之前写过的另外一篇博客《 Dubbo RPC源码解读》。 一、 思考与目标1. 思考并发情况下，dubbo的RPC模型如下图所示：如图所示，Consumer端可能同时有多个线程调用Provider的服务，此时Provider会启动多个线程来分别处理这些并发调用，处理完
1. 前言前面的文章分析了Dubbo Provider是如何处理RPC调用请求的，整个处理链路是清晰了，但是关于线程模型却一笔带过，Dispatcher也只是简单介绍了一下，本篇文章会全面分析Provider线程模型。 Dubbo线程可以分为两大类，一类是用于处理底层网络通信的IO线程，一类是处理业务逻辑的业务线程，也可称作Dubbo线程。IO线程以Netty为例，又细分为Boss和Worker，
Dubbo作为一个服务治理框架，功能相对来说比较完善，性能也挺不错。但很多同学在使用dubbo的时候，只是简单的参考官方说明进行配置和应用，并没有过多的去思考一些关键参数的意义，最终做出来的效果总是差强人意,接下来我们将给大家详细的介绍Dubbo调优的常用参数以及原理。一、Dubbo调用模型二、常用性能调优参数三、源码以及原理分析上面的第二节讲解了每个参数的含义，那么接下来我们一起看看具体的源码实
今天这篇，我们来聊一聊一个Dubbo服务是如何发布的。 Dubbo支持多种容器，我们今天聊的，是基于Spring的Dubbo服务发布过程。如何发布一个Dubbo服务在看源码之前，我们不妨自己想一想，如何发布一个Dubbo服务。大家都应该有过Dubbo的使用经验。我们的Dubbo服务信息一般都是维护在如Zookeeper这样的注册中心的（不考虑injvm这种本机调用）。所以，发布一个Dubbo服务，
目录简介1、Dubbo是什么？2、Dubbo底层对于线程池3、采集数据4、上报数据 5、数据展示简介简历写着熟悉 Dubbo，面试的时候一问，居然连 Dubbo 线程池监控都不知道，就问你尴不尴尬，今天就来分享一下 Dubbo 线程池监控；1、Dubbo是什么？Dubbo 是一款优秀的微服务框架，它以其高性能、简单易用、易扩展等特点，广泛应用于互联网、金融保险、科技公司、制造业、零售物流
目录启动时检查负载均衡Random LoadBalanceRandomLoadBalance 算法 RoundRobin LoadBalanceRandomLoadBalance 算法LeastActive LoadBalanceLeastActiveLoadBalance 算法ConsistentHash LoadBalanceConsistentHashLoadBalance 算法线
Dubbo的线程池压测调优 dubbo的服务提供者端一共包含了两类线程池，一类叫做io线程池，还有一类叫做业务线程池，它们各自有着自己的分工，如下图所示 dubbo在服务提供方中有io线程池和业务线程池之分。可以通过调整相关的dispatcher参数来控制将请求处理交给不同的线程池处理。（下边列举工作中常用的几个参数：）all：将请求全部交给业务线程池处理（这里面除了日常的消费者进行服务调用之外，
本文基于dubbo 2.7.5版本代码在RPC调用中，线程一共要做两件事：一是接受消息或者发送消息，也就是网络交互，这个可以认为是IO处理，二是处理业务，包括将请求转发给底层提供服务的对象，并且执行服务逻辑，这个可以认为是业务处理。这两件事可以使用不同的线程处理，也可以用相同的线程处理。由此便产生了不同的线程模型。 这里的线程模型指的是接受消息后使用IO线程还是业务线程处理消息，其中要处理的消息包
Provider端线程模型 在了解服务端线程模型之前，先了解一下Dubbo对Channel上的操作抽象，Dubbo将Channel上的操作成了5中行为，分别是：建立连接、断开连接、发送消息、接收消息、异常捕获，Channel上的操作的接口为org.apache.dubbo.remoting.ChannelHandler，该接口是SPI的，用户可以自己扩展，接口代码如下：该
dubbo微服务分为服务提供者和服务消费者，单个linux虚拟机上部署单个dubbo服务节点，机器配置一般是4核8G内存，JVM参数配置是最大JVM内存是4G，其他的参数配置请百度参考。这次小编我用的是8核8G内存的linux虚拟机，该机器上部署了2个微服务节点，JVM最大内存是2G。我把服务消费者部署在另外的linux虚拟机上，部署了两个服务消费者，然后用nginx作负载均衡，请求分别路由到这两
一台java服务器能跑多少个线程？这个问题来自一次线上报警如下图，超过了我们的配置阈值。 打出jstack文件，通过IBM Thread and Monitor Dump Analyzer for Java工具查看如下： 共计1661个线程，和监控数据得出的吻合。但这个数量应该是大了，我们都知道线程多了，就会有线程切换，带来性能开销。当时就想到一台java服务器到底可以跑多
