Apache Dubbo 架构与实战

Captain Leo

关注

最新推荐文章于 2026-07-03 10:38:24 发布 · 847 阅读

原创

本文为博客 VIP 文章，开通 VIP 后可阅读全文

开通 VIP

Dubbo 是一款高性能的Java RPC 框架

项目架构演变过程

随着互联网的发展，用户群体逐渐壮大，网站的流量成倍增长，常规的单体架构已无法满足请求压力暴增和业务的快速迭代，架构的变化势在必行。

单体架构

单体架构所有模块和功能都集中在一个项目中，部署时也是将项目所有功能部整体署到服务器中。如下图：
在这里插入图片描述

优点
- 小项目开发快成本低
- 架构简单
- 易于测试
- 易于部署
缺点
- 大项目模块耦合严重不易开发维护沟通成本高
- 新增业务困难
- 核心业务与边缘业务混合在一块，出现问题互相影响

垂直架构

根据业务把项目垂直切割成多个项目，因此这种架构称之为垂直架构。

为了避免上面提到的那些问题，我们开始做模块的垂直划分，做垂直划分的原则是基于业务特性，核心目标，第一个是为了业务之间互不影响，第二个是在研发团队的壮大后为了提高效率，减少之间的依赖。
在这里插入图片描述

优点
- 系统拆分实现了流量分担，解决了并发问题
- 可以针对不同系统进行优化
- 方便水平扩展，负载均衡，容错率提高
- 系统间相互独立，互不影响，新的业务迭代时更加高效
缺点
- 服务系统之间接口调用硬编码
- 搭建集群之后，实现负载均衡比较复杂
- 服务系统接口调用监控不到位调用方式不统一
- 服务监控不到位
- 数据库资源浪费，充斥慢查询，主从同步延迟大

分布式架构（SOA )

SOA全称为Service Oriented Architecture，即面向服务的架构 。它是在垂直划分的基础上，将每个项目拆分出多个具备松耦合的服务，一个服务通常以独立的形式存在于操作系统进程中。各个服务之间通过网络调用，这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

我们在做了垂直划分以后，模块随之增多，系统之间的RPC逐渐增多，维护的成本也越来越高，一些通用的业务和模块重复的也越来越多，这个时候上面提到的接口协议不统一、服务无法监控、服务的负载均衡等问题更加突出，为了解决上面的这些问题，我们将通用的业务逻辑下沉到服务层，通过接口暴露，供其他业务场景调用。同时引入了阿里巴巴开源的Dubbo，一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。
在这里插入图片描述
解释说明:

分层: 按照业务性质分层每一层要求简单和容易维护
- 应用层: 距离用户最近的一层也称之为接入层使用tomcat 作为web容器接收用户请求使用下游的dubbo提供的接口来返回数据并且该层禁止访问数据库
- 业务服务层:根据具体的业务场景演变而来的模块比如简历投递职位搜索职位推荐等
- 基础业务层:招聘业务的核心是账号简历公司职位，这一层是与业务无关的模块是一些通用的服务，这类服务的特点: 请求量大逻辑简单特性明显功能独立
  - 消息服务（发邮件短信微信）
  - 附件解析 50% 自己上传附件需要解析成pdf
- 存储层:不同的存储类型 Mysql Mongodb ES fastDFS
分级:按照业务性质分层同一层的业务也要做好分级依据业务的重要性进行分级按照二八定律网站80%的流量都在核心功能上面要优先保证核心业务的稳定。
隔离:不同性质不同重要性的业务做好隔离包括业务缓存 DB 中间件都要做好隔离比如核心业务的数据库要和活动相关的数据库隔离
调用 :总体上调用要单向可以跨层调用但不能出现逆向调用
优点
- 服务以接口为粒度，为开发者屏蔽远程调用底层细节使用Dubbo 面向接口远程方法调用屏蔽了底层调用细节
- 业务分层以后架构更加清晰并且每个业务模块职责单一扩展性更强
- 数据隔离，权限回收，数据访问都通过接口让系统更加稳定安全
- 服务应用本身无状态化这里的无状态化指的是应用本身不做内存级缓存而是把数据存入db
- 服务责任易确定每个服务可以确定责任人这样更容易保证服务质量和稳定
缺点
- 粒度控制复杂如果没有控制好服务的粒度服务的模块就会越来越多就会引发超时分布式事务等问题
- 服务接口数量不宜控制容易引发接口爆炸所以服务接口建议以业务场景进行单位划分并对相近的业务做抽象防止接口爆炸
- 版本升级兼容困难尽量不要删除方法字段枚举类型的新增字段也可能不兼容
- 调用链路长服务质量不可监控调用链路变长下游抖动可能会影响到上游业务最终形成连锁反应服务质量不稳定同时链路的变成使得服务质量的监控变得困难

