远程调用——Listener 目标：介绍dubbo-rpc-api中的各种listener监听器的实现逻辑，内容略少，随便撇两眼，不是重点。 前言 本文介绍监听器的相关逻辑。在服务引用和服务发现中监听器处于的位置请看下面的图： 服务暴露： 服务引用： 这两个监听器所做的工作不是很多，来看看源码理解一下。 源码分析 （一）ListenerInvoke...

远程调用——Filter 目标：介绍dubbo-rpc-api中的各种filter过滤器的实现逻辑。 前言 本文会介绍在dubbo中的过滤器，先来看看下面的图： 可以看到红色圈圈不服，在服务发现和服务引用中都会进行一些过滤器过滤。具体有哪些过滤器，就看下面的介绍。 源码分析 （一）AccessLogFilter 该过滤器是对记录日志的过滤器，它所做...

最近我面临着一个选择，因为dubbo 2.7.0-release出现在了仓库里，最近一直在进行2.7.0版本的code review，那我之前说这一系列的文章都是讲述2.6.x版本的源代码，我现在要不要选择直接开始讲解2.7.0的版本的源码呢？我最后还是决定继续讲解2.6.x，因为我觉得还是有很多公司在用着2.6.x的版本，并且对于升级2.7.0的计划应...

对于zookeeper我相信肯定不陌生，在之前的文章里面也有讲到zookeeper来作为注册中心。在这里，基于zookeeper来实现远程通讯，duubo封装了zookeeper client，来和zookeeper server通讯。

netty4对netty3兼容性不是很好，并且netty4在很多的术语和api也发生了改变，导致升级netty4会很艰辛，网上应该有很多相关文章，高版本的总有高版本的优势所在，所以dubbo也需要与时俱进，又新增了基于netty4来实现远程通讯模块。下面讲解的，如果跟上一篇文章有重复的地方我就略过去了。关键还是要把远程通讯的api那几篇...

现在dubbo默认的网络传输Transport接口默认实现的还是基于netty3实现的网络传输，不过马上后面默认实现就要改为netty4了。由于netty4对netty3对兼容性不是很好，所以保留了两个版本的实现。

Apache MINA是一个网络应用程序框架，可帮助用户轻松开发高性能和高可扩展性的网络应用程序。它通过Java NIO在各种传输（如TCP / IP和UDP / IP）上提供抽象的事件驱动异步API。它通常被称为NIO框架库、客户端服务器框架库或者网络套接字库。那么本问就要讲解在dubbo项目中，基于mina的API实现服务端和客户端来完成远程通...

本文我们讲解的是如何基于Tomcat或者Jetty实现HTTP服务器。Tomcat和Jetty都是一种servlet引擎，Jetty要比Tomcat的架构更简单一些。关于它们之间的比较，我觉得google一些更加方便，我就不多废话了 。

Grizzly NIO框架的设计初衷是帮助开发者更好地利用Java NIO API，构建强大的可扩展的服务器应用。关于Grizzly我也没有很熟悉，所以只能根据grizzly在dubbo的远程通讯中应用稍微讲解一下。

从dubbo 2.0.5开始，dubbo开始支持通过 telnet 命令来进行服务治理。本文就是讲解一些公用的telnet命令的实现。下面来看一下telnet实现的类图：

缓存区在NIO框架中非常重要，它作为字节容器，每个NIO框架都有自己的相应的设计实现。比如Java NIO有ByteBuffer的设计，Mina有IoBuffer的设计，Netty4有ByteBuf的设计。 那么在本文讲到的内容是dubbo对于缓冲区做的一些接口定义，并且做了不同的框架实现缓冲区公共的逻辑。下面是本文要讲到的类图：

上一篇文章我讲的是dubbo框架设计中Transport层，这篇文章我要讲的是它的上一层Exchange层，也就是信息交换层。官方文档对这一层的解释是封装请求响应模式，同步转异步，以 Request, Response为中心，扩展接口为 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer。

先预警一下，该文篇幅会很长，做好心理准备。Transport层也就是网络传输层，在远程通信中必然会涉及到传输。它在dubbo 的框架设计中也处于倒数第二层，当然最底层是序列化，这个后面介绍。官方文档对Transport层的解释是抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel、Transporter、Client、Se...

服务治理框架中可以大致分为服务通信和服务管理两个部分，前面我先讲到有关注册中心的内容，也就是服务管理，当然dubbo的服务管理还包括监控中心、 telnet 命令，它们起到的是人工的服务管理作用，这个后续再介绍。接下来我要讲解的就是跟服务通信有关的部分，也就是远程通讯模块。我在《dubbo源码解析（一）Hello,Dubbo...

这篇文章是讲解注册中心的最后一篇文章。这篇文章讲的是dubbo的注册中心用zookeeper来实现。这种实现注册中心的方法也是dubbo推荐的方法。为了能更加理解zookeeper在dubbo中的应用，接下来我先简单的介绍一下zookeeper。

Redis是一个key-value存储系统，交换数据非常快，redis以内存作为数据存储的介质，所以读写数据的效率极高，远远超过数据库。redis支持丰富的数据类型，dubbo就利用了redis的value支持map的数据类型。redis的key为服务名称和服务的类型。map中的key为URL地址，map中的value为过期时间，用于判断脏数据，脏数据由监控中心...

这是dubbo实现注册中心的第二种方式，也是dubbo的demo模块中用的注册中心实现方式。multicast其实是用到了MulticastSocket来实现的。

dubbo内置的注册中心实现方式有四种，这是第一种，也是dubbo默认的注册中心实现方式。我们可以从上篇文章中看到RegistryFactory接口的@SPI默认值是dubbo。

服务治理框架中可以大致分为服务通信和服务管理两个部分，服务管理可以分为服务注册、服务发现以及服务被热加工介入，服务提供者Provider会往注册中心注册服务，而消费者Consumer会从注册中心中订阅相关的服务，并不会订阅全部的服务。

前一篇文章《dubbo源码解析（一）Hello,Dubbo》是对dubbo整个项目大体的介绍，而从这篇文章开始，我将会从源码来解读dubbo再各个模块的实现原理以及特点，由于全部由截图的方式去解读源码会导致文章很杂乱，所以我只会放部分截图，全部的解读会同步更新在我github上fork的dubbo源码中，同时我也会在文章一些关键的地方加...

文档简短形象的对单一应用架构、垂直应用架构、分布式服务架构、流动计算架构做了一个对比，可以很明白的看出这四个架构所适用的场景，因为业务需求越来越复杂，才会有这一系列的演变。