Dez minutos, leve você para dominar rapidamente o design de arquitetura de Dubbo

Quando eu costumava ler código-fonte, muitas vezes ficava atolado em detalhes de implementação. Olhando para ele, não sei para onde foi, mesmo que seja debug, apenas entende o processo de execução do código. Às vezes, mesmo que você entenda na hora, você esquece depois de um tempo.

Mais tarde, à medida que lia cada vez mais código-fonte, descobri que, dividindo a estrutura do módulo do framework e classificando o relacionamento entre cada interface (classe) (herança, implementação, dependência etc.), entendi o princípio de implementação de o código fonte ajudou muito. Por exemplo, ao depurar, a lógica geral de execução pode ser adivinhada, para que o código-fonte possa ser melhor rastreado. Ao mesmo tempo, essa maneira de dividir e classificar também me permite lembrar o princípio de implementação por mais tempo.

Portanto, da perspectiva da arquitetura geral do Dubbo, este artigo o levará a uma visão geral do projeto de arquitetura do Dubbo. Especificamente, este artigo começará com a análise dos componentes básicos do Dubbo, depois continuará a dividir cada módulo e, finalmente, levará você a formar uma compreensão completa do Dubbo, do grosso ao fino, do geral ao detalhe.

Estrutura geral

Vamos começar com os blocos básicos de construção do Dubbo.

Conforme mostrado na figura, o Dubbo consiste em 4 módulos básicos, a saber, Registro, Consumidor, Provedor e Monitor.

• Registro : Registro, usado para registro e descoberta de serviços.
• Consumidor : O consumidor do serviço, o chamador do serviço remoto.
• Provedor : Um provedor de serviço que envolve a implementação do serviço e expõe o serviço.
• Monitor : A central de monitoramento do serviço, que é utilizada para contar informações como número de chamadas e tempo de chamada do serviço.

Abaixo, desmontamos e analisamos os módulos básicos acima um por um.

Centro de Registro

Primeiro desmonte e disseque o módulo de registro.

Conforme mostrado na figura, o centro de registro pode ser dividido em duas partes, uma é o meio de armazenamento de terceiros, que suporta a função de armazenar informações de serviço e notificar alterações de serviço, como Zookeeper, Redis, etc. o centro de registro. A outra é a abstração do registro na estrutura do Dubbo. O Dubbo abstrai o registro como Registryos componentes principais do registro. Depois que esses componentes são introduzidos em Consumere Provider, as operações relacionadas do registro podem ser executadas, como serviços de registro e serviços de assinatura. eventos e mudanças no serviço de notificação, etc.

O registro desmontado neste artigo refere-se ao componente principal do registro no RegistryDubbo .

Como pode ser visto na figura acima, os componentes principais do módulo de registro no Dubbo incluem , Registrye RegistryFactorycomponentes .DirectoryNotifyListener

• Registry: É uma abstração do registro, um Registryrepresenta um registro.
• RegistryFactory: Fábrica de registro, usada para criar no momento da inicialização Registry.
• Directory: Diretório de serviço, usado para atualizar e salvar chamadas remotas Invoker. A rigor, o diretório de serviço é um componente público, que pode ser dividido no registro ou no módulo de tolerância a falhas de serviço abaixo, pois esses dois módulos de função são usados Directory​​(diretório de serviço) .
• NotifyListener: define a notify()interface de notificação ( ), e a classe de implementação desta interface é usada para receber notificações de mudanças de serviço. Na figura , ele implementa e , ao RegistryDirectorymesmo tempo , não apenas implementa as funções de atualização e salvamento disponíveis para chamadas remotas , mas também implementa a função de receber notificações de alteração de serviço.DirectoryNotifyListenerInvoker

Por meio dos componentes principais acima, as funções relacionadas ao registro são realizadas em conjunto, como registrar serviços, assinar eventos de alteração de serviço, notificar alterações de serviço e obter informações de serviço.

consumidores de serviços

O seguinte desmonta e analisa o consumidor do serviço.

Há muito conteúdo em consumidores de serviços, que é analisado separadamente aqui.

上图中，从两个角度剖析了服务消费者。一个是从组成部分的角度，将服务消费者拆分为 Registry、Proxy、Protocol、Cluster、Invoker 和 Client 六大组成部分。另一个是从执行流程的角度，将其分为初始化、请求和响应三步。

