微服务实战系列之Dubbo（上）

前言

随着一年一度冬至的到来，2023的步伐也将远去。而博主的系列文章，也将从今天起，越来越聚焦如何构建微服务“内核”上。前序系列文章几乎囊括了微服务的方方面面，无论使用什么框架、组件或工具，皆可拿来用之。

那么，今天博主将推出微服务开发框架系列文章，欢迎各位盆友继续跟着博主的步伐，快乐徜徉于微服务的世界。Let’s Go！

本期主题，博主将带着各位盆友，聚焦在经典的RPC框架：Dubbo，一个盛行于互联网平台的宠儿。

在这里插入图片描述

一、读懂RPC

我们提到Dubbo，那不得不提RPC（远程过程调用，Remote Procedure Call缩写）。首先了解一下什么是RPC：

RPC是一个通信协议，允许客户端通过网络调用非本地的服务，即像调用本地服务一样，调用一个“远程”的网络服务。一般用于构建分布式平台，实现跨网络访问通信。

1. 主要特点

经典3跨
无需关注“远程”服务如何实现，支持3跨（跨网络、跨平台、跨语言）。只要一个Client，根据RPC通信规范，即可叩开一个Remote Server的大门。此乃经典的C/S程序架构模式。
服务可重用性
既然满足3跨，那可了不起了。随时随地，任你“驰骋”。只要Server有，统统皆拿走。此刻，博主不禁暗然自喜中…

2. 核心组件

我们已知RPC是一个通信过程的协议，如使用它，必须遵循相应的“制度”，否则，乱了“江湖规矩”。满足RPC调用，必须具备以下四个模块：

模块名称	模块简介
Client	一个客户端，可发起远程调用的程序，一般称之为`“消费者”`。
Client Stub	一个客户端的请求存根，记录调用的服务信息，实现请求信息`“编码”`和服务端返回信息的`“解码”`。
Server	一个服务端，可提供服务的正在运行的程序，一般称之为`“生产者”`。
Server Stub	一个服务端的响应存根，记录接收的客户端信息，实现客户端数据`“解码”`；发起服务调用并向`Client Stub`返回经过`“编码”`的信息。

具体交互流程图，示意如下，请参考：

在这里插入图片描述

3. 关键技术

我们可能知道或至少了解，通信的基本原理：
在这里插入图片描述

首先需要通信的双方，其次需要一个通信的媒介或载体，最后是信息内容。当然该过程存在一定的干扰项（比如平台、网络、语言等等），因此一定程度上存在可能“失真”的风险。

那么RPC既然是一个通信协议，那也基本遵循该原理，核心技术包括：

–序列化和反序列化（Sequence）
将对象转换为二进制或逆向转换，即实现RPC过程中的编码和解码的过程。
–动态代理（Proxy）

动态代理是一种在运行时创建代理类的机制，动态代理可以在不修改源代码的情况下，在运行时为某个接口动态生成实现类，并且可以拦截接口中的方法调用，从而实现一些特殊的功能.。

比如AOP、日志、注解等皆使用了动态代理技术实现。而在RPC中，主要用它完成调用过程的核心处理逻辑（2个Stub皆采用该技术），包括封装请求信息、发起调用和返回响应信息等传输过程实现。

到此为止，我想各位盆友已对RPC有了深刻的认识和了解。那么接下来，博主顺势而为，继续带着大家走进人见人爱的Dubbo。

二、走进Dubbo

Apache Dubbo is a high-performance, Java-based open-source RPC framework.

翻译成大白话：Dubbo是一个基于JAVA的高性能开源RPC框架。

1. 架构图

在这里插入图片描述
通过Dubbo架构图（来自官网）观察，是不是很很高效很经典？一个标准的端到端的服务框架。

组件名称	组件含义
Consumer	服务消费者，用于使用服务
Provider	服务提供者，也叫生产者，用于提供服务
ZooKeeper	用于满足Dubbo服务治理的工具，称之为服务注册中心

当然，Dubbo 在微服务应用开发框架之上抽象了一套 RPC 服务定义、暴露、调用与治理的编程范式，所以实际上它的服务能力包含了服务治理内容，可参考下图（来自官网）：
在这里插入图片描述

2. 关键特性

- Transparent interface based RPC
提供基于RPC的透明接口
- Intelligent load balancing
提供智能的负载均衡策略
- Automatic service registration and discovery
提供自动的服务注册和发现能力
- High extensibility
提供较高的扩展能力
- Runtime traffic routing
提供运行时的服务管理和路由能力
- Visualized service governance
提供可视化服务治理能力