在日益增长的业务需求中，一开始使用的是每个项目独立开发，虽然都是前后端分离的项目，但是每一个项目之间互不干扰。后来，因为某种需求，需要几个项目的数据相互交错获取。

最开始的想法就是集成多个数据源。

举例

有A、B、C三个项目，对应着数据库DBa、DBb、DBc、，现在A项目需要同时操作DBa、DBc数据库。

这时，最理想就是调用RPC框架了。

IDEA2022.3.2 java11 SpringBoot 2.7.12-SNAPSHOT Nacos 2.2.2

注意：如果使用SpringBoot3.x以上的要使用jdk17以上的，否则会启动报错。

RPC全称为Remote Procedure Call，翻译为远程过程调用。它是一种计算机网络通信协议，用于在不同的进程或计算机之间进行通信，让它们像调用本地方法一样调用远程方法。

假设你有一个应用程序，它需要调用另外一个计算机上的函数或方法，通常情况下，你需要通过网络编程，手动发送请求和接收响应。而RPC则可以让你像调用本地函数一样，直接调用远程函数，简化了网络编程的复杂度。

具体来说，RPC通信过程中，调用方会像调用本地方法一样，发送请求到远程服务器，请求中包含了要调用的方法名和参数列表。远程服务器接收到请求后，会解析请求，调用对应的方法，并将执行结果返回给调用方。调用方收到响应后，就可以像处理本地函数一样，对结果进行处理。

通俗来说，RPC就像是你在打电话时，向远程的对方说出你需要做的事情，对方完成后告诉你结果。这样，你就不需要亲自去完成任务了，这个过程中，你只需要关心需要完成的任务和结果，不需要关心具体的实现方式。

RPC在分布式系统中的应用非常广泛，比如微服务架构中的服务调用，Hadoop中的远程过程调用等。它可以让分布式系统更加简单、灵活和可扩展。

背景 Dubbo的诞生背景可以追溯到2011年，当时阿里巴巴内部的分布式架构和服务治理已经比较成熟，但面对日益增长的业务规模和复杂性，分布式服务之间的调用和管理成为了一个巨大的挑战。在这样的背景下，Dubbo应运而生。

Dubbo最初由阿里巴巴公司的工程师提出并开发，旨在为阿里巴巴内部的分布式系统提供一种高性能、可靠、可扩展的RPC框架，帮助阿里巴巴更好地构建分布式服务架构和实现服务治理。

后来，随着Dubbo逐渐成熟并在阿里巴巴内部广泛应用，阿里巴巴决定将其开源，于2011年底正式发布第一个版本，随后在2012年和2015年分别发布了2.0和2.5版本，以及2019年发布的2.7版本。Dubbo的开源以及不断更新迭代，吸引了越来越多的用户和开发者参与，逐渐成为了Java生态系统中最受欢迎的RPC框架之一。

如今，Dubbo已经广泛应用于阿里巴巴、华为、网易等企业的分布式系统中，并得到了国内外各大互联网公司和社区的广泛认可和支持。

2018年11月，Apache Dubbo 成为了 Apache 的顶级项目，这意味着 Dubbo 已经发展成为一个非常成熟、高质量、社区活跃的开源项目。Dubbo 的加入也进一步加强了 Apache 在分布式系统领域的地位，为分布式系统的发展和推广做出了巨大贡献。

作用

Dubbo主要包括三个核心模块：

Provider（服务提供者）：暴露服务的应用，提供服务的方法。

Consumer（服务消费者）：调用远程服务的应用，消费服务的方法。

Registry（服务注册中心）：服务注册与发现的管理中心。

Dubbo框架的工作流程如下：

1、服务提供者启动，向注册中心注册自己提供的服务。

2、服务消费者启动，向注册中心订阅自己需要的服务。

3、注册中心返回可用的服务列表给服务消费者。

4、服务消费者调用远程服务。

5、远程服务提供者响应请求，返回结果给服务消费者。

6、服务消费者收到响应，完成调用。

Nacos是一种基于云原生理念构建的动态服务发现、配置管理和服务治理平台，由阿里巴巴开源团队于2018年开源。它主要解决了分布式系统中服务注册、发现、配置管理和DNS服务等问题。

Nacos提供了以下核心功能：

1、服务注册和发现：Nacos可以帮助服务提供者自动注册服务并向Nacos Server汇报服务实例的健康状况，服务消费者可以通过Nacos查询可用服务实例。

2、配置管理：Nacos提供了集中式的配置管理功能，支持动态配置、版本管理、灰度发布、监听等功能，可以方便地管理分布式系统中的配置信息。

3、服务路由和负载均衡：Nacos支持服务提供者和消费者之间的流量管理和路由规则的动态更新，以及多种负载均衡策略。

4、DNS服务：Nacos支持提供DNS服务，可以在无需其他服务发现组件的情况下使用DNS方式进行服务发现。

温馨提示：Dubbo官网上默认的注册中心是Zookeeper，本文注册中心使用的是Nacos。

像笔者这种的项目（看 需求），就是因为发展而演变成要使用微服务组件，而不是一开始就选好微服务架构的。就看这个部分就好了。否则请看方案二。

启动类加上注解@EnableDubbo

启动这两个项目（消费者和提供者），因为消费者配置了check: false，所以先启动哪一个项目都是可以的。消费者的端口是8102，我们访问一下

http://localhost:8102/user/1

看到如下

DemoService的全限定包名是import com.example.astar.component.DemoService，也就是说消费者和提供者之间的桥梁就是来自同一个接口，我们需要在项目中分别创建一模一样的接口才可以，实现类不用管。如果提供者和消费者的接口的包名不一样就会导致调用失败。

说人话：就是两个项目都不在一个文件下，怎么可能用同一个类？这里只要这个类本身、包名一样就可以了，Dubbo就会认为是一样的。

此方案是在一开始就决定用微服务这个框架的项目来说的，通常我们会分为类似以下几个子模块：

步骤我就懒得说了，大致和方案一一样，不同的地方是公共模块interface的导入： 在消费者和提供者上添加子模块即可：

温馨提示：打包的时候会把子模块的引入部分一起打包，不用担心，正常使用即可，其余部分不变。

END

茫茫人海路漫漫， 潜心修炼方有颜。 踏实走好每一步， 静待花开见真章。