前言Docker是大家或多或少都听过的一项技术，或者说你在投简历、刷博客、刷论坛的时候一定都见过。如果您从未听说过或见过一项技术，请百度。Dubbo技术大家应该都听说过。一些公司也可能会在他们的项目中使用Dubbo。这个技术面试应该也属于好玩家。接触过Dubbo之后，你就会对RPC调用了如指掌，同时也会了解很多网络层面的知识点。总之，接下来要开启的Dubbo系列一定会让你受益匪浅。这么浅，大家一起学习吧！之前应该写过很多系列的文章，我把这些文章收录在我的https://github.com/DayuMM2021/Java文章网址里，里面也有很多代码，包括Designpatternexamples，RocketMQ源码分析，Dubbo源码分析，以及后续的大数据分析等。本文主要是带领大家了解Dubbo的源码、功能和架构设计。一般我们在学习一个技术点的时候首先要了解的是这个技术点的来源，它是干什么的，能解决什么痛点，大概的架构和运行流程是怎么样的。不要上来就直接砸各种细节和源码，不然只会把自己搞糊涂。看完这篇文章，什么RPC调用，什么HTTP，这些都不用担心了，但是离完全理解Dubbo还有一点距离，但是只要你继续看我的Dubbo系列文章，那么你就是不同的。这一波，这一波，我已经说清楚了，老手，喜欢跟跟随才不会迷路。RPC与HTTPRPC，RemoteProcedureCall也就是远程过程调用，指的是调用不同地址空间的计算机程序，通常是不同的计算机，RPC是进程间通信的一种形式，因为不同的进程有不同的地址空间。如果它们在同一台主机上，即使物理地址空间相同，它们也有不同的虚拟地址空间。如果在不同的主机上，物理地址空间肯定会不同，虚拟地址空间也不相同。.远程过程调用的对象是本地过程调用。本地过程调用大家应该都不陌生了。您编写了一个简单的Java程序。内部方法调用实际上是对本地过程的调用，而远程过程调用是指在本地调用远程主机上的方法最重要的是远程过程调用。RPC和HTTP，傻傻的不知道RPC和HTTP不是等价的概念。RPC，如上解释，属于完整的远程调用链路，包括：接口规范+序列化反序列化规范+通信协议等，而HTTP只是一种通信协议，属于OSI第七层，不是一个完整的远程调用链接。这是牛（HTTP）和马车（RPC）的对比。为了比较，你需要给牛一个工具，让它变成牛车！HTTP的远程调用基于HTTP的远程调用，HTTP+Restful，有很大的优势。可读性很好。使用这种方案会包含大量的HTTP头信息，而有用信息所占比例很小。这个应该比较麻烦，需要封装各种参数名和参数值。Restful属于一个规范，是一个actions加resources的规范。操作包括GET、POST、PUT、DELETE和资源。网络中的一切都属于资源。该规范是对网络中的资源进行各种操作，资源是Restful架构或者整个网络处理的核心。RPCRPC的优点是有用信息占比很高，效率也很高，而且调用起来非常简单，就像调用本地服务一样，没有任何感知，我们也不需要关心网络传输或者通信的问题，HTTP其实也是RPC的一种实现方式。RPC就像一种地方方言。它只需要在内部知道。双方都需要懂方言，否则无法沟通。HTTP就像普通话，基本都能看懂。RPC框架就是实现和小助手一样的功能。目的是让我们使用远程调用像本地调用一样简单方便，能够解决一些远程调用可能出现的各种问题，让我们的开发者无感知、无安慰地进行开发。很好，我也很好，快乐无忧。RPC流程服务A调用服务B的过程在开发者的感知中就好像是内部调用一样。RPC要求将被调用方法的接口放在调用者中。调用方只要调用这些接口，就相当于调用了被叫方。实际方法很简单，调用者也可以像调用内部接口一样调用远程方法，不需要封装参数名和参数值等操作。服务A调用服务首先，调用者调用接口，必须为接口构造一个假的实现，显然是使用了动态代理，这样调用者的调用就被动态代理接受了。动态代理收到调用后，想的是调用远程的实际实现，包括识别要调用的远程方法的IP和端口号，序列化调用方法的入参，发送向远程方法请求，接收远程服务向调用者请求后的步骤包括反序列化每个调用参数，定位实际调用方法，然后输入参数调用，根据调用路径返回调用结果。我简单的做了一张图，大家就明白了：Dubbo来源众多。其实我们在使用这个技术的时候，可能是因为项目需要，所以才使用的。不过，至于为什么要用到这个技术，可能我不是很了解，但其实了解这个技术的起源和背景知识，对于理解一个技术还是有帮助的。那么，dubbo是如何被提上日程的呢？在互联网发展的过程中，在过去，我们只需要一台服务器，把所有的程序打包。但随着流量的增加，传统的垂直应用架构已经无法应对，于是架构进化。渐渐地，应用之间的关系变得非常复杂，会出现以下问题：1、服务越来越多，服务URL配置管理变得非常困难，单点压力也越来越大。2、服务依赖越来越复杂，甚至分不清哪个应用先启动哪个应用。3、服务调用量越来越大，服务的容量问题会暴露出来。该服务需要多少台机器，什么时候应该添加机器？为了解决这个问题由于架构演化产生的几个问题，dubbo诞生了。当然，dubbo并不是唯一解决这个问题的技术。从上面的Dubbo服务治理图可以看出，Duboo很好的解决了上面的一些问题。所以，当你的系统架构发展到这个阶段，就需要考虑使用Dubbo了。Dubbo架构首先我们来看一下官网发布的Dubbo架构图：节点角色描述节点角色描述Provider暴露服务提供者Consumer调用远程服务的服务消费者Registry服务注册和发现的注册中心Monitor的服务调用次数统计调用时间监控中心容器服务运行容器以上就是Dubbo的主要作用。接下来说一下整体流程。其实Dubbo的架构也很简单。为什么这么说？有没有发现，它其实很像production的provider-consumer模型，只是在这个模型上加了一个注册中心和一个监控中心，用来管理provider提供的URL，管理整个流程。首先服务提供者Provider启动，然后向注册中心注册自己可以提供的服务，服务消费者Consumer开始向注册中心订阅自己需要调用的服务，然后注册中心会提供相应的meta信息给消费者，然后消费者会通过Loadbalancing选择一个Provider直接调用。如果服务提供者的元数据发生变化，注册中心会将变化信息推送给服务消费者。服务提供者和消费者都会在内存中记录调用的次数和时间，然后定期将统计数据发送给监控中心进行监控。这样整个过程应该就很清楚了！Dubbo分层架构我们看一下Dubbo的层，它来自于网络。我们来看看它的架构设计：大层分为三层，分别是Business层、RPC传输层、Remoting层。根据设计，也可以分为API层和SPI层。采用微内核设计+SPI扩展，可以定制扩展有特殊需求的访问方式，进行定制化二次开发。下面我们详细看一下每一层的作用。不要死记硬背，适度理解即可。Service，服务接口层，与实际的逻辑业务相关。根据服务消费者和服务提供者的业务设计，实现相应的接口Config。外部配置层的接口主要围绕ServiceConfig和ReferenceConfig来初始化配置信息。Register，服务注册层，封装服务注册和发现，以服务URL为中心，扩展接口为RegistryFactory、Registry、RegistryService，可以没有服务注册中心，服务提供者直接暴露服务Proxy，代理层，服务提供者或消费者都会生成一个代理类使服务接口透明化，代理层进行远程调用并返回结果。Cluster，封装了多个提供者的路由和负载均衡，并连接到注册中心，以Invoker为中心，将多个服务提供者合二为一，实现透明的服务消费。Monitor，监控层，负责监控统计RPC的调用时间和次数，以Statistics为中心。远程调用层Portocol主要封装了以Invocation和Result为中心的RPC调用，扩展接口有Protocol、Invoker和Exporter。Protocol是服务接口，负责Invoker的生命周期管理；Invoker是属于Dubbo核心模块的一个实体，代表一个可执行文件。Exchange，信息交换层，用于封装请求响应模型，从同步到异步，以Request和Response为中心。Transport，网络传输层，以Message为核心，抽象为Mina和Netty，抽象出网络传输的统一接口。Serialize，序列化层，将数据序列化为二进制流，当然也可以反序列化。扩展接口是序列化的。Dubbo服务暴露服务暴露就是将要提供的服务暴露出来。想一想，一个用户服务模块需要对外提供一个注册新用户的功能，那你的服务就必须要暴露出来，不然怎么调用你的对外接口呢？服务！这个意思大家先明白，我就把这个单独拿出来给大家看下Dubbo的源码。Dubbo服务引用是指使用@Reference。用过Dubbo的人应该对这个注解不陌生。订阅ReferenceConfig中的消息。这个消息订阅是引用注册中心的调用，同时也创建了一个netty。客户端用于交互。Dubbo服务调用invoker代理对象（即自动注入的服务）。在Dubbo中，客户端调用的服务是一个经过多次代理的对象，有一个过滤代理。作用是利用dubbo的容错能力，通过负载均衡选择使用注册中心的哪个服务，最后在DubboInvoker对象中进行远程调用。该对象获取对应的通道。通过模拟这个接口输入的参数，通过request进行请求，得到结果后，解析并返回结果。SPI机制SPI（ServiceProviderInterface）的全称是JDK内置的一种服务提供者发现机制。目前很多框架都用它来做服务扩展发现。简单的说，就是一种动态替换发现机制。例如，有一个接口，你想在运行时为它动态添加实现。您只需要添加一个实现即可。那为什么dubbo不使用jdk的SPI，而是选择自己模仿实现一个呢！我也会单独开一个SPI来解释这些问题。总之，看完这篇文章，你应该了解了RPC、HTTP、Dubbo技术点之间的关系，以及Dubbo的总体架构。有几个，我就挑出上面没有详细介绍的几点。并且会把源码带来给大家分析。你说看完了还能Dubbo。面试怕问到Dubbo吗？
