在网络传输中只将数据看作是原始的字节序列。然则，我们的应用程序需要把这些字节序列组成有意义的信息。将应用程序的数据转换为网络格式，以及将网络格式转换为应用程序的数据的组件分别叫作编码器和解码器，同时具有这两种功能的单一组件叫作编解码器。1、粘包&拆包基于前面的分析我们知道dubbo的远程调用是基于Netty这个Nio框架进行基于TCP/IP的Socket通信。TCP是一个“流”协议，所谓流就是没有界限的一串数据。可以想像一个河里的流水是连成一片的，其间没有分界线。TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分，所以在业务上认为，一个完整的包可能会被
序列化：把对象转换为字节序列的过程称为对象的序列化。反序列化：把字节序列恢复为对象的过程称为对象的反序列化。Dubbo是Alibaba开源的分布式服务框架远程调用框架，现在已捐赠给apache软件基本会。因此dubbo调用是需要跨JVM，需要进行网络通信。这就需要使用到序列化与反序列化。在dubbo中定义了ObjectInput、ObjectOutput与Serialization来进行数据的序列化与反序列化。1、Serialization定义下面我们来看一下Serialization的接口定义：@SPI("hessian2")publicinterfaceSerializ
任何框架或组件，总会有核心领域模型，比如：Spring的Bean，Struts的Action，Napoli的Queue。对于Dubbo来说它的核心就是Service(服务接口)，而Service不管是provider暴露服务，还是consumer引用服务。它都是一个非常重要的概念，我们来看一下Dubbo的核心领域模型：Protocol是服务域，它是Invoker暴露和引用的主功能入口，它负责Invoker的生命周期管理。Invoker是实体域，它是Dubbo的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地的实现，也可能是一个远程的实
在前面一篇博客中分享了dubbo在网络通信当中的consumer的发送以及接收原理。通过集群容错最终选择一个合适的Invoke通过netty直联调用provider的服务。众所周知，netty是基于JavaNio的Reactor模型的异步网络通信框架，所以dubbo在consumer端把异步变成了同步。大概总结了consumer的发送与接收原理，下面我们来讨论一下dubbo网络通信当中provider的接收与发送原理。这样就完成了dubbo架构图里面的consumer调用provider的过程.本次是分析dubbo的provider的接收与发送原理，讨论包括以下几个点：provider接收co
在前面的文章中,我们分析了dubbo从provider进行服务暴露,然后把服务信息注册到注册中心上面解耦consumer与provider的调用。consumer通过javassist创建代理对象引用远程服务。当通过代理对象调用远程服务的时候，讲到进行真正调用的时候dubbo抽象出集群容错(Cluster、Directory、Router、LoadBalance)从服务多个暴露方选取出一个合适的Invoke来进行调用。dubbo默认是通过FailoverClusterInvoker从多个Invoke中选择出一个Invoke实例InvokerWrapper来进行远程调用。本次分析主要包括以下4个
dubbo做为RPC框架，需要进行跨JVM通信，要保证高性、稳定的进行远程通信。dubbo底层通信选择了netty这个nio框架做为默认的网络通信框架并且通过自定义协议进行通信。dubbo支持以下网络通信框架：Netty(默认)MinaGrizzly1、netty简介在网络编码领悟，Netty是Java的卓越框架。它封装了JavaNIO操作的复杂性，使得开发者能够使用其提供的简易API就能够开发出高效的网络程序。首先我们来看一下netty里面的关键特性：分类Netty的特性设计统一的API，支持多种传输类型，阻塞和非阻塞的简单简单而强大的线程模型真正的无连接数据报套接字支持链接逻辑组件以支持复
在之前的文章我们分析了dubbo的服务治理，也就是在consumer端在进行服务引用的时候。consumer首先会根据配置Protocol(协议)创建Invoke调用对象，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。然后再使用ProxyFactory接口创建代理对象，进行远程调用。创建的代理对象为InvokeInvocationHandler，然后它组合了一个MockClusterInvoker对象。dubbo里面的服务治理就是通过它来完成的。这个里面就涉及到服务治理也就是集群容错。首先通过MockClusterInvo
在之前的dubbo源码分析中我们分析了dubbo的服务暴露。provider把需要暴露的服务地址信息注册到注册中心(比如:zookeeper)，然后把通过javanio框架netty以socket的方式把远程服务暴露给consumer调用，并且订阅注解中心，当注册中心发生变化的时候Inovke调用就会改变。当consumer需要引用服务的时候通过javassist创建代理对象，获取到代理对象InvokerInvocationHandler，而它组合了一个MockClusterInvoker。dubbo通过这个对象进行服务治理，也就是之前分析的集群容错源码的分析。我们再来看一下集群容错的架构图：
在分布式服务当中监控服务的各项指标至关重要，而dubbo也提供了一个简单的监控中心(SimpleMonito)。SimpleMonitor挂掉不会影响到Consumer和Provider之间的调用，所以用于生产环境不会有风险。并且配置好了之后可以结合admin管理后台使用，可以清晰的看到服务的访问记录、成功次数、失败次数等…SimpleMonitor采用磁盘存储统计信息，请注意安装机器的磁盘限制，如果要集群，建议用mount共享磁盘。1、监控中心我们先来看一下dubbo监控中心的配置文件：#1dubbo.container=log4j,spring,registry,jetty#2dubbo.
在集中式环境中服务的机器台只有一台，这样对于服务不仅存在服务单点故障问题而且还存在流量问题。为了解决这个问题，就引入的分布式与集群概念。分布式：一个业务分拆多个子业务，部署在不同的服务器上集群：同一个业务，部署在多个服务器上当请求来临时，如何从多个服务器中，选择一个有效、合适的服务器，这个集群所需要面对一问题。所以在集群里面就引申出负载均衡（LoadBalance），高可用（HA），路由（Route）等概念。我们来看一下dubbo在进行服务调用的时候是如何处理的。这张集群容错包含以下几个角色：Invoker：对Provider(服务提供者)的一个可调用Service接口的抽象，Invoker封
在集中式环境中服务的机器台只有一台，这样对于服务不仅存在服务单点故障问题而且还存在流量问题。为了解决这个问题，就引入的分布式与集群概念。分布式：一个业务分拆多个子业务，部署在不同的服务器上集群：同一个业务，部署在多个服务器上1、dubbo服务治理当请求来临时，如何从多个服务器中，选择一个有效、合适的服务器，这个集群所需要面对一问题。所以在集群里面就引申出负载均衡（LoadBalance），高可用（HA），路由（Route）等概念。我们来看一下dubbo在进行服务调用的时候是如何处理的。这张集群容错包含以下几个角色：Invoker：对Provider(服务提供者)的一个可调用Service接口的
在集中式环境中服务的机器台只有一台，这样对于服务不仅存在服务单点故障问题而且还存在流量问题。为了解决这个问题，就引入的分布式与集群概念。分布式：一个业务分拆多个子业务，部署在不同的服务器上集群：同一个业务，部署在多个服务器上1、dubbo服务治理当请求来临时，如何从多个服务器中，选择一个有效、合适的服务器，这个集群所需要面对一问题。所以在集群里面就引申出负载均衡（LoadBalance），高可用（HA），路由（Route）等概念。我们来看一下dubbo在进行服务调用的时候是如何处理的。这张集群容错包含以下几个角色：Invoker：对Provider(服务提供者)的一个可调用Service接口的
在集中式环境中服务的机器台只有一台，这样对于服务不仅存在服务单点故障问题而且还存在流量问题。为了解决这个问题，就引入的分布式与集群概念。分布式：一个业务分拆多个子业务，部署在不同的服务器上集群：同一个业务，部署在多个服务器上1、dubbo服务治理当请求来临时，如何从多个服务器中，选择一个有效、合适的服务器，这个集群所需要面对一问题。所以在集群里面就引申出负载均衡（LoadBalance），高可用（HA），路由（Route）等概念。我们来看一下dubbo在进行服务调用的时候是如何处理的。这张集群容错包含以下几个角色：Invoker：对Provider(服务提供者)的一个可调用Service接口的
在集中式环境中服务的机器台只有一台，这样对于服务不仅存在服务单点故障问题而且还存在流量问题。为了解决这个问题，就引入的分布式与集群概念。分布式：一个业务分拆多个子业务，部署在不同的服务器上集群：同一个业务，部署在多个服务器上1、dubbo服务治理当请求来临时，如何从多个服务器中，选择一个有效、合适的服务器，这个集群所需要面对一问题。所以在集群里面就引申出负载均衡（LoadBalance），高可用（HA），路由（Route）等概念。我们来看一下dubbo在进行服务调用的时候是如何处理的。这张集群容错包含以下几个角色：Invoker：对Provider(服务提供者)的一个可调用Service接口的
Dubbo是阿里巴巴开源的一个高性能优秀的服务框架，使得应用可通过高性能的RPC实现服务的输入与输出功能。作为一个优秀的框架，至少应该包含以下几个特点：完善的文档活跃的社区良好的扩展性今天主要讨论的主题就是dubbo中良好的扩展性。dubbo的扩展点加载是从JDK标准的SPI(ServiceProviderInterface)扩展点发现加强而来。JDK标准的SPI会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源。如果扩展点加载失败，连扩展点的名称都拿不到了。比如：JDK标准的ScriptEngine，通过getName()获取脚本类型的名称，但如果Ru
在使用dubbo的时候，我们对于远程服务调用是无感知的。当需要调用远程服务的时候我们只需要进行以下配置，就可以像本地调用的方式调用远程服务：<?xmlversion="1.0"encoding="UTF-8"?><beansxmlns="http://www.springframework.org/schema/beans"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:dubbo="http://code.aliba
在前面的文章我们分析了一下dubbo远程服务暴露过程中通过Netty进行Socket服务暴露。使得远程客户端可以访问这个暴露的服务，这个只是解决了访问之前点到点的服务调用。对于分步式环境当中，越来越多的服务我们如何管理并且治理这些服务是一个问题。因此dubbo引入了注册中心这个概念，把服务暴露、服务调用的信息保存到注册中心上面。并且还可以订阅注册中心，实现服务自动发现。因为dubbo远程暴露里面的过程还是比较复杂的，所以我就分为三个文章来讲解dubbo的远程暴露：dubbo远程暴露–Netty暴露服务dubbo远程暴露–Zookeeper连接dubbo远程暴露–Zookeeper注册&
在上一篇文章我们讲解了一下dubbo远程服务暴露过程中通过Netty进行Socket服务暴露。使得远程客户端可以访问这个暴露的服务，这个只是解决了访问之前点到点的服务调用。对于分步式环境当中，越来越多的服务我们如何管理并且治理这些服务是一个问题。因此dubbo引入了注册中心这个概念，把服务暴露、服务调用的信息保存到注册中心上面。并且还可以订阅注册中心，实现服务自动发现。因为dubbo远程暴露里面的过程还是比较复杂的，所以我就分为三个文章来讲解dubbo的远程暴露：dubbo远程暴露–Netty暴露服务dubbo远程暴露–Zookeeper连接dubbo远程暴露–Zookeeper注册&
在上一篇文章我们讲解了一下dubbo服务暴露过程中的本地暴露。它只是一个开胃小菜，主要是为我们后面讲解远程暴露开个头。下面就来分析一下dubbo在远程暴露里面发生了哪些事。因为dubbo远程暴露里面的过程还是比较复杂的，所以我就分为三个文章来讲解dubbo的远程暴露：dubbo远程暴露–Netty暴露服务dubbo远程暴露–Zookeeper连接dubbo远程暴露–Zookeeper注册&订阅这就篇就是分析dubbo服务暴露中通过Netty来暴露服务(当然dubbo还可以通过Mina、Grizzly来暴露服务，默认使用Netty)。1、ServiceConfig#doExportUrl
在上一篇文章我们分析了一下dubbo在服务暴露发生了哪些事，今天我们就来分析一下整个服务暴露中的本地暴露。(PS:其实我感觉本地暴露蛮鸡肋的)。本地暴露需要服务提供方与服务消费方在同一个JVM。下面我们来写一个本地暴露使用的例子：DemoService.javapublicinterfaceDemoService{StringsayHello(Stringname);}DemoServiceImpl.javapublicclassDemoServiceImplimplementsDemoService{publicStringsayHello(Stringname){return"H
dubbo的服务模型是非常简单的，要么是服务提供方(Provider)提供服务，要么是服务消费方(Consumer)消费服务，从dubbo官网的系统架构图就可以看出来。Provider与Consumer通过Registry来解耦合，这一点和Spring有点相似。在Spring中它的核心领域模型是Bean.我们通过配置bean，然后Spring容器获取到需要的对象。不需要关心对象的创建过程，并且我们可以在Spring的Bean的生命周期过程来来定制化对象。在使用dubbo的时候并不需要服务暴露与服务引用的细节。我们只需要在服务端配置：provider-beans.xml<?xmlversi
如果大家看过之前的dubbo内核SPI实现–2.dubbo源码分析之内核SPI实现,有可能还是一头雾水,下面我讲一下dubbo的具体应用。最典型的应用就是Protocol接口。Protocol属于dubbo十层结构中的远程调用层,它封装了RPC调用。以Invocation和Result为中心,其它的扩展接口还包括Invoker和Exporter。Protocol是服务域,它是Invoker暴露和引用的主功能入口,它负责Invoker的生命周期管理。Invoker是实体域,它是Dubbo的核心模型,其它模型都向它靠扰,或转换成它.它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地
Spring框架从2.0版本开始,提供了基于Schema风格的SpringXML格式用来定义bean的扩展机制。引入Schema-basedXML是为了对Traditional的XML配置形式进行简化。通过Schema的定义，把一些原本需要通过几个bean的定义或者复杂的bean的组合定义的配置形式，用另外一种简单而可读的配置形式呈现出来。Schema-basedXML由三部分构成，我们由一幅图说明：namespace——拥有很明确的逻辑分类element——拥有很明确的过程语义attributes——拥有很简明的配置选项例如，<mvc:annotation-driven/>这段配
我们运行的Java代码，一般都是编译之后的字节码。Dubbo为了实现基于SPI思想的扩展特性，可以灵活的添加额外的功能。对于SPI接口需要能够动态生成，这样就需要在运行的时候去编译加载这个设配类的代码。下面我们就是来了解下Dubbo的动态编译。我们首先来看一下Compile的类图。Compile接口定义：@SPI("javassist")publicinterfaceCompiler{/***Compilejavasourcecode.**@paramcodeJavasourcecode*@paramclassLoaderTODO*@returnCompiledclass*
Dubbo采用微内核+插件体系，使得设计优雅，扩展性强。那所谓的微内核+插件体系是如何实现的呢！大家是否熟悉spi(serviceproviderinterface)机制，即我们定义了服务接口标准，让厂商去实现（如果不了解spi的请谷歌百度下）,jdk通过ServiceLoader类实现spi机制的服务查找功能–Java规范SPI。1、为什么不使用JDKSPI在dubbo中它实现了一套自己的SPI机制。JDK标准的SPI会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源.增加了对扩展点IoC和AOP的支持，一个扩展点可以直接setter注入其它扩展点。2
在之前的文章中介绍了Dubbo的出现背景以及使用方式，下面我们通过源码的方式来分析一下Dubbo的架构。1、准备在分析探索Dubbo架构原理之前，我们需要准备一下环境，用于后面我们来分析dubbo的架构。1.1ZookeeperDubbo使用Zookeeper为注册中心。所以需要在本地启动zookeeper，作为Dubbo的注册中心。启动Zookeeper服务：用于dubbo的注册中心。启动ZookeeperInspector:它是Zookeeper服务信息查看工具。可以查看zookeeper上面的节点信息。1.2Dubbo源代码dubbo源代码的下载地址为:alibaba/dubbo.通过d
Dubbo从2.7.0版本开始正式支持配置中心，在服务自省架构中也依赖配置中心完成ServiceID与ServiceName的映射。配置中心在Dubbo中主要承担两个职责：外部化配置：目的之一是实现配置的集中式管理，目前已经有很多成熟的专业配置管理系统（例如，携程开源的Apollo、阿里开源的Nacos等），Dubbo配置中心的目的不是”重复造轮子”，而是保证Dubbo能与这些成熟的配置管理系统一起正常工作；服务治理：负责服务治理规则的存储与通知。Dubbo可以同时支持多种配置来源。在Dubbo初始化过程中，会从多个来源获取配置，并按照固定的优先级将这些配置整合起来，实现高优先级的配置覆盖低优
上一章，我介绍了Dubbo的服务自省架构中的元数据方案，整个服务自省架构除了元数据方案还需要服务发布订阅功能的支持。本章，我就来讲解Dubbo中服务实例的发布与订阅功能的具体实现：首先，我会对ServiceDiscovery接口的核心定义进行讲解；然后，我会重点介绍以ZooKeeper为注册中心的ZookeeperServiceDiscovery实现，这其中还会涉及相关事件监听的实现。一、ServiceDiscoveryServiceDiscovery主要封装了针对ServiceInstance的发布和订阅操作，你可以暂时将其理解成一个ServiceInstance的注册中心。ServiceD
在微服务架构中，服务是基本单位，而Dubbo架构中服务的基本单位是Java接口，这种架构上的差别就会带来一系列挑战。从Dubbo2.7.5版本开始，Dubbo引入了服务自省架构，来应对微服务架构带来的挑战。一、注册中心1.1传统架构我们先来回顾一下Dubbo传统架构中最核心的组件：我们知道URL是贯穿整个Dubbo服务注册与发现的核心。ProviderURL注册到ZooKeeper上的大致格式如下：dubbo://192.168.0.100:20880/org.apache.dubbo.demo.DemoService?anyhost=true&application=demo-pro
Dubbo作为一个RPC框架，暴露给用户最基本的功能就是服务发布和服务引用。在上一章，我已经分析了服务发布的核心流程。那么在本章，我就接着深入分析服务引用的核心流程。Dubbo支持两种方式引用远程的服务：服务直连：仅适合在测试场景调试服务时使用；基于注册中心引用：这是生产环境中使用的服务引用方式。一、DubboBootstrap入口在上一章介绍服务发布的时候，我介绍了DubboBootstrap.start()方法的核心流程，其中除了会调用exportServices()方法完成服务发布之外，还会调用referServices()方法完成服务引用。在DubboBootstrap.referSe