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

前言

眼看着2023即将走远，心里想着似乎还有啥，需要再跟各位盆友叨叨。这不说曹操，曹操就来了。趁着上一篇Dubbo博文的余温尚在，博主兴匆匆地“赶制”了Dubbo的下集，以飨读者。

上一篇博主依然从Dubbo的内核出发，阐明了它是如何running的。而今天博主继续带着各位盆友，了解如何使用它。鉴于当前Spring+Dubbo组合的流行，本博是基于Spring完成相关介绍。

如需寻一份Dubbo最新的官方源码，请速戳：apache dubbo github sourcecode；
如需查阅最近的中文文档，请速戳：apache dubbo doc；

使用Dubbo

什么是契约？简单讲，可以理解为通信双方必须遵守的约定。既然Dubbo是基于RPC通信完成服务调用，那么服务提供者（P）与服务消费者（C）必须建立在同一个“频率”完成互相握手。

那么在RPC中，或者具体到Dubbo使用过程中，如何建立“契约”？请紧随博主脚步，以防迷路。

1、创建BaseService

一个base api可以作为通信的“契约”，实现P与C的互相通信。

通常，我们在创建BaseService的时候，以接口的形式出现，当然必须符合java的接口设计原则。形如：

public interface MyBaseService {/*** 基础服务* @param input 输入内容*/String doWork(String input) throws ServiceException;
}

2、创建服务提供者（P）

创建BaseService完成后，我们可以创建一个Provider。形如：

@Service("myService")
public class MyBaseServiceImpl implements MyBaseService {@OverrideString doWork(String input) throws ServiceException{return "running:"+input;}
}

定义完成后，我们应该把它发布到服务环境中，怎么发布？

<!--  --><!-- 服务提供应用名称 -->
<dubbo:application name="myservice-provider"/>
<!-- 指定注册中心 -->
<dubbo:registry id="myservice" address="zookeeper://localhost:2181"/>
<!-- 服务发布协议及暴露端口 -->
<dubbo:protocol name="dubbo" port="28080"/>
<!-- 声明需要暴露的服务接口-->
<dubbo:service interface="com.mytest.MyBaseService"ref="myService" timeout="300000" retries="0" loadbalance="roundrobin"/>

其中，dubbo:service几个参数的解释如下：

参数名	参数说明
interface	提供服务的接口全路径
ref	服务提供类，通常是已实现了interface的Bean
timeout	超时时间，单位毫秒
retries	重试次数，当服务异常时触发
loadbalance	负载均衡方式，默认随机

行文至此，我们已经新建了一个Provider，可以通过Spring启动，也可以通过web容器部署。当然部署时，我们可以观察到，每个服务均以dubbo协议发布，服务请求的URL如下所示：

 dubbo://localhost:28080/com.mytest.MyBaseService

当然该URL是基础路径，还包括了dubbo:service中指定的各种参数以及服务的请求方法。

3、创建服务消费者（C）

具备了服务提供者，那么我们可以准备一个服务消费者，用于请求提供者发布的服务。
首先，声明一个服务代理，形如：

<dubbo:reference interface="com.mytest.MyBaseService" id="myBaseService" check="false" loadbalance="roundrobin" retries="0"/>

其中，dubbo:reference 几个参数的解释如下：

参数名	参数说明
interface	请求服务的接口全路径
id	接口唯一ID
check	是否开启服务检测
loadbalance	负载均衡方式，默认随机

声明完成后，我们可以新建一个class，实现RPC调用。

实际上，我们经常使用的dubbo架构如下图示意。这也是本期介绍的主要内容。

---

结语

Dubbo 为开发者提供从项目创建、开发测试，到部署、可视化监测、流量治理，再到生态集成的全套服务。

从这句话可以了解，Dubbo为微服务的开局和繁荣提供了持久的源动力，当然它依然在逐步进化中。博主衷心的希望Dubbo更上一层楼，为微服务继续添砖加瓦。

---

历史回顾

---

• 微服务实战系列之Dubbo（上）
• 微服务实战系列之ZooKeeper（实践篇）
• 微服务实战系列之ZooKeeper（下）
• 微服务实战系列之ZooKeeper（中）
• 微服务实战系列之ZooKeeper（上）
• 微服务实战系列之MQ
• 微服务实战系列之通信
• 微服务实战系列之J2Cache
• 微服务实战系列之Cache（技巧篇）
• 微服务实战系列之MemCache
• 微服务实战系列之EhCache
• 微服务实战系列之Redis
• 微服务实战系列之Cache
• 微服务实战系列之Nginx（技巧篇）
• 微服务实战系列之Nginx
• 微服务实战系列之Feign
• 微服务实战系列之Sentinel
• 微服务实战系列之Token
• 微服务实战系列之Nacos
• 微服务实战系列之Gateway
• 微服务实战系列之加密RSA
• 微服务实战系列之签名Sign

---