【Dubbo 详解】

Dubbo

Dubbo常见面试问题

互联网架构演变趋势

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。

单一应用架构

单体架构也称之为单体系统或者是单体应用。就是一种把系统中所有的功能、模块耦合在一个应用中的架构方式，一般只操作一个数据库。代表技术： Struts2、 SpringMVC、 Spring、 MyBatis等。
特点：打包成一个独立的单元(导成一个唯一的 jar 包或者是 war 包)。会以一个进程的方式来运行
优点：项目易于管理、部署简单
缺点：测试成本高、可伸缩性差、可靠性差、迭代困难、跨语言程度差、团队协作难（有任何一个模块出现问题，整个应用就不能用了）

RPC架构

远程过程调用（比如在上海的计算机A要调用在北京的计算机B的服务）。（本地过程调用就是计算机调用本地的服务）他一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。代表技术： Thrift（Facebook 开发的系统内部各语言之间协调通讯的 RPC 框架，带有强大的代码生成引擎，支持跨语言、多平台调用的。Apache 官网有资料）、 Hessian（基于HTTP协议的 RPC 框架，提供RMI 功能，且采用二进制协议的轻量级框架）等等。
特点：应用直接调用服务，服务之间是隔离的。

缺点：服务过多时，管理成本高昂。服务治理，服务注册、发现，服务容错，服务跟踪，服务网关，IP暴露等都是此架构无法避免的问题。（因为服务之间都是隔离的没办法互相发现调用等等）

SOA架构

SOA(Service oriented Architecture):面向服务架构
ESB(Enterparise Service Bus):企业服务总线，服务中介。主要是提供了一个服务与服务之间的交互。 ESB 包含的功能如：负载均衡，流量控制，加密处理，服务的监控，异常处理，监控告急等等。代表技术： Mule（Java为核心的消息框架和整合平台，提供服务中介、数据转换、消息路由、服务创建和托管等功能。不是开源的技术，是付费产品。）、 WSO2（开源的服务总线，提供了 SOA 基础设施的搭建，内置数据服务支持，服务角色管理等功能）。

微服务架构：

微服务是一种架构风格。一个大型的复杂软件应用，由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好的完成该任务。微服务就是一个轻量级的服务治理方案。对比 SOA 架构，使用注册中心代替 ESB 服务总线。注册中心相比服务总线来说，更加轻量级。代表技术： SpringCloud、 Dubbo等等
架构风格：项目的一种设计模式。 常见的架构风格有：
客户端与服务端的：在使用之前需要安装客户端的应用。如：QQ，网络游戏等。
基于组件模型的架构： 如：EJB（Session Bean 实现业务逻辑的、Entity Bean 域模型、Manager Driven Bean 驱动管理模型等）
分层架构（单体架构）：典型的就是 MVC 架构
面向服务架构：将系统拆分为若干服务，业务功能基于服务实现，服务可独立配置、维护、运行，且多服务有统一的管理平台（ESB、 注册中心）
1、特点：
系统是由多个服务构成，每个服务可以单独独立部署，每个服务之间是松耦合的。服务内部是高内聚的，外部是低耦合的。高内聚就是每个服务只关注完成一个功能。低耦合就是服务之间没有直接关联（比如上面的用户服务，该服务只是用户服务的所有的功能，这就是高内聚；与订单服务和物流服务没有关系，这就是松耦合）
2、优点：
测试容易：服务高内聚低耦合，每个服务可以独立测试。
可伸缩性强：服务相对独立，可随时增删服务实现系统服务变化（如上图增加购物车服务等），可针对某服务独立水平扩展可靠性强：服务出现问题，受影响的位置是当前服务，不会影响其他服务。应用健壮性有更好的保证。
跨语言程度会更加灵活：可针对服务特性使用不同的语言开发（如上图，不同的服务可以用不同的语言开发），尽可能发挥出每种语言的特性。团队协作容易：团队专注自主研发的服务，对其他服务的了解可局限在服务的调用上。
系统迭代容易：当服务发生变更时，只需针对单一服务进行系统升级迭代
3、缺点：
运维成本过高，部署数量较多：服务过多导致运维成本成倍提升。
接口兼容多版本（比如用户服务升级到了3.0的版本，那么购物车服务也要去兼容用户服务的3.0的版本）（在实际开发中，需要在父类 POM.xml文件中更改已经升级了的对应的服务的版本号如下，如果shop对应的服务版本改为了2.4.5，也就代表着shop服务包括父的POM.xml,以及各个子模块的POM.xml文件的版本都要更改为2.4.5，另外其他服务中的shop的版本也要更改为2.4.5如下）：因服务可独立升级迭代，所以会导致接口版本过多。

