Dubbo分布式框架(阿里开源)

Posted 2020-09-03

分布式开发

分布式开发的本质就在于：虽然所有的主机物理上分布了，但是对于用户而言就仿佛是一个整体。

于我们的Java开发人员而言，那么分布式开发的意义是什么呢？也就是说那里需要去使用分布式开发？

在任何一个项目里面（MVC设计模式），业务操作是最为核心的部分，而所有项目之中你的业务操作是否完整直接决定了你的项目本身是否健壮。

 

最初开发结构是使用单台服务器完成，这样就造成了一个问题：所有的业务的接口以及所有的实现类都写了在一台服务器之

中，那么这台服务器除了要进行显示的处理之外，还需要处理大量的业务操作，所以这台服务器往往要求性能很高，但是即便你再

高性能的服务器，如果面对与大用户的访问处理操作，那么你依然无所适从。

 

那么随着开发技术的不断发展，人们开始越来越多的发现如果将业务层直接和前端的开发混合在一起，那么将无法进行业务

的重用操作，这样会带来非常麻烦的业务重复开发问题，所以开始将业务的操作单独剥离出来，让业务单独运行在一台服务器上，

这样就可以组成一个业务的服务器集群，那么这样的集群也可以将其称为业务中心。

然而不管RPC技术如何进行处理操作，所有进行远程端服务的接口，必须要提供有远程对象才可以供前端开发者进行调用。

 

当这些业务中心组成完成之后，实际上也就出现了一个数据库的集群，也就是说庞大的项目开发里面，每一个业务中心应该有自己的数据库服务器供用户使用，正是因为如此，所以在很多的大型项目设计里面，对于数据库之中的约束大部分情况下往往都只会使用主键约束，而其他的所有约束都会通过业务层进行控制。对于每一个业务层后面所使用的数据库，你也可以继续进行架构设计，例如：进行库表的分离设计，或者直接使用MyCat进行分片处理。

 

 

传统分布式开发技术

如果要想说最早的分布式开发技术（分布式技术的鼻祖，是属于所有语言都可以实现的技术）就是CORBA，而在CORBA之后由SUN公司发布了一项属于自己的分布式开发技术：RMI（这个技术性能差，但是这个技术的实现形式和Dubbo是最相似的）。

 

在RMI的处理里面，有两个非常重要的概念，那么就是存根与骨架，可以简单的理解为，RMI技术依然借助于接口定义完成，客户端用户接口定义形式（远程方法视图），客户端通过这个远程接口就可以知道所有可以使用的方法有那些。后来随着JDK版本的不断的提升，那么服务端的骨架会自动的进行生成处理。不过由于RMI技术使用非常的小众，所以并没有发展起来，后来经过不断的技术的创新，在RMI基础之后，又结合了CORBA ，形成了后来的EJB技术，而在EJB技术里面真正提出了业务中心的概念，也就是说结合会话Bean与实体Bean进行业务中心的定义，不过由于整个的EJB的设计体系过于庞大，就导致EJB技术的技术成本很高，所以不得不放弃（SSH框架开发阶段）。

 

 

但是在整个的行业之中对于分布式开发的需求实际上是一直存在的，尤其是到了后来net大力发展的时代，很多的开发者为了融合J2EE与.net体系的完美对接，后来推出了WebService技术。

 

WebService的好处是使用了XML作为数据交换，可以整合所有的技术平台。但是缺点：慢，非常慢的执行。

WebService在进行处理的时候往往会结合一些WEB容器去实现。而要知道给出的XFire等开发框架是一个不断发展的过程。现在依然有许多的开发公司使用了CXF

开发技术进行开发，并且CXF后续有了一个jersey（Rest架构）。

后来在WebService上继续进行了技术的革新，产生了一个SOA的概念，而后又同时出现了ESB的概念，整合所有的应用。不过这个SOA概念炒作了几年之后，也就很少听见了。那么再随后的技术发展就发展到了现在经常听见Restful架构，利用JSON或XML实现数据的交换处理，这样的好处是可以更多的避免WebService

所带来的性能问题，在很多的开源项目里面被大量的采用。

但是综合以上的许多点会发现实际上不管这些分布式的技术如何发展，那么总体而言有两种形式：

·

基于远程接口的实现技术：RMI、EJB、Dubbo；·

基于平台的交换技术（基于XML、JSON）：WebService、Rest架构。

 

 

 Dubbo简介

 

Dubbo在整体的实现风格上与Java传统的RMI、EJB技术都是非常相似，在整个的开发处理之中依然是以接口（远程接口）为主进行服务提供的。

 

对于Dubbo本身开发架构来讲：开发人员可以说所需要做的处理是非常有限的，而Dubbo开发框架会帮助用户进行一系列的配置处理。同时在整个的Dubbo里面也有一些属于自己的开发需求。

 

对于开发者或者使用者而言，最为关注的部分往往就是业务操作部分，在业务操作部分里面重点就在于接口。实际上分为这么多的层次结构本身是非常有意义的，例如：在进行业务交换的时候往往会传递VO类对象，那么这个对象一旦传递就一定会牵扯到远程传输，而一旦需要远程传输对象，那么就一定需要有序列化的操作支持。而且Dubbo本身需要有一个注册中心，那么注册中心负责Dubbo所有元数据的提供，那么依靠这些元数据的信息提供才可以找到所需要的

Dubbo服务，同时在整个的设计里面，也提供有一个监控工具，监控所有的Dubbo服务。

 

 

在整个的Dubbo开发框架里面有两个非常重要的角色操作：服务提供者（Provider）、消费者（Consumer），就可以简单的理解为Provider提供有具体的业务接口实现类，而Consumer依据远程接口来调用远程对象（提供者上提供的业务接口实现类）。

 

在整个Dubbo的设计里面充分的考虑到了各类用户的需求，一些底层的通讯或者是信息存储都提供有大量的不同的存储方案。