（dubbo和nacos）day63javaEE基础查漏补缺

休哥哥来啦

已于 2022-05-08 23:07:24 修改

阅读量1.5k

点赞数 3

分类专栏：后端框架 spring框架服务架构文章标签： redis 缓存 java dubbo nacos

于 2022-03-06 01:06:51 首次发布

本文链接：https://blog.csdn.net/weixin_44310276/article/details/123304443

版权

后端框架同时被 3 个专栏收录

19 篇文章 0 订阅

订阅专栏

spring框架

13 篇文章 0 订阅

订阅专栏

服务架构

5 篇文章 0 订阅

订阅专栏

dubbo和nacos

1.软件架构的演进过程
2.注册中心挂了不影响调用嘛？
3.注册中心和网关的区别：
4.nginx也可以做网关
5.RPC（remote procedure call）即远程过程调用
6.Nacos、Eureka和Zookeeper：
7. CAP，C 是指强一致性，A是指可用性，P是指分区一致性。
8.dubbo是对socket的封装，通过网络来调用方法。
9.dubbo和ngix的区别和作用:
10.dubbo消费者和提供者通信流程：
11.nacos支持三种部署模式:
12.创建新工程时：注意jdk、字符集、mevan。
13.自定义工具栏。
14.dubbo在springboot中的包注解扫描：
15.添加快捷模板
16.消费者和提供者都需要注册到服务中心。
17.dubbo的相关注解：
18.消费者不需要配置：注册协议，和包注解扫描。
19.为什么消费者要复制service
20.controller注入（声明）service接口，是用来接收，服务层的service。
21.RPC执行流程：rpc是根据接口来调用的。
22.消费者和提供者都有公共的service接口代码，所以把代码抽取出来。
23.文件丢了或误删了，可以通过history来进行恢复。
24.公共接口要不要也部署服务器？
25.分布式项目代码结构图：
26.做领导人必须要学会画饼。
27.dubbo的话，springboot就不能使用idea热部署了。
28.dubbo如何做到热部署？
29.Dubbo的应用场景：
30.序列化：
31.dubbo和redis缓存中，实体类为什么要实现序列化？
32.启动时检查：
32.dubbo中常见的错误：500,no provider没有提供者。
33.服务超时:
34.没有响应的原因：
35.服务超时配置的优先级：
36.服务重试：
36.负载均衡：
37.克隆启动类:
38.dubbo支持四种负载均衡策略:
39.提供者宕机流程：
40.多版本：多版本企业中用的比较少。
41.版本参数都可以抽取到配置文件。
42.总结dubbo开发环境和生产环境配置。

1.软件架构的演进过程

1）单体：

将所有功能代码都部署在一起就可以。

集群的话，所有模块都要部署（可能一两个模块访问量比较大），导致服务器资源浪费。

2）垂直：

前后台系统的分离

都有用户管理模块，有重复模块功能和代码。

3）分布式：

把重复的业务代码，抽离出来。（service和dao），web，三层架构进行分离。

服务多了，调用就非常复杂，比如ip地址变了，那调用改服务的代码都要变

4）soa:

分布式基础上，加入服务注册中心，，web层之间找服务中心进行调用。

依赖：服务注册中心过高。

dubbo(服务注册中心)只能做java项目，不能跨语言跨平台。

5）微服务：

每个服务都是一个可以独立运行的项目，也有一个注册中心，通信是http协议，可以跨语言跨平台.

用户访问系统得有一个网关。

系统开发的技术成本高。

2.注册中心挂了不影响调用嘛？

影响，但是不影响各个独立的服务模块。可以多部署几台注册中心（集群高可用）。

3.注册中心和网关的区别：

系统间关联的系统叫注册中心。用户与系统间的通信叫网关。

4.nginx也可以做网关

5.RPC（remote procedure call）即远程过程调用

A机器通过网络调用B机器的某个方法，这个过程就称为RPC

6.Nacos、Eureka和Zookeeper：

三者都可以实现分布式注册中心框架
Zookeeper（大型map集合）采用 CP 强一致性原则，在网络分区的产生了抖动情况下不允许注册服务实例；节点采用主从结构
Eureka采用 AP 高可用性原则，在网络分区的的情况允许注册服务实例；节点采用去中心化结构

Nacos选择AP和CP混合形式实现注册中心，默认情况下采用 AP 高可用性原则

版权声明：本文为CSDN博主「陆羽泡的茶丶」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/HS_huaishi/article/details/116981432

7. CAP，C 是指强一致性，A是指可用性，P是指分区一致性。

AC是互相冲突的：