<windranger.shop.version>2.4.5</windranger.shop.version>

分布式系统的复杂性：系统分部，导致通讯成本提升，系统复杂度提升。
分布式事务：分布式系统会引出分布式事务的出现，现在有很多的分布式事务解决方案，分布式事务不是不可解决的，这不会影响微服务架构的应用。

RPC基于RMI的简单实现

RPC基本概念
RPC协议(Remote Procedure Call Protocol)
远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。
RPC框架
在单机时代一台电脑运行多个进程，进程之间无法通讯，显然这会浪费很多资源，因此后来出现IPC(Inter-process communication：单机中运行的进程之间的相互通信)，这样就能允许进程之间进行通讯，比如在一台计算机中的A进程写了一个吃饭的方法，那在以前如果在B进程中也要有一个吃饭的方法，必须要在B进程中进行创建，但有了RPC后B只需要调用A进程的程序即可完成，再到后来网络时代的出现， 大家电脑都连起来，这时可不可以调用其他电脑上的进程呢，当然可以，这样RPC框架就出现了。严格意义上来讲：Unix的生态系统中RPC可以在同一台电脑上不同进程进行，也可以在不同电脑上进行；而在windows里面同一台电脑上不同进程间的通讯还可以采用LPC(本地访问)。综上：RPC或LPC是上层建筑，IPC是底层基础。

RPC框架有很多：比如 JAVA RMI、 Thrift、 Dubbo、 grpc等。

RPC与HTTP、TCP／UDP、Socket的区别

1、TCP/UDP: 都是传输协议，主要区别是tcp协议连接需要3次握手，断开需要四次挥手，是通过流来传输的，就是确定连接后，一直发送信息，传完后断开。udp不需要进行连接，直接把信息封装成多个报文，直接发送。所以udp的速度更快写，但是不保证数据的完整性。

2、Http：超文本传输协议是一种应用层协议，建立在TCP协议之上

3、Socket：是在应用程序层面上对TCP/IP协议的封装和应用。其实是一个调用接口，方便程序员使用TCP/IP协议栈而已。程序员通过socket来使用tcp/ip协议。但是socket并不是一定要使用tcp/ip协议，Socket编程接口在设计的时候，就希望也能适应其他的网络协议。

4、RPC是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。 所以RPC的实现可以通过不同的协议去实现比如可以使http、RMI等

RPC的运行流程

首先，要解决通讯的问题，主要是通过在客户端和服务器之间建立TCP连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。
第二，要解决寻址的问题，也就是说，A服务器上的应用怎么告诉底层的RPC框架，如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称名称是什么，这样才能完成调用。比如基于Web服务协议栈的RPC，就要提供一个endpoint URI，或者是从UDDI(一种目录服务，通过该目录服务进行服务注册与搜索)服务上查找。如果是RMI调用的话，还需要一个RMI Registry来注册服务的地址。
第三，当A服务器上的应用发起远程过程调用时，方法的参数需要通过底层的网络协议如TCP传递到B服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，也就是序列化（Serialize）或编组
（marshal），通过寻址和传输将序列化的二进制发送给B服务器。

