如何把握分布式服务发布和服务引用流程？

最新推荐文章于 2024-10-01 18:51:18 发布

职略

最新推荐文章于 2024-10-01 18:51:18 发布

阅读量1.2k

点赞数 32

文章标签： java 大数据 jvm 分布式架构

本文链接：https://blog.csdn.net/2401_83062316/article/details/139084415

版权

在分布式系统和微服务架构中，系统的能力来自于服务与服务之间的交互和集成。为了实现这一过程，就需要服务提供者对外暴露可以访问的入口，而服务消费者就基于这些入口对服务提供者发起访问。

我们来举一个例子，如果我们想要发布一个DemoService，那么可以使用这样的代码。

DemoService service = new…;

RpcServer server = new…;

server.export(DemoService.class, demo, options);

而对DemoService服务进行导入的表现形式可以采用如下所示的代码风格。

RpcClient client =

DemoService service = client.refer(DemoService.class);

service.call(“how are you?”);

显然，就这两段代码而言，我们都觉得很简单。但事实上，想要实现这样的效果，开发人员要做的事情非常多。今天，我们就将从这个简单的示例出发，探讨背后的服务发布和引用流程。

服务发布和引用

在当前主流的分布式服务框架中，无论是Dubbo还是Spring Cloud，都提供了类似上面介绍的服务发布和引用功能。通过对这些框架的实现机制进行抽象和体量，我们实际上可以梳理出一套统一的设计和开发流程。接下来，让我们先来看服务的发布流程

服务发布

先抛开具体的技术和框架，我们可以简单抽象出如下图所示的服务发布整体流程。

上图中包含了服务发布过程中的各个核心组件，包括发布启动器、动态代理、发布管理器、协议服务器和中心。我们先对这些核心组件做一一展开。

发布启动器

发布启动器（Launcher）的核心作用有两点，一个是确定服务的发布形式，一个是启动服务发布过程。在目前主流的开发框架中，配置化、API调用和使用注解是最常见的三种发布形式。

以上三种方式各有利弊，在日常开发过程中，配置和注解比较常用，而API调用则主要完成服务与服务之间的集成。

讲完发布形式，我们来讨论如何启动服务发布过程。

可以看到，我们可以使用Spring容器来完成基于配置化和注解形式下的服务启动过程。而对于API调用而言，由于不一定会借助于容器，所以可以直接使用main函数来实现这一目标。

动态代理

动态代理是远程过程调用中非常核心的一个技术组件，在服务发布和服务引用过程中都会用到，其主要作用就是为了简化服务发布和引用的开发难度，以及确保能够对发布过程进行扩展和定制。

发布管理器

服务发布过程需要使用专门的组件来进行统一管理，这个组件就是发布管理器。该组件需要判断本次发布是否成功，然后在服务发布成功之后，把服务的地址信息注册到注册中心。这而这里的服务地址信息则来自于协议服务器。

协议服务器

在服务发布过程中，在物理上真正建立网络连接，并对网络端口到进行绑定和释放的组件是协议服务器。协议服务器还会对检测网络心跳以及在连接失败之后进行重连操作。

用于发布服务的常见协议包括HTTP、RMI、Hessian等。我们也可以自己定义这样的协议，例如Dubbo框架就实现了一套自定义的Dubbo协议。

注册中心

注册中心的作用是存储和管理服务定义的各类元数据，并能感知到这些元数据的变化。注册中心的核心机制就是服务注册和发现，业界也存在一批主流的注册中心实现工具。

以上所示的服务发布流程图有一定的共性，可以通过转化映射到具体的某个框架。事实上，基于Dubbo的服务发布流程与上述过程非常类似。我们在今天后面的内容中会做进一步分析。

服务引用

相较服务发布，服务的引用是一个导入（Import）的过程，整体流程如下图所示。

从上图中，我们可以看到服务调用流程与服务发布流程呈对称结构，所包含的组件包括：

调用启动器

调用启动器和发布启动器是对应的，这里不再重复介绍。

动态代理

在服务引用过程中，动态代理的作用就是确保远程调用过程的透明化，即开发人员可以使用本次对象来完成对远程对象的处理。

调用管理器

和发布管理器相比，调用管理器的核心功能是提供了一种缓存机制，从而确保根据保存在服务调用者本地的远程服务地址信息来发起调用。

协议客户端

和协议服务器相对应，协议客户端会创建与服务端的网络连接，发起请求并获取结果。

注册中心

注册中心在这里的作用是提供查询服务定义元数据的入口。

以上所示的服务引用流程图同样有一定的共性，可以通过转化映射到具体的某个框架。事实上，基于Dubbo的服务引用流程与上述过程也比较类似。

对比服务发布，服务引用的实现过程通常会更加复杂一点。这在Dubbo框架中体现的就比较明显。接下来，我们就以Dubbo框架为例，分析它的服务发布和引用流程。

Dubbo中的服务发布和引用

Dubbo中的服务发布

Dubbo中的服务发布基本遵循上我们前面所抽象的服务发布流程，但也添加了一些优化措施。体现在两方面，一方面是发布的时效性，另一方面是发布的作用范围。

我们先来讨论Dubbo暴露服务的两种时效，一种是延迟暴露，一种是正常暴露。

你可能会问，Dubbo为什么要考虑发布时效这个问题呢？主要原因在于为了提供平滑发布机制。如果Dubbo服务本身还没有完全启动成功，那这时候对外暴露服务是没有意义的，我们可以通过设置延迟时间来确保服务在发布的时间点上就是可用的。

另一方面，在Dubbo中提供了四种发布作用范围的选项。

可以看到，如果我们把scope配置为none，则不发布这个Dubbo服务；如果配置local，则说明该服务只会在当前JVM中进行暴露，从而可以提高服务调用的效率；如果配置scope=remote，那么该服务就会进行远程暴露；而如果不配置或者不配置为以上三种中的任何一种，则Dubbo会既暴露本地服务又暴露远程服务。