微服务架构

微服务架构是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中独立运行，并使用轻量级机制(通常是HTTP资源的API)进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。这些服务的集中化管理非常少，它们可以用不同的编程语言编写，并使用不同的数据存储技术。

微服务是在SOA上做的升华 , 粒度更加细致，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”。

后面单独写一篇微服务架构相关的文章，大家期待哈！！！

Dubbo架构与实战

Dubbo 架构概述

什么是Dubbo
Apache Dubbo是一款高性能的Java RPC框架。其前身是阿里巴巴公司开源的一个高性能、轻量级的开源Java RPC框架，可以和Spring框架无缝集成。
Dubbo 的特性
- 基于透明接口的 RPC
- 智能负载均衡
- 自动服务注册和发现
- 高扩展性
- 运行时流量路由
- 可视化服务治理
Dubbo 的服务治理
服务治理（SOA governance），企业为了确保项目顺利完成而实施的过程，包括最佳实践、架构原则、治理规程、规律以及其他决定性的因素。服务治理指的是用来管理SOA的采用和实现的过程。

Dubbo 处理流程

在这里插入图片描述

节点说明：

节点	角色名称
Provider	暴露服务的服务提供方
Consumer	调用远程服务的服务消费方
Registry	服务注册与发现的注册中心
Monitor	统计服务的调用次数和调用时间的监控中心
Container	服务运行容器负责启动加载运行服务提供者

调用流程:
- 服务提供者在服务容器启动时向注册中心注册自己提供的服务
- 服务消费者在启动时向注册中心订阅自己所需的服务
- 注册中心返回服务提供者地址列表给消费者如果有变更注册中心会基于长连接推送变更数据给消费者
- 服务消费者从提供者地址列表中基于软负载均衡算法选一台提供者进行调用如果调用失败则重新选择一台
- 服务提供者和消费者在内存中的调用次数和调用时间定时每分钟发送给监控中心

服务注册中心Zookeeper

通过前面的Dubbo架构图可以看到，Registry（服务注册中心）在其中起着至关重要的作用。Dubbo官方推荐使用Zookeeper作为服务注册中心。Zookeeper 是 Apache Hadoop 的子项目，作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用。
Zookeeper的安装及其使用见上一篇文章。

Dubbo开发实战

实战案例介绍

在Dubbo中所有的的服务调用都是基于接口去进行双方交互的。双方协定好Dubbo调用中的接口，提供者来提供实现类并且注册到注册中心上。

调用方则只需要引入该接口，并且同样注册到相同的注册中心上(消费者)。即可利用注册中心来实现集群感知功能，之后消费者即可对提供者进行调用。

我们所有的项目都是基于Maven去进行创建，这样相互在引用的时候只需要以依赖的形式进行展现就可以了。

并且这里我们会通过maven的父工程来统一依赖的版本。

程序实现分为以下几步骤:

建立maven工程并且创建API模块: 用于规范双方接口协定
提供provider模块，引入API模块，并且对其中的服务进行实现。将其注册到注册中心上，对外来统一提供服务。
提供consumer模块，引入API模块，并且引入与提供者相同的注册中心。再进行服务调用。

开发过程

接口协定

定义maven。

<groupId>com.learn</groupId> 
<artifactId>service-api</artifactId>
<version>1.0-SNAPSHOT</version>

定义接口，这里为了方便，只是写一个基本的方法。

public interface HelloService {
       
        
	String sayHello(String name); 
}

创建接口提供者

引入API模块。

	<dependency> 
		<groupId>com.learn</groupId> 
		<artifactId>service-api</artifactId> 
		<version>${project.version}</version> 
	</dependency>

引入Dubbo相关依赖，这里为了方便，使用注解方式。

	<dependency> 
		<groupId>org.apache.dubbo</groupId> 
		<artifactId>dubbo</artifactId> 
	</dependency> 
	<dependency> 
		<groupId>org.apache.dubbo</groupId>
		<artifactId>dubbo-registry-zookeeper</artifactId> 
	</dependency> 
	<dependency> 
		<groupId>org.apache.dubbo</groupId> 
		<artifactId>dubbo-rpc-dubbo</artifactId> 
	</dependency> 
	<dependency> 
		<groupId>org.apache.dubbo