第四，B服务器收到请求后，需要对参数进行反序列化（序列化的逆操作），恢复为内存中的表达方式，然后找到对应的方法（寻址的一部分）进行本地调用，然后得到返回值。

第五，返回值还要发送回服务器A上的应用，也要经过序列化的方式发送，服务器A接到后，再反序列化，恢复为内存中的表达方式，交给A服务器上的应用

JAVAEE里面的stub是为屏蔽客户调用远程主机上的对象，必须提供某种方式来模拟本地对象,这种本地对象称为**存根(stub),**存根负责接收本地方法调用,并将它们委派给各自的具体实现对象

Skeleton：服务器的骨架

为什么需要RPC

论复杂度，RPC框架肯定是高于简单的HTTP接口的。但毋庸置疑，HTTP接口由于受限于HTTP协议，需要带HTTP请求头，导致传输起来效率或者说安全性不如RPC。

现在问题是，遇到怎样的瓶颈了才需要或者说更适合用RPC（比如像阿里这么大的请求并发量，简单的HTTP肯定达不到预期），但问题是大家所在的公司，要有像阿里这么大的量是比较少的，甚至说1/1000的量可能都没有，那我们还需要使用RPC吗？

技术应该不是为了使用新技术而去使用，而应该是旧技术存在某些瓶颈，存在难以支撑或者扩展性越老越差等问题暴露出来之后，用新技术来进行解决。

那RPC最大的优点，或者说它相比简单的HTTP接口，它的优势、更适合它的业务场景是怎样呢？简单的HTTP又哪里不足，哪些场景明显不太适合呢？

http接口是在接口不多、系统与系统交互较少的情况下，解决信息初期常使用的一种通信手段；优点就是简单、直接、开发方便。利用现成的http协议进行传输。但是如果是一个大型的网站，内部子系统较多、接口非常多的情况下，RPC框架的好处就显示出来了，首先就是长链接，不必每次通信都要像http 一样去3次握手什么的，减少了网络开销(这个问题在http2.0已经被解决不再算是问题了)；其次就是RPC框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。第三个来说就是安全性。最后就是流行的服务化架构、服务化治理，RPC框架是一个强力的支撑。

RPC是一种概念，http也是RPC实现的一种方式，用http交互其实就已经属于RPC了。
但是我们为什么要应用RPC层呢？

灵活部署
解耦

系统做大了，肯定是需要做微服务的。 现在我们做电商就是这样，单独有一个订单系统，支付系统，商品系统，用户系统。都是分开部署，单独上线的。

RPC:远程过程调用。RPC的核心并不在于使用什么协议。RPC的目的是让你在本地调用远程的方法，而对你来说这个调用是透明的，你并不知道这个调用的方法是部署哪里。通过RPC能解耦服务，这才是使用RPC的真正目的。RPC的原理主要用到了动态代理模式，至于http协议，只是传输协议而已。

RPC是一个软件结构概念，是构建分布式应用的理论基础。就好比为啥你家可以用到发电厂发出来的电？是因为电是可以传输的。至于用铜线还是用铁丝还是其他种类的导线，也就是用http还是用其他协议的问题了。这个要看什么场景，对性能要求怎么样。比如在java中的最基本的就是RMI技术，它是java原生的应用层分布式技术。我们可以肯定的是在传输性能方面，RMI的性能是优于HTTP的。那为啥很少用到这个技术？那是因为用这个有很多局限性，首先它要保证传输的两端都要要用java实现，且两边需要有相同的对象类型和代理接口，不需要容器，但是加大了编程的难度，在应用内部的各个子系统之间还是会看到 他的身影，比如EJB就是基于rmi技术的。这就与目前的bs架构的软件大相径庭。用http必须要服务端位于http容器里面，这样减少了网络传输方面的开发，只需要关注业务开发即可。

RPC基于RMI(Remote Method Invocation,远程方法调用)的简单实现

Dubbo入门

Dubbo介绍

