dubbo

1、应用架构的演进过程

单一应用架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dYeHu8Rt-1639100619742)(img/3.png)]

垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2N21f7hC-1639100619745)(img/4.png)]

分布式服务架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-x8K5CwqN-1639100619748)(img/5.png)]

面向服务架构

流动计算架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VquHdgWB-1639100619749)(img/14.png)]

微服务架构：

	与流动计算架构很相似，除了具备流动计算架构优势外，微服务架构中的微服务可以独立部署，独立发展。且微服务的开发不会限制于任何技术栈。微服务架构的最佳实践是SpringCloud。

2、RPC是什么意思，你怎么理解

介绍

Remote Procedure Call 远程过程调用，是分布式架构的核心，按响应方式分如下两种：
1、同步调用
   客户端调用服务方方法，等待直到服务方返回结果或者超时，再继续自己的操作
2、异步调用
   客户端把消息发送给中间件，不再等待服务端返回，直接继续自己的操作
   
RPC是一种进程间的通信方式
它允许应用程序调用网络上的另一个应用程序中的方法
对于服务的消费者而言，无需了解远程调用的底层细节，是透明的

注意：
RPC并不是一个具体的技术，而是指整个网络远程调用过程。

RPC是一个泛化的概念，严格来说一切远程过程调用手段都属于RPC范畴。各种开发语言都有自己的RPC框架。Java中的RPC框架比较多，广泛使用的有RMI、Hessian、Dubbo等

RPC组件

简单来说一个RPC架构里包含如下4个组件:

1、 客户端(Client)：服务调用者

2、 客户端存根(Client Stub)：存放服务端地址信息，将客户端的请求参数打包成网络消息，再通过网络发送给服务方

3、 服务端存根(Server Stub)：接受客户端发送过来的消息并解包，再调用本地服务

4、 服务端(Server)：服务提供者。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ckzthFvh-1639100619751)(img/15.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-N1NCST0l-1639100619752)(img/16.png)]

3、Dubbo是什么？有什么作用？

   是一款高性能的Java RPC框架。其前身是阿里巴巴公司开源的一个高性能、轻量级的开源Java RPC框架，可以和Spring框架无缝集成。
作用：
提供了三大核心能力：
 1、面向接口的远程方法调用
 2、智能容错和负载均衡
 3、服务自动注册和发现

4、Dubbo的架构以及都有哪些节点角色？

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uwACYckL-1639100619753)(img/17.png)]

节点角色说明：

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

虚线都是异步访问，实线都是同步访问
蓝色虚线:在启动时完成的功能
红色虚线(实线)都是程序运行过程中执行的功能

调用关系说明:

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

5、介绍下Dubbo的负载均衡吧

负载均衡（Load Balance）：其实就是将请求分摊到多个操作单元上进行执行，从而共同完成工作任务。

在集群负载均衡时，Dubbo 提供了多种均衡策略（包括随机random、轮询roundrobin、最少活跃调用数leastactive），缺省为random随机调用。

配置负载均衡策略，既可以在服务提供者一方配置，也可以在服务消费者一方配置，两者取一

• 服务提供者指定负载均衡策略

@Service(loadbalance = "roundrobin")
public class UserServiceImpl implements UserSerivce {
}

• 服务消费者指定负载均衡策略

@Controller
@RequestMapping("/user")
public class UserController {
	@Reference(loadbalance = "roundrobin")
	private UserSerivce userService;
}

6、Dubbo 超时时间设置怎么设置，服务调用超时问题如何解决

Dubbo 超时时间设置有两种方式：
1、服务提供者端设置超时时间，在Dubbo 的用户文档中，推荐如果能在服务端多配置就尽量
多配置，因为服务提供者比消费者更清楚自己提供的服务特性。
2、服务消费者端设置超时时间，如果在消费者端设置了超时时间，以消费者端为主，即优先
级更高。因为服务调用方设置超时时间控制性更灵活。如果消费方超时，服务端线程不会
定制，会产生警告

7、dubbo 在调用服务不成功时，默认是会重试几次？

2次

8、在一个项目里引用多个服务，怎么保证你引用的那个服务就是那个服务

你打开不是有监控中心，你可以看服务后台它注册了多少个服务，消费端有多
少个，提供者有多少个。端口号不同，一个服务启动起来会占用一个端口，而且是一个java
jvm 的进程。如果一台服务分配到两三台机器，会给负载均衡策略的。

