分布式RPC框架Apache Dubbo

• 软件架构的演进过程
• • 1· 单体架构
  • 2· 垂直架构
  • 3· SOA架构
  • 4· 微服务架构
• Dubbo简介
• 服务注册中心Zookeeper
• • Zookeeper树型目录服务：
• Dubbo协议
• Dubbo的负载均衡
• 给Dubbo添加事务
• • @Transactional
  • 解决方法

软件架构的演进过程

软件架构的发展经历了由单体架构、垂直架构、SOA架构到微服务架构的演进过程

1· 单体架构

全部功能集中在一个项目内（All in one）

架构优点：

架构简单，前期开发成本低、开发周期短，适合小型项目。

架构缺点：

全部功能集成在一个工程中，对于大型项目不易开发、扩展和维护。

技术栈受限，只能使用一种语言开发。

系统性能扩展只能通过扩展集群节点，成本高。

最初学习的项目就是为单体架构

2· 垂直架构

按照业务进行切割，形成小的单体项目。

架构优点：

技术栈可扩展（不同的系统可以用不同的编程语言编写）。

架构缺点：

功能集中在一个项目中，不利于开发、扩展、维护。

系统扩张只能通过集群的方式。

项目之间功能冗余、数据冗余、耦合性强。

3· SOA架构

SOA全称为Service-Oriented Architecture，即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。

站在功能的角度，把业务逻辑抽象成可复用的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。

将重复功能或模块抽取成组件的形式，对外提供服务，在项目与服务之间使用ESB（企业服务总线）的形式作为通信的桥梁。

架构优点：

重复功能或模块抽取为服务，提高开发效率。

可重用性高。

可维护性高。

架构缺点：

各系统之间业务不同，很难确认功能或模块是重复的。

抽取服务的粒度大。

系统和服务之间耦合度高。

目前大部分小型公司采用SOA架构

4· 微服务架构

将系统服务层完全独立出来，抽取为一个一个的微服务。

抽取的粒度更细，遵循单一原则。

采用轻量级框架协议传输。

架构优点：

服务拆分粒度更细，有利于提高开发效率。

可以针对不同服务制定对应的优化方案。

适用于互联网时代，产品迭代周期更短。

架构缺点：

粒度太细导致服务太多，维护成本高。

分布式系统开发的技术成本高，对团队的挑战大。

目前市场上主流架构为微服务架构

Dubbo简介

Apache Dubbo是一款高性能的Java RPC框架。其前身是阿里巴巴公司开源的、轻量级的开源Java RPC框架，可以和Spring框架无缝集成，2018年阿里巴巴把这个框架捐献给了apache基金会。

RPC全称为remote procedure call，即远程过程调用。RPC是一个泛化的概念，严格来说一切远程过程调用手段都属于RPC范畴。

Dubbo提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

服务注册中心Zookeeper

Zookeeper 是 Apache Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo服务的注册中心，工业强度较高，可用于生产环境，并推荐使用 。

Zookeeper树型目录服务：

服务提供者(Provider)启动时: 向 /dubbo/com.foo.BarService/providers 目录下写入自己的URL 地址；

服务消费者(Consumer)启动时: 订阅 /dubbo/com.foo.BarService/providers 目录下的提供者URL 地址。并向 /dubbo/com.foo.BarService/consumers 目录下写入自己的 URL 地址；

监控中心(Monitor)启动时: 订阅 /dubbo/com.foo.BarService 目录下的所有提供者和消费者URL 地址；

Dubbo协议

Dubbo支持的协议有：dubbo、rmi、hessian、http、webservice、rest、redis等。

推荐使用的是dubbo协议，默认的端口号为20880

dubbo 协议采用单一长连接和 NIO 异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。

dubbo也可以在同一个工程中配置多个协议，不同服务可以使用不同的协议。

Dubbo的负载均衡

负载均衡（Load Balance）：其实就是将请求分摊到多个操作单元上进行执行，从而共同完成工作任务。

在集群负载均衡时，Dubbo 提供了多种均衡策略（包括随机、轮询、最少活跃调用数、一致性Hash），默认为random随机调用。

配置负载均衡策略，既可以在服务提供者一方配置，也可以在服务消费者一方配置：

public class HelloController {
//在服务消费者一方配置负载均衡策略
@Reference(check = false,loadbalance = "random")
private HelloService helloService;
           

//在服务提供者一方配置负载均衡
@Service(loadbalance = "random")
public class HelloServiceImpl implements HelloService {
public String sayHello(String name) {
return "hello " + name;
}
}
           

给Dubbo添加事务

@Transactional

Dubboo通过提供的标签配置进行包扫描，扫描到@Service注解的类后被发布为服务。

但是在服务提供者类上加入@Transactional事务控制注解后，服务就发布不成功了。原因是@Transactional注解的底层原理是为服务提供者类创建代理对象，默认情况下Spring是基于JDK动态代理方式创建代理对象，代理对象的完整类名为com.sun.proxy.$Proxy42（最后两位数字不是固定的）。导致

Dubbo在发布服务前进行包匹配时无法完成匹配，进而没有进行服务的发布。

根据源码可看出 beanClassName包的地址不能与pkg,无法返回ture。

解决方法

在l类上加入事务注解后，Spring会为此类基于JDK动态代理技术创建代理对象，创建的代理对象完整类名为com.sun.proxy.$Proxy35，导致Dubbo在进行包匹配时没有成功。

（1）修改applicationContext-service.xml配置文件，开启事务控制注解支持时指定proxy-target-class属性，值为true。其作用是使用cglib代理方式为Service类创建代理对象

<!--开启事务控制的注解支持-->
<tx:annotation-driven transaction-manager="transactionManager" proxy-targetclass="true"/>
           

（2）修改HelloServiceImpl类，在Service注解中加入interfaceClass属性，值为HelloService.class，作用是指定服务的接口类型

@Service(interfaceClass = HelloService.class)
@Transactional
public class HelloServiceImpl implements HelloService {
public String sayHello(String name) {
return "hello " + name;
}
}