Dubbo是由阿里巴巴开源的一个高性能、基于Java开源的远程调用框架。正如在许多RPC系统中一样，Dubbo是基于定义服务的概念，指定可以通过参数和返回类型远程调用的方法。在服务器端，服务器实现这个接口，并运行一个Dubbo服务器来处理客户端调用。在客户端，客户机有一个存根，它提供与服务器相同的方法。

Dubbo提供三个核心功能： 基于接口的远程调用、容错和负载均衡，以及服务的自动注册与发现。Dubbo框架广泛的
在阿里巴巴内部使用，以及京东、当当、去哪儿、考拉等都在使用。

节点角色说明：
Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。
Monitor: 统计服务的调用次调和调用时间的监控中心。
Container: 服务运行容器。

调用关系说明：
1、 服务容器负责启动，加载，运行服务提供者。
2、 服务提供者在启动时，向注册中心注册自己提供的服务。
3、服务消费者在启动时，向注册中心订阅自己所需的服务。
4、注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
5、 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
6、 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

常用标签

dubbo:application : 指定应用程序名称
dubbo:registry :指定连接注册中心信息(配置注册中心)(Dubbo的注册中心一般使用zookeeper)
dubbo:protocol : 服务提供方注册服务采用的协议
dubbo:service : 对外暴露服务配置
dubbo:reference : 配置订阅的服务(接口的代理),其他标签及属性用到了去api查询即可。

	<!-- 提供方应用信息，用于应用程序名称 -->
	<dubbo:application name="Coms" />

	<!-- 添加权限过滤器 -->
	<dubbo:provider filter="dubboAuthFilter" />
	
	<!--服务提供方注册服务采用的协议 应用在Dubbo上使用的接口 -->
	<dubbo:protocol name="dubbo" port="20880" />
	
	<!-- 使用zookeeper注册中心暴露服务地址 -->
	<dubbo:registry address="${zookeeper.address}" file="./dubbo-registry/dubbo-registry.properties" check="false" />

	<dubbo:service interface="com.***.IStudentApi"
				   ref="StudentService" />

	<!-- Token验证接口，必须消费的服务，否则无法通过请求的权限验证 -->
	<dubbo:reference interface="com.***.IStudentApi"
		id="remoteStudentApi" check="false" />

Dubbo中RPC协议配置

Dubbo 框架采用RPC协议来对外暴露自己所提供的服务。

Dubbo协议

<!-- 提供方应用信息，用于应用程序名称 -->
	<dubbo:application name="Coms" />

注册中心

注册中心的作用：就是更高效的管理系统的服务：比如服务接口的发布、自动剔除无效的服务、自动恢复服务等
Dubbo中支持四种注册中心： multicast 、zookeeper(推荐) 、redis 、simple

zookeeper注册中心

Zookeeper 是 Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用。

流程说明：
1、服务提供者启动时: 向/dubbo/com.foo.BarService/providers 目录下写入自己的 URL 地址
2、服务消费者启动时: 订阅/dubbo/com.foo.BarService/providers 目录下的提供者 URL 地址。并向/dubbo/com.foo.BarService/consumers 目录下写入自己的 URL 地址
3、监控中心启动时: 订阅 /dubbo/com.foo.BarService 目录下的所有提供者和消费者 URL 地址。

支持以下功能：
当提供者出现断电等异常停机时，注册中心能自动删除提供者信息
当注册中心重启时，能自动恢复注册数据，以及订阅请求
当会话过期时，能自动恢复注册数据，以及订阅请求
当设置<dubbo:registry check=“false” /> 时，记录失败注册和订阅请求，后台定时重试
可通过<dubbo:registry username=“admin” password=“1234” /> 设置 zookeeper 登录信息
可通过<dubbo:registry group=“dubbo” /> 设置 zookeeper 的根节点，不设置将使用无根树
支持 * 号通配符 <dubbo:reference group="" version="" /> ，可订阅服务的所有分组和所有版本的提供者