这里就拿注册中中间件来说：一个注册中心集群，如果想要保证一致性，那就一定要等集群全部节点的服务注册表信息完全一直了，才能对外提供服务，否则一致性就不能保证。比如说三个节点，其中一个节点的注册表信息发生变化，此时如果没有完成同步，想要保持可用性开放对外服务，则到不同的节点上取到的数据是不一致的，这保证了可用性而违背一致性。如果一定要等集群数据同步完，再提供服务，则在同步期间，一定不能对外提供服务，这就失去了可用性。所以说可用性A和一致性C是相互冲突的。
原文链接：https://blog.csdn.net/star1210644725/article/details/102878301

8.dubbo是对socket的封装，通过网络来调用方法。

9.dubbo和ngix的区别和作用:

dubbo是服务框架，nacos是作为服务框架的注册中心和配置中心。

dubbo可以使用不同的注册中心（如redis，zookeper）。

[Nacos] 主要功能集中在 动态服务发现、服务配置、服务元数据及流量管理。你可以把他简单的理解为是一个**注册中心和配置中心**。

[Dubbo] 是一款高性能、轻量级的开源 Java **服务框架**。 主要功能点在于 RPC 框架。

10.dubbo消费者和提供者通信流程：

1）dubbo，到注册中心找到服务的地址。

2）调用期间，根据地址直接跟提供者，进行通信（不用再到注册中心去寻找）。

3）调用结束时，再通知注册中心，调用完毕。？？？

11.nacos支持三种部署模式:

1、单机模式：可用于测试和单机使用，生产环境切忌使用单机模式（满足不了高可用）

2、集群模式：可用于生产环境，确保高可用

3、多集群模式：可用于多数据中心场景

12.创建新工程时：注意jdk、字符集、mevan。

13.自定义工具栏。

http://t.csdn.cn/mASrt

14.dubbo在springboot中的包注解扫描：

1）@dubboService需要配置包注解扫描。

springboot不能扫描@DubboService的注解：得在yaml中配置。(普通的springboot项目是在启动类上写的注解扫描)

2）@dubboreference不用配置包注解扫描。

注意：@restController，连带着@dubboreference就一起扫描了。

@dubboreference，不是放在类上的注解，是属性上的注解，所以不用声明扫描。

15.添加快捷模板

http://t.csdn.cn/gxENG

sboot—springboot的启动类main方法的快捷键。

16.消费者和提供者都需要注册到服务中心。

注册完成之后，根据包名类名进行rpc通信。

注意：提供者和消费者的包名和接口名字必须一致。

17.dubbo的相关注解：

@DubboReference(loadbalance = "roundrobin",version = "1.0"，timeout = 5000,retries = 0)
创建代理对象，连接nacos，
负载均衡策略loadbalance，
多版本version，
局部超时时间timeout，
重试次数retries。

@DubboService//1.创建对象交给ioc容器，2.将服务注册到nacos中

18.消费者不需要配置：注册协议，和包注解扫描。

19.为什么消费者要复制service

为了让消费者需求与提供者提供一致。

20.controller注入（声明）service接口，是用来接收，服务层的service。

21.RPC执行流程：rpc是根据接口来调用的。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sWyQzPEU-1646499698776)(../../../A_%E9%97%AE%E9%A2%98%E7%AC%94%E8%AE%B0%E5%92%8C%E5%A4%8D%E4%B9%A0%E8%B5%84%E6%96%99/3.Java%E5%A4%8D%E4%B9%A0md%E6%96%87%E6%A1%A3/%E9%97%AE%E9%A2%98_md/%E9%97%AE%E9%A2%98.assets/1646495682060.png)]

22.消费者和提供者都有公共的service接口代码，所以把代码抽取出来。

23.文件丢了或误删了，可以通过history来进行恢复。

24.公共接口要不要也部署服务器？

不用，那万一公共接口挂了呢，还得集群啥的浪费资源。

25.分布式项目代码结构图：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-o173bmJz-1646499698777)(../../../A_%E9%97%AE%E9%A2%98%E7%AC%94%E8%AE%B0%E5%92%8C%E5%A4%8D%E4%B9%A0%E8%B5%84%E6%96%99/3.Java%E5%A4%8D%E4%B9%A0md%E6%96%87%E6%A1%A3/%E9%97%AE%E9%A2%98_md/%E9%97%AE%E9%A2%98.assets/1646478903393.png)]

26.做领导人必须要学会画饼。

27.dubbo的话，springboot就不能使用idea热部署了。

28.dubbo如何做到热部署？

Dubbo同一服务可以部署多份实例而形成负载均衡集群，可以使用Dubbo服务接口的版本号功能和Dubbo服务的优雅停机功能，可以达到服务的优雅热部署

29.Dubbo的应用场景：

1)序列化

2)启动时检查

3)服务超时