9、为什么需要服务治理

• 过多的服务URL配置困难
• 负载均衡分配节点压力过大的情况下也需要部署集群
• 服务依赖混乱，启动顺序不清晰
• 过多服务导致性能指标分析难度较大，需要监控

10、Dubbo的注册中心集群挂掉，发布者和订阅者之间还能通信么？

	可以的，启动dubbo时，消费者会从zookeeper拉取注册的生产者的地址接口等数据，缓存在本地。
每次调用时，按照本地存储的地址进行调用。

	注册中心对等集群，任意一台宕机后，将会切换到另一台；注册中心全部宕机后，服务的提供者和消费者仍能通过本地缓存通讯。服务提供者无状态，任一台 宕机后，不影响使用；服务提供者全部宕机，服务消费者会无法使用，并无限次重连等待服务者恢复；
	挂掉是不要紧的，但前提是你没有增加新的服务，如果你要调用新的服务，则是不能办到的。

11、Dubbo与Spring的关系/项目中怎么用的dubbo

关系：

	Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载

项目中的使用：

Dubbo 是依赖spring 容器的,所以我们在使用的时候是结合spring 用的,我们在配置服务的
提供者的项目中,在Spring 的xml 配置文件中写下面标签注册到注册中心,在dubbo 标签中
配置服务提供者端口号,服务提供名称,注册中心的地址和端口号,下面红色代码不用
说.<dubbo:protocol name="dubbo" port="20887"></dubbo:protocol>(服务提供者端口号)
<dubbo:application name="youlexuan-cart-service"/>
<dubbo:registry address="zookeeper://192.168.177.129:2181"/>
<dubbo:annotation package="com.youlexuan.cart.service.impl" />
调用是通过,在springmvc.xml 文件中配置<!-- 引用dubbo 服务-->
<dubbo:application name="youlexuan-cart-web" />
<dubbo:registry address="zookeeper://192.168.177.129:2181"/>
<dubbo:annotation package="com.youlexuan.cart.controller" />
用dubbo 的好处是：把项目拆分成各个独立的小工程，通过接口调用方式，互相交互数据，
可以单独进行部署和升级，这样就减少了他们直接的耦合性和代码的复用性。还可以针对不
同模块采用不同的部署策略，比如订单模块并发比较高，所以可以把订单模块这个war 包，
单独部署多套，都注册到同一个zookeeper 中。当客户端调用时，zookeeper 会帮忙进行负
载处理。

12、Dubbo使用的是什么通信框架

默认使用NIO Netty框架

13、Dubbo的集群容错方案有哪些？

• Failover Cluster

失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。

• Failfast Cluster

快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。

• Failsafe Cluster

失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作

• Failback Cluster

失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作

Dubbo默认采用的是：Failover Cluster

14、Dubbo在安全机制方面是如何解决？

Dubbo通过Token令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo还提供服务黑白名单，来控制服务所允许的调用

15、Dubbo和Spring Cloud的关系？

	Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而 Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托了 Spirng、Spirng Boot 的优势之上，两个框架在开始目标就不一致，Dubbo 定位服务治理、Spirng Cloud 是一个生态体系。

最大的区别：

	Dubbo底层是使用Netty这样的NIO框架，是基于TCP协议传输的，配合以Hession序列化完成RPC通信。
	而SpringCloud是基于Http协议+Rest接口调用远程过程的通信，相对来说，Http请求会有更大的报文，占的带宽也会更多。但是REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖。

16、dubbo的直连方式

即在服务消费方配置服务提供方的位置信息。
1、xml 配置方式：
<dubbo:reference id="userService" interface="com.kaola.service.UserService"
url="dubbo://localhost:20880" />
2、注解方式：
@Reference(url = "127.0.0.1:20880")
HelloService helloService;

17、dubbo的健壮性体现

1. 监控中心宕掉不影响使用，只是丢失部分采样数据
2. 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
3. 注册中心对等集群，任意一台宕掉后，将自动切换到另一台
4. 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
5. 服务提供者无状态，任意一台宕掉后，不影响使用
6. 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢
复我们前面提到过：注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和
消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。

用，只是丢失部分采样数据
2. 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
3. 注册中心对等集群，任意一台宕掉后，将自动切换到另一台
4. 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
5. 服务提供者无状态，任意一台宕掉后，不影响使用
6. 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢
复我们前面提到过：注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和
消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。