官网中，根据组件的定位将其分成了 10 层，拆分的很细。但是我感觉这里如果分的太细会比较琐碎，不好理解，因此我在这里将其分成了 6 个部分。在理解这样划分的基础上，再往更细粒度的拆分，也会更加简单。

下面先从组成部分的角度分析，图中每个虚线大方块都表示一个组成部分。

• Registry：即注册中心，前文已经分析过了，通过RegistryFactory、Registry、Directory、NotifyLisetener联合实现注册中心相关的功能，包括subscribe、register、lookup、notify等。
• Proxy：即服务代理，用于代理依赖的接口。在使用过程中，通过<dubbo:reference />标签配置完依赖的接口后，就会生成一个代理。当调用接口时，实际上调用的是这个代理类。
• Protocol：服务协议，它相当于一个中间层，用于封装 RPC 调用。它在初始化时会创建用于远程调用的Invoker，并通过调用Client模块与服务端建立连接。
• Cluster：服务集群，内部的主要功能是服务容错。内部包括了Cluster、ClusterInvoker、Directory、Router和LoadBalance等组件。
• Invoker：服务调用者，其内部通过调用Client模块，完成与服务端的通讯(请求和响应)。
• Client：客户端模块，我将Exchanger、Transporter、Client、Serialize等组件全部都划到了客户端模块里，因为这些组件共同实现了connect（与服务端建立连接）、request（发送双向通讯请求）、send（发送单向通讯请求）和received（接收响应消息）等功能。

下面再从执行流程的角度分析，图中的红色箭头表示初始化流程，绿色箭头表示发送请求流程，蓝色箭头表示接收响应结果流程。

初始化流程

如上图所示，初始化流程从ReferenceConfig发起，其最终目的是生成Proxy服务代理。过程中，先通过Registry注册中心订阅服务变更事件，并在第一次初始化时主动执行notify通知服务变更，通过DubboProtocol调用Client模块与服务端建立连接，并生成DubboInvoker。同时，生成用于服务容错的ClusterInvoker。其中在Client模块中建立与服务端的连接时，依次通过Exchanger和Transporter组件，最终通过Client组件完成与服务端的网络连接。

发送请求流程

当调用<dubbo:reference />标签配置的依赖的接口时，实际上是调用的Proxy域中的服务代理。

在调用过程中，Proxy会通过Cluster服务容错模块调用DubboInvoker，DubboInvoker最终通过Client组件向服务提供者发送请求。其中服务容错的功能由Directory、Route和LoadBalance等组件共同组合完成；DubboInvoker在发送请求后会通过AsyncToSyncInvoker阻塞等待结果；Client向服务提供者发送消息之前，要通过Serialize组件对请求消息进行编码。

接收响应结果流程

服务提供者处理完请求后，会向服务提供者发送响应结果。服务消费者接收到响应数据后，先通过Serialize组件对响应消息解码，然后通过ChannelHandler组件将响应结果分发到服务消费者的线程池里，最终唤醒上一步阻塞等待结果的AsyncToSyncInvoker。最后，将响应结果返回给接口调用方。

服务提供者

下面拆解并剖析服务提供者。 和剖析服务消费者一样，这里也是从两个角度剖析了服务提供者。一个是从组成部分的角度，将服务提供者拆分为 Registry、Proxy、Protocol、Invoker 和 Server 五大组成部分。另一个是从执行流程的角度，将其分为初始化、接收并处理请求和发送响应结果三步。

服务提供者的组成部分在剖析服务消费者的时候大部分都解释过了，这里只说下不同之处。

1. 通讯模块，在服务消费者中叫 Client 模块，而在服务提供者中叫 Server 模块，里面的组件基本相同。
2. 服务消费者中有 Cluster 集群容错模块，而服务提供者中没有。
3. 在 Invoker 模块中，服务消费者中的Invoker是DubboInvoker，相对来说内容较多，封装了远程调用；服务提供者中的Invoker是AbstractProxyInvoker，内容较简单，用于调用本地生成的Proxy。
4. Proxy 模块中，服务消费者的配置类是ReferenceConfig，服务提供者的配置类是ServiceConfig。
5. Proxy 模块中，服务消费者的代理类用于封装调用远程方法的细节，服务提供者的代理类用于调用本地实现类。