4)服务重试

5)负载均衡

6)多版本

30.序列化：

dubbo底层是通过网络传输数据的，所以传输对象必须要实现序列接口。

31.dubbo和redis缓存中，实体类为什么要实现序列化？

要保存对象的状态，比如user对象中，被赋予的实例变量（name,age的值）。

1）每个保存在堆（Heap）中的对象都有相应的状态（state），即实例变量（instance ariable）

2）序列化：保存的不仅仅是保存对象的实例变量的值，JVM还要保存一些小量信息，比如类的类型等以便恢复原来的对象。

cause: java.lang.IllegalStateException: Serialized class com.itheima.domain.User must implement java.io.Serializable
报错：需要序列化。

32.启动时检查：

启动时检查，配置在服务消费者一方，用于服务消费者在启动的时候主动检查注册中心或者服务提供者是否准备好提供服务

注意：开发阶段，提供者比消费者启动慢（提供者需要连接数据库，redis啥的，启动比较慢），消费者经常启动失败。

32.dubbo中常见的错误：500,no provider没有提供者。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1g1lZ42s-1646499698777)(../../../A_%E9%97%AE%E9%A2%98%E7%AC%94%E8%AE%B0%E5%92%8C%E5%A4%8D%E4%B9%A0%E8%B5%84%E6%96%99/3.Java%E5%A4%8D%E4%B9%A0md%E6%96%87%E6%A1%A3/%E9%97%AE%E9%A2%98_md/%E9%97%AE%E9%A2%98.assets/1646480786569.png)]

开发环境：关闭启动时检查：消费者：关闭检查接口，关闭注册中心。

生产环境：打开检查。

33.服务超时:

如果消费者访问该接口，却一直没有响应。消费者不能一直等待，这样用户体验太差。

所以有一个超时响应时间，dubbo默认1秒，如果超过这个时间，服务无法作出反应，直接终止线程

34.没有响应的原因：

1）提供者挂了。

2）查询数据库啥的时间比较长。

3）服务有异常。

超时时间的设置：要按实际情况来调整超时时间。

35.服务超时配置的优先级：

局部>全局异常（消费者>提供者）

全局异常的局限性：服务挂了，还得等全局时间5秒才能返回错误。

访问某个有异常的service，还得等全局时间5秒才能返回错误。应该单独设置超时时间，有错误立刻返回。

局部配置（细粒度）

开发环境：关闭启动时检查：消费者：关闭检查接口，关闭注册中心。

生产环境：打开检查。

36.服务重试：

restris（重试）:请求失败，可能是网络波动，再自动试几次。

默认：1次主动发送，2次重试。

开发环境：应该设置为0次，因为本地没有网络波动。

36.负载均衡：

在高并发情况下，一个服务往往需要以集群的形式对外工作。请求到底应该由哪一个服务提供者去处理就成了个问题，这个时候就需要配置对应的负载均衡策略了。

37.克隆启动类:

搭建第二个提供者：不需要改代码，只需要改启动类配置就行了

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-K01mWKf5-1646499698777)(../../../A_%E9%97%AE%E9%A2%98%E7%AC%94%E8%AE%B0%E5%92%8C%E5%A4%8D%E4%B9%A0%E8%B5%84%E6%96%99/3.Java%E5%A4%8D%E4%B9%A0md%E6%96%87%E6%A1%A3/%E9%97%AE%E9%A2%98_md/%E9%97%AE%E9%A2%98.assets/1646497735790.png)]

38.dubbo支持四种负载均衡策略:

random：按权重随机选择，这是默认值。
roundrobin：按权重轮询选择。
leastactive：最少活跃调用数，相同活跃数的随机选择。（谁不忙找谁。）
consistenthash：一致性Hash，相同参数的请求总是发到同一提供者。（当url（参数啥的）改变了，就会改变hash值）

39.提供者宕机流程：

某个提供者服务器挂了，先通知服务中心，服务中心排除掉之后能，通知消费者

有一个报错，好像就都挂了。

40.多版本：多版本企业中用的比较少。

当项目出现新功能时，会让一部分用户先使用新功能，用户反馈没问题时，再将所有用户迁移到新功能

可以测试和正式服务同时运营。尝鲜功能，ow实验模式。就是多版本。

测试完毕后可以很快的去切换服务，之前测试的版本就成了正式版本。

41.版本参数都可以抽取到配置文件。

42.总结dubbo开发环境和生产环境配置。

	开发环境	生产环境
启动时检查	消费者：关闭检查接口，关闭注册中心。	打开检查。
服务超时	设置全局：打断点用，可以设置长一点	设置局部：根据实际情况配置。
服务重试	应该设置为0次，因为本地没有网络波动	默认：2次重试。