关于分布式服务框架Dubbo的调研报告

关于分布式服务框架Dubbo的调研报告

在接触过的项目中由于功能比较少，数据访问量并不是很大，在项目设计架构的时候总是优先考虑如何使代码简化，抽象相似方法。因此会引入诸如面向接口编程，面向切面编程，以及设计模式的考量。此时，ORM(Object/Relation Mapping)的数据访问框架，这种对象关系映射解决了面向对象与关系数据库存在的互不匹配的问题，也成了中小型项目基本的服务框架。其中，我了解的比较多的是显示层的struts2,数据持久层的Hibernate,以及业务逻辑层的Spring,三者通力配合可以大大简化应用服务的代码编程数量，可以让程序员在编写代码的时候优先考量功能需求，而不必为冗余的操作代码而浪费时间，其中我深有体会的有像将服务放入Spring,自动完成事物操作。还有关于CDUR的操作，数据存储与取得，只要进行简单的Hibernate配置就可以直接实现关系对象的转化。

当然以上ORM框架的核心以及它所完成的任务决定了一个项目分层架构是一种垂直纵向的关系，比如说我们经典的MVC模式，我们需要实体层，数据持久层，业务逻辑层，以及显示层。持久层，业务逻辑层，显示层在设计的时候需要从上往下传递数据对象，因而考量设计的重点在于高内聚，低耦合。层与层之间要相互依赖，又要相互独立。这样的设计在进行功能量适中，访问服务数量不多的情况能够应对自如，但是当访问服务数量激增，系统功能变得复杂的时候这种基于ORM的服务架构就会显得笨重，并且不利于测试。

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变得市场需求。那么，提高业务复用及整合的分布式服务框架RPC（Remote Procedure Call Protocol）就成了关键。

这种抽取核心功能的方式非常类似于MVC模型下模板方法模式，即抽取公共方法为抽象基类，而在此处就将相似服务功能抽取出来形成注册服务中心来统一调配资源。

Duboo就是这种分布式服务框架，它主要针对的是一种SOA方案，我们知道面向对象模型是紧耦合的，而SOA指得就是一种面向服务体系，实际上就是我们都认知的面向接口编程，这也是分布式核心思想，尽量用接口定义公共服务

方式，利用实现接口的方式实现具体方法。Duboo功能主要包括：高性能NIO 通讯及多协议集成，服务动态寻址与路由，软负载均衡与容错，依赖分析与降级等。

Duboo的依赖成本比较低，只要JDK在1.5以上，通过一些配置就可以让Duboo不依赖任何三方库运行起来，并且Duboo是开源的，这样就方便了程序员更好的应用在项目中，当然你的项目要有类似于淘宝的访问量你才需要考虑它的适用。

那么Duboo所要解决的问题是什么呢？

首先，服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover，降低对F5硬件负载均衡器的依赖，也能减少部分成本。

当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系。

接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。

其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量。

说了这么多，我们来看看Duboo这个架构到底提供了什么。在Duboo架构中,其主要包括5个角色，Provider:暴露服务的服务提供方；Consumer:调用服务的服务消费方；Register:服务注册与发现中心。Moniter:统计服务的调用次数和调用时间的监控中心。Container:服务运行对象。

很显然，Duboo将我们熟悉的MVC模式下业务逻辑层进行了封装，并交给容器管理。我们可以将基于Duboo的具体服务类部署于Spring IOC容器中，利用注解的方式来声明和注入相关的服务对象，将我们熟悉的业务逻辑的层的具体

方法接口统一放入Duboo形成服务注册与发现中心统一资源调配。

实际上，在使用Duboo等类似分布式框架的前提都是集中在服务层功能的真正复杂情况下，由于大型项目每个模块设计的程序员所使用的方法可能并不唯一，那么调合功能使其按照统一的方式向外发布和获取访问者的服务需求是亟需解决的。当功能累加的时候我们需要分层来部署项目，当出现瓶颈的时候我们就会希望以非常细的粒度来再次部署，这样就需要增加机器来缓解服务器的负担。

Dubbo通过长连接减少握手，即在一次连接中发送多个数据包，完成数据上传与下载。通过NIO及线程池在单连接上并发拼包处理消息，通过二进制流压缩数据，比常规HTTP等短连接协议更快。实际上NIO(new IO)的独到之处即提供了（Buffer）原始类型的缓存支持，能让我们在读写数据的时候更快。

Dubbo提供了形式简明的服务框架，使用他的同时，我们也应该考虑到部署的复杂度与并发量，它所适合的场景我想应该更多得定位于日均访问量非常大的系统，用来提供服务与追踪受众。