Dubbo能做什么？的架构和设计思路分析！

Dubbo是一个分布式服务框架，致力于提供高性能、透明的RPC远程服务调用解决方案和SOA服务治理解决方案。

简单来说，dubbo 是一个服务框架。 如果不需要分发，其实也没有必要使用。 只有分布式的时候，才需要dubbo这样的分布式服务框架，本质上就是服务调用。 东东，说白了就是一个远程服务调用的分布式框架（告别Web方式的WSdl，注册到dubbo上作为服务端和消费者）。

其核心部分包括：

1、远程通讯：

提供了对多种基于长连接的NIO框架的抽象封装，包括多线程模型、序列化、“请求-响应”模式信息交换方法。

2.集群容错：

提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡、容错、地址路由、动态配置等集群支持。

3、自动发现

基于注册中心目录服务，服务消费者可以动态搜索服务提供者，地址透明，服务提供者可以平滑增减机器。

多宝能做什么？

1.透明的远程方法调用

调用远程方法就像调用本地方法一样，配置简单，无API侵入。

2.软负载均衡和容错机制

可以替代内网F5等硬件负载均衡器，降低成本，减少单点。

3.自动服务注册和发现

无需对服务提供商地址进行硬编码。 注册中心根据接口名称查询服务提供商的IP地址，可以平滑地添加或删除服务提供商。

Dubbo采用全配置方式透明访问应用程序。 没有 API 侵入应用程序。 只需要加载Dubbo的配置，基于Dubbo的扩展就被加载了。

Dubbo的架构和设计思想

Dubbo框架具有极高的扩展性，主要采用微内核+插件体系，并且文档齐全，非常方便二次开发，适应性强。

Dubbo的整体架构如图所示：

Dubbo框架设计总共分为10层，最顶层是为真正想使用Dubbo开发分布式服务实现业务逻辑的开发人员保留的接口层。 图中，左边浅蓝色背景是服务消费者使用的接口，右边浅绿色背景是服务提供者使用的接口，中轴上的接口是双方使用的接口。

Dubbo框架设计分为10层：

与淘宝HSF相比，Dubbo有什么特点？

1.Dubbo比HSF部署方式更加轻量级

HSF需要使用指定的JBoss等容器，还需要给JBoss等容器添加sar包扩展，这对用户的运行环境侵入性很大。 如果想运行在其他容器如 或 等上，则需要自己扩展容器以兼容HSF加载。 ，而Dubbo没有任何要求，可以运行在任何Java环境中。

2、Dubbo比HSF扩展性更强，二次开发非常方便。

一个框架不可能涵盖所有需求。 Dubbo始终保持对第三方一视同仁的理念，即不需要修改Dubbo原生代码就可以外围扩展所有功能，包括Dubbo自己内置的功能，就像第三方一样。 它是通过扩展来实现的，如果要增加功能或者替换某些部分的实现，HSF是非常困难的。 比如支付宝和淘宝使用不同的HSF分支，因为添加功能的时候核心代码变了，你必须复制一份。 各分支机构独立发展。 即使现阶段HSF开源，除非重写架构，否则也很难复用。

3. HSF依赖很多内部系统

比如配置中心、通知中心、监控中心、单点登录等，如果要开源的话，还需要做大量的剥离工作，但是Dubbo为各个系统的整合预留了扩展点，并整理了所有依赖关系，同时为开源社区提供了用户可以直接使用的替代方案。

4.Dubbo比HSF功能更多

除了隔离之外，Dubbo 基本上是 HSF 的超集。 Dubbo还支持更多的协议以及更多注册中心的集成，以适应更多的网站架构。

Dubbo适合什么场景？

1.RPC分布式服务

当网站规模变大时，不可避免地将应用拆分为服务，以提高开发效率、优化性能、节省关键竞争资源。

例如：为了适应不断变化的市场需求，方便多个垂直应用之间的数据交互，我们将公共业务抽取出来作为一个独立的模块，为其他应用提供服务。 系统逐渐依赖抽象和RPC远程服务调用。 。

2、配置管理

当服务越来越多时，服务的URL地址信息会爆炸，配置管理会变得非常困难，F5硬件负载均衡器的单点压力也会增大。

3. 服务依赖

随着进一步发展，服务之间的依赖关系变得如此复杂，甚至不清楚哪个应用程序应该在哪个应用程序之前启动，架构师也无法完整地描述应用程序的架构关系。

4、服务拓展

那么，随着服务调用次数的增加，服务的容量问题就暴露出来了。 该服务需要支持多少台机器？ 我什么时候应该添加机器？ ETC……

遇到这些问题时，可以使用Dubbo来解决。

欢迎加入小编的Java学习群。 无论你是新手还是专家，我都欢迎大家。 我会不定期分享有用的信息，包括2019年最新的Java信息以及小编自己整理的零基础入门教程视频。 欢迎初学者和进阶的朋友。我不忙的时候会回答你们的问题。

本文由博文多平台发布！