关于作者
程序猿周周
⌨️ 短视频小厂BUG攻城狮
如果文章对你有帮助,记得关注、点赞、收藏,一键三连哦,你的支持将成为我最大的动力
本文是《后端面试小册子》系列的第 1️⃣3️⃣ 篇文章,该系列将整理和梳理笔者作为 Java 后端程序猿在日常工作以及面试中遇到的实际问题,通过这些问题的系统学习,也帮助笔者顺利拿到阿里、字节、华为、快手等多个大厂 Offer,也祝愿大家能够早日斩获自己心仪的 Offer。
PS:《后端面试小册子》已整理成册,目前共十三章节,总计约二十万字,欢迎关注公众号【程序猿周周】获取电子版和更多学习资料(最新系列文章也会在此陆续更新)。公众号后台可以回复关键词「电⼦书」可获得这份面试小册子。文中所有内容都会在 Github 开源,项目地址 csnotes,如文中存在错误,欢迎指出。如果觉得文章还对你有所帮助,赶紧点个免费的 star 支持一下吧!
标题 | 地址 |
---|---|
MySQL数据库面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/122910606 |
Redis面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/122934938 |
计算机网络面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/122973684 |
操作系统面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/122994599 |
Linux面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/122994862 |
Spring面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/123016872 |
Java基础面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/123080189 |
Java集合面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/123171501 |
Java并发面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/123266624 |
Java虚拟机面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/123412605 |
Java异常面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/123462676 |
设计模式面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/123490442 |
Dubbo面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/123538243 |
Netty面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/123564362 |
Dubbo 是阿里 SOA 服务化治理方案的核心框架,也是一个分布式、高性能、透明化的 RPC 服务框架,提供服务自动注册、自动发现等高效服务治理方案, 可以和 Spring 框架无缝集成。
Remoting:网络通信框架,提供对多种 NIO 框架抽象封装,包括”同步转异步“和”请求-响应“模式的信息交换方式。
Cluster:服务框架,提供基于接口方法的透明远程过程调用,包括多协议支持,以及软负载均衡,失败容错,地址路由,动态配置等集群支持。
Registry:服务注册,基于注册中心目录服务,使服务消费方能动态的查找服务提供方,使地址透明,使服务提供方可以平滑增加或减少机器。
Dubbo 是 SOA 时代的产物,它的关注点主要在于服务的调用,流量分发、流量监控和熔断,而 Spring Cloud 诞生于微服务架构时代,考虑的是微服务治理的方方面面,并有强大的 Spring 家族优势支持,因此两个框架在开始目标就不一致,Dubbo 定位服务治理、Spirng Cloud 是一个生态。
二者最大的区别是:Dubbo 底层是使用 Netty 这样的 NIO 框架,是基于 TCP 协议传输的,配合 Hession 序列化完成 RPC 通信,而 SpringCloud 是基于 Http 协议加 Rest 接口调用远程过程的通信。
Http 请求会有更大的报文,占的带宽也会更多,但是 REST 相比 RPC 更为灵活,调用双方只依靠一纸契约,不存在代码级别的强依赖。
Provider:暴露服务的提供者。
Customer:调用远程服务的消费者。
Registry:服务注册与发现的注册中心。
Monitor:统计服务调用次数和时间的监控中心。
Container:服务运行容器。
1)Provider(提供者)绑定指定端口并启动服务;
2)指供者连接注册中心,并发本机 IP、端口、应用信息和提供服务信息发送至注册中心存储;
3)Consumer(消费者)连接注册中心 ,并发送应用信息、所求服务信息至注册中心;
4)注册中心根据消费者所求服务信息匹配对应的提供者列表发送至 Consumer 应用缓存;
5)Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用;
6)Provider 状态变更会实时通知注册中心、在由注册中心实时推送至 Consumer。
1)Consumer 与 Provider 解偶,双方都可以横向增减节点数。
2)注册中心可做对等集群,可动态增减节点,宕机后自动切换。
3)去中心化,双方不直接依懒注册中心,即使注册中心全部宕机短时间内也不会影响服务的调用。
4)服务提供者无状态,任意一台宕掉后,不影响使用。
Dubbo 支持 dubbo、rmi、hessian、http、webservice、thrift、redis 等多种协议,但是官网推荐使用 dubbo 协议。
同时,Dubbo 允许配置多协议,即在不同服务上支持不同协议或者同一服务上同时支持多种协议。
Dubbo 支持多种协议,而不同的协议默认使用的序列化框架也不同。如:
此外,
除了上面说的默认序列化框架外,也可以指定使用第三方的序列化框架,如 Kryo、FST 等。
Dubbo 内置了 4 种负载均衡策略:
如果不指定负载均衡,默认使用随机负载均衡。我们也可以根据自己的业务显式指定一个负载均衡。
可以在多个地方类来配置负载均衡,如 Provider 的服务或方法上,Consumer 的服务或方法上。
和 Dubbo 其它配置类似,多个配置是有覆盖关系的:Consumer 方法 > Consumer 接口 > Provider 方法 > Provider 接口
。
正常情况下,当我们进行系统设计时候,不仅要考虑正常逻辑下代码该如何走,还要考虑异常情况下代码逻辑应该怎么走。当服务消费方调用服务提供方的服务出现错误时候,Dubbo 提供了多种容错方案,缺省模式为 failover,也就是失败重试。
当服务消费方调用服务提供者失败后自动切换到其他服务提供者服务器进行重试。这通常用于读操作或者具有幂等的写操作,需要注意的是重试会带来更长延迟。可通过 retries="2"
参数来设置重试次数(不含第一次)。
当服务消费方调用服务提供者失败后,立即报错,也就是只调用一次。通常这种模式用于非幂等性的写操作。
当服务消费方调用服务出现异常时,直接忽略异常。这种模式通常用于写入审计日志等操作。
当服务消费端用服务出现异常后,在后台记录失败的请求,并按照一定的策略后期再进行重试。这种模式通常用于消息通知操作。
当消费方调用一个接口方法后,Dubbo Client 会并行调用多个服务提供者的服务,只要一个成功即返回。这种模式通常用于实时性要求较高的读操作,但需要浪费更多服务资源。可通过 forks="2"
参数来设置最大并行数。
当消费者调用一个接口方法后,Dubbo Client 会逐个调用所有服务提供者,任意一台调用异常则这次调用就标志失败。这种模式通常用于通知所有提供者更新缓存或日志等本地资源信息。
如上,Dubbo 本身提供了丰富的集群容错模式,但是如果您有定制化需求,可以根据 Dubbo 提供的扩展接口 Cluster 进行定制。