下面再从执行流程的角度分析，图中的红色箭头表示初始化流程，绿色箭头表示接收并处理请求流程，蓝色箭头表示发送响应结果流程。

初始化流程

服务提供者的初始化流程，是从 Proxy 模块中的ServiceConfig发起的。它首先通过 Protocol 模块调用Server 模块，启动服务；然后生成用于调用本地实现类的 Proxy，并创建用于调用 Proxy 的AbstractProxyInvoker；最后通过 Registry 模块，将服务信息注册到注册中心。

接收并处理请求流程

服务提供者的 Server 接收到请求后，首先通过Seralize组件解码，然后交给ChannelHandler处理，在ChannelHandler的处理过程中，分发到ThreadPool中进行业务处理。

HeaderExchangeHandler进行最终的业务处理调度，通过ExchangeHandler和AbstractProxyInvoker调用本地代理和本地实现，并得到最终的业务处理结果。

发送响应结果流程

HeaderExchangeHandler得到业务结果后，通过Channel向Server的对端（服务消费者）发送响应结果。在将响应结果发送到对端（服务消费者）之前，会通过Seralize组件对响应结果编码。

发送完成之后，就走到了前文中服务消费者接收响应结果流程。

总结

根据以上的分析结果，Dubbo 整体架构如下图所示。

从组成模块层面分析，Dubbo 包括注册中心、服务消费者、服务提供者和监控中心四大模块。注册中心包括两部分，一个是用于存储和通知服务信息的第三方存储媒介，另一个是 Dubbo 框架中抽象出的 Registry 模块。服务消费者由 Proxy、Protocol、Cluster、Invoker、Registry 和 Client 六大模块组成。服务提供者由 Proxy、Protocol、Invoker、Registry 和 Server 五大模块组成。

从整体的执行流程上分析。

• 服务提供者初始化，启动服务，生成本地服务代理，并将服务注册到注册中心里。
• 服务消费者初始化，连接服务提供者，订阅服务注册中心中的变更事件，接收服务变更通知，生成远程调用的服务代理。
• O consumidor de serviço envia uma solicitação e envia a mensagem de solicitação ao provedor de serviços por meio de processos como tolerância a falhas de serviço, invocação remota e codificação de mensagem.
• O provedor de serviços recebe os dados da solicitação e obtém o resultado do processamento de negócios por meio do processo de decodificação de mensagens, processamento de distribuição e implementação local de chamada.
• Depois que o provedor de serviços obtém o resultado do processamento de negócios, ele codifica a mensagem de resposta e envia o resultado da resposta ao consumidor do serviço por meio do Canal.
• O consumidor do serviço recebe o resultado da resposta, decodifica o resultado da resposta e ativa a espera de bloqueio da chamada remota.
• O chamador de negócios obtém o resultado final da chamada remota.
• Além disso, no módulo do centro de monitoramento, as estatísticas de agendamento serão carregadas regularmente no centro de monitoramento.

Até agora, a arquitetura geral do Dubbo foi introduzida. Ao analisar o princípio de implementação do Dubbo posteriormente, continuaremos a seguir as ideias deste artigo e realizaremos uma análise detalhada da perspectiva do processo de execução e dos componentes principais.

Dicas gentis

Este artigo é uma análise geral da arquitetura Dubbo de uma perspectiva global. É uma visão geral de alto nível da estrutura Dubbo. Ele não inclui detalhes de implementação, portanto, o conteúdo é relativamente denso. Se você não conhece o Dubbo antes, ele pode parecer difícil.

Se você conhece o Dubbo, mas ainda está um pouco confuso sobre este artigo, isso é perfeitamente normal. Sugiro que volte a esta seção depois de ler os seguintes artigos, será muito fácil. Até então, você definitivamente terá sentimentos mais diferentes.

Para entender sistematicamente os princípios de design e implementação da arquitetura Dubbo, leia: "Análise detalhada dos princípios de implementação e design da arquitetura Dubbo"

Declaração de direitos autorais: Este artigo foi publicado na plataforma Nuggets em 17 de agosto de 2022, por favor, não reimprima!