Prinzip- und Beispielanalyse des Java-basierten verteilten Service-Frameworks Dubbo

Vorwort

Bevor wir Dubbo vorstellen, wollen wir die Grundkonzepte verstehen:

Dubbo ist ein RPC-Framework, RPC, also Remote Procedure Aufruf (Remote-Prozeduraufruf), das Gegenteil ist der lokale Prozeduraufruf. Vor der verteilten Architektur verwendeten die Einzelanwendungsarchitektur und die vertikale Anwendungsarchitektur lokale Prozeduraufrufe. Es ermöglicht einem Programm, eine Prozedur oder Funktion in einem anderen Adressraum (normalerweise einem anderen in einem Netzwerk gemeinsam genutzten Computer) aufzurufen, ohne dass der Programmierer die Details des Remote-Aufrufs explizit codieren muss. <code>RPC框架，RPC，即Remote Procedure Call（远程过程调用），相对的就是本地过程调用，在分布式架构之前的单体应用架构和垂直应用架构运用的都是本地过程调用。它允许程序调用另外一个地址空间（通常是网络共享的另外一台机器）的过程或函数，并且不用程序员显式编码这个远程调用的细节。

而分布式架构应用与应用之间的远程调用就需要RPC框架来做，目的就是为了让远程调用像本地调用一样简单。

Dubbo框架有以下部件

Consumer

即调用远程服务的服务消费方，消费者需要面向接口编程，知道了哪些接口可以调用了，具体实现需要框架提供一个代理类来为接口提供具体实现，让消费者只管调用什么接口，而具体实现的获取由代理类来处理。

消费者还需要提供调用方法名以及方法的参数值。

但是代理类此时还不知道需要调用哪个服务器上的远程方法，此时需要一个注册中心，通过注册中心获取可以调用的远程服务列表。

远程服务器一般都是集群部署，那么调用哪个服务器则需要通过负载均衡来选择一个最合适的服务器来调用。

同时还需要有集群容错机制，因为各种原因，可能远程调用会失败，此时需要容错机制来重试调用，保证远程调用的稳定性。

同时与服务提供方约定好通信协议和序列化格式，方便通信以及数据传输。

Provider

即暴露服务的服务提供方，服务提供方内部实现具体的接口，然后将接口暴露出去，再将服务注册到注册中心，服务消费方调用服务，提供者接收到调用请求后，通过约定好的通信协议来处理该请求，然后做反序列化，完成后，将请求放入线程池中处理，某个线程接收到这个请求然后找到对应的接口实现进行调用，然后将调用结果原路返回。

Registry

即服务注册与发现的注册中心，注册中心负责服务地址的注册与查找，相当于服务目录，服务提供者和消费者只会再启动时与注册中心交互，注册中心不转发请求，压力小。

注册中心还可以集中化处理配置以及动态地将变更通知订阅方。

但是为什么需要注册中心呢？没有注册中心不可以吗？

在没有注册中心，各服务之间的调用关系是这样的：

当服务越来越多时，服务URL配置管理变得非常困难，硬件负载均衡器的单点压力也越来越大，而有了注册中心之后，就可以实现服务的统一管理，并且实现软负载均衡，降低硬件成本，以下为注册中心示意图：

Monitor

即统计服务调用次数和调用时间的监控中心，面对众多服务，精细化的监控和方便的运维是不可或缺的，对后期维护相当重要。

Container

即服务运行的容器。

架构

图中的各个节点充当的角色已经介绍过了，以下是各节点之间调用关系：

Container服务容器负责启动，加载以及运行

Provider服务提供者Provider服务提供者启动时，需要将自身暴露出去让远程服务器可以发现，同时向Registry注册中心注册自己提供的服务

Consumer服务消费者启动时，向Registry注册中心订阅所需要的服务

Registry

Remote-Aufrufe zwischen Anwendungen mit verteilter Architektur erfordern das RPC-Framework, um Remote-Aufrufe so einfach wie lokale Aufrufe zu machen. 🎜🎜🎜 🎜 Das Dubbo-Framework verfügt über die folgenden Komponenten:

Consumer

🎜Das heißt, der Service-Consumer, der Remote-Services aufruft, muss schnittstellenorientiert programmieren, um zu wissen, welche Schnittstellen aufgerufen werden können Eine Proxy-Klasse für die Schnittstelle stellt eine bestimmte Implementierung bereit, sodass Verbraucher einfach die Schnittstelle aufrufen können, und der Erwerb der spezifischen Implementierung wird von der Proxy-Klasse übernommen. 🎜🎜Verbraucher müssen außerdem den Namen der aufrufenden Methode und die Werte der Methodenparameter angeben. 🎜🎜Aber die Proxy-Klasse weiß zu diesem Zeitpunkt noch nicht, welche Remote-Methode auf dem Server aufgerufen werden muss. Zu diesem Zeitpunkt ist ein Registrierungscenter erforderlich, um eine Liste der Remote-Dienste zu erhalten, die aufgerufen werden können. 🎜🎜Remote-Server werden im Allgemeinen in Clustern bereitgestellt. Daher ist für den anzurufenden Server ein Lastausgleich erforderlich, um den am besten geeigneten anzurufenden Server auszuwählen. 🎜🎜Gleichzeitig ist auch ein Cluster-Fehlertoleranzmechanismus erforderlich. Aus verschiedenen Gründen können Remote-Anrufe fehlschlagen. Zu diesem Zeitpunkt ist ein Fehlertoleranzmechanismus erforderlich, um den Anruf erneut zu versuchen, um die Stabilität des Remote-Anrufs sicherzustellen . 🎜🎜Gleichzeitig vereinbaren Sie mit dem Dienstanbieter das Kommunikationsprotokoll und das Serialisierungsformat, um die Kommunikation und Datenübertragung zu erleichtern. 🎜

Anbieter

🎜Das heißt, der Dienstanbieter stellt den Dienst intern bereit, stellt dann die Schnittstelle bereit und registriert den Dienst dann im Registrierungscenter Nachdem die Anrufanforderung empfangen wurde, wird sie über das vereinbarte Kommunikationsprotokoll verarbeitet und anschließend deserialisiert. Anschließend wird die Anforderung zur Verarbeitung in den Thread-Pool gestellt findet die entsprechende aufzurufende Schnittstellenimplementierung und gibt dann das Aufrufergebnis auf den ursprünglichen Pfad zurück. 🎜

Registrierung

🎜Es ist das Registrierungszentrum für die Registrierung und Suche von Dienstadressen, das dem Dienstverzeichnis entspricht und nur miteinander interagiert mit der Registrierungsstelle, wenn sie gestartet werden. Die Registrierungsstelle leitet keine Anfragen weiter, daher besteht wenig Druck. 🎜🎜🎜 🎜 Das Registrierungscenter kann auch die Konfiguration zentral verwalten und Abonnenten dynamisch über Änderungen informieren. 🎜🎜Aber warum brauchen wir ein Registrierungszentrum? Geht das nicht ohne Registrierungsstelle? 🎜🎜In Ermangelung eines Registrierungszentrums ist die Aufrufbeziehung zwischen den Diensten wie folgt: 🎜🎜🎜🎜Wenn es immer mehr Dienste gibt, wird die Verwaltung der Dienst-URL-Konfiguration sehr schwierig, und auch der Einzelpunktdruck auf den Hardware-Lastausgleich nimmt zu Mit dem Registrierungscenter kann eine einheitliche Verwaltung der Dienste erreicht, ein sanfter Lastausgleich erreicht und die Hardwarekosten gesenkt werden. Das Folgende ist ein schematisches Diagramm des Registrierungscenters: 🎜🎜🎜

Überwachen

🎜Das heißt, Das Überwachungszentrum, das die Anzahl der Serviceanrufe und die Anrufzeit zählt. Angesichts vieler Dienste sind eine verfeinerte Überwachung sowie eine komfortable Bedienung und Wartung unverzichtbar und für die spätere Wartung sehr wichtig. 🎜

Container

🎜Der Container, auf dem der Dienst ausgeführt wird. 🎜🎜Architektur🎜🎜🎜🎜Die Rollen, die jeder Knoten in der Abbildung spielt, wurden vorgestellt. Das Folgende ist die Aufrufbeziehung zwischen jedem Knoten: 🎜🎜ContainerDer Dienstcontainer ist für das Starten, Laden und Ausführen verantwortlich🎜🎜Provider Service ProviderProviderWenn der Dienstanbieter startet, muss er sich selbst offenlegen, damit der Remote-Server ihn erkennen und gleichzeitig die von ihm bereitgestellten Dienste mit dem Registry-Registrierungscenter🎜 🎜Wenn der Consumer-Dienstkonsument startet, abonniert er das Registry-Registrierungscenter für die erforderlichen Dienste 🎜🎜Registry Das Registrierungszentrum gibt die Dienstanbieterliste an den Verbraucher zurück. Wenn sich gleichzeitig Änderungen ergeben, überträgt das Registrierungszentrum Echtzeitdaten basierend auf langen Verbindungen an die Verbraucher<p>Wenn der Dienstkonsument einen Remote-Dienst anrufen muss, wählt er basierend auf dem anzurufenden Lastausgleichsalgorithmus einen Anbieterserver aus der Adressliste des Anbieters aus. Wenn der Anruf fehlschlägt, wird der Anruf basierend auf der Cluster-Fehlertoleranzstrategie wiederholt </p>Serviceverbrauch Der Betreiber und Anbieter zählt die Anzahl der Anrufe und die Anrufzeit im Speicher und sendet die Daten dann über geplante Aufgaben an das Überwachungszentrum <code>Monitor

Hohe Verfügbarkeit

• Monitor监控中心

  高可用性

  • 监控中心宕机后不会对服务造成影响，只是丢失部分统计数据

  • 注册中心集群后，任意一台宕机后，将自动切换到其他注册中心

  • 当所有注册中心均宕机后，服务提供者和消费者之间仍然能通过本地记录了彼此信息的缓存进行通讯，但是如果一方产生变更，另外一方无法感知

  • 服务提供者无状态，任意一台服务器宕机后不影响使用，会有其他服务提供者提供服务

  • 当所有服务提供者宕机后，服务消费者无法正常使用，将进行无限次重连等待服务提供者重新连线恢复

  框架设计

  

  大的分层为Business（业务逻辑层）、RPC层和Remoting层。

  再细分下来，Dubbo一共有十层架构，作用分别如下：

  Service，业务层，即日常开发中的业务逻辑层

  Config，配置层，对外配置接口，以ServiceConfig 和ReferenceConfig为中心，可以直接初始化配置类，也可以通过Spring解析配置生成配置类

  Proxy，服务代理层，服务接口透明代理，生成服务的客户端Stub和客户端Skeleton，负责远程调用和返回结果

  Registry，注册中心层，封装服务地址的注册与发现，以服务URL为中心，拓展接口为RegistryFactory，Registry，RegistryService

  Cluster路由和集群容错层，封装了多个提供者的路由、负载均衡以及集群容错，并桥接注册中心，负责通过负载均衡选取调用具体的节点，处理特殊调用请求和负责远程调用失败的容错措施

  Monitor，监控层，负责监控统计RPC调用次数和调用时间

  Portocol，远程调用层，主要封装RPC远程调用方法

  Exchange，信息交换层，用于封装请求响应模型

  Transport，网络传输层，抽象化网络传输统一接口，有Mina和Netty可供使用

  Serialize，序列化层，将数据序列化成二进制流进行传输，也可以反序列化接收数据

  服务暴露过程

  首先Provider启动，Protocal通过Proxy代理将需要暴露的接口封装成Invoker，是一个可执行体，然后通过Exporter包装并发送到注册中心完成注册，至此服务就暴露完成。

  

  服务消费过程

  

  注：上图中蓝色部分为服务消费者，绿色部分为服务提供者。

  服务消费者启动时会向注册中心订阅并拉取所需服务提供者的信息，并保存到本地缓存，由此即使所有注册中心宕机后，服务提供者和服务消费者也可以通过本地缓存进行通讯，只是一方出现了信息变更，另一方无法感知，但并不影响服务的进行。

  之后整个服务消费流程从图中的Proxy开始，由代理类完成处理，以此到达透明无感知。

  ProxyFactory生成一个Proxy代理类，Proxy持有一个Invoker可执行对象，调用invoke之后需要通过Cluster从Directory中获取所有可调用的远程服务Invoker列表，如果配置了某些路由规则，还需要再过滤一遍Invoker列表。

  剩下的Invoker再通过LoadBalance做负载均衡选取一个，还需要再通过Filter进行一些数据统计，之后将这些数据保存下来，定时发送给Monitor。

  接下来用Client做数据传输，一般用Netty进行传输。

  传输需要通过Codec接口进行协议构造，然后再通过SerializationNachdem das Überwachungszentrum ausgefallen ist, hat dies keine Auswirkungen auf den Dienst, aber einige statistische Daten gehen verloren

• 🎜Nach der Registrierung des Zentrums Cluster: Wenn eines ausfällt, wechselt es automatisch zu anderen Registrierungszentren🎜
• 🎜Wenn alle Registrierungszentren ausfallen, können Dienstanbieter und Verbraucher weiterhin über Caches kommunizieren, die die Informationen des anderen lokal aufzeichnen. Wenn sich eine Partei ändert, kann die andere Partei dies nicht erkennen. 🎜
• 🎜Der Dienstanbieter ist zustandslos. Wenn ein Server ausfällt, hat dies keine Auswirkungen auf die Nutzung. Es gibt keine anderen Dienstanbieter, die Dienste bereitstellen /li>
• 🎜Wenn alle Dienste bereitgestellt werden. Nachdem der Dienstanbieter ausgefallen ist, kann der Dienstkonsument ihn nicht normal nutzen und stellt auf unbestimmte Zeit eine erneute Verbindung her und wartet darauf, dass der Dienstanbieter die Verbindung wiederherstellt und wieder aufnimmt🎜

Framework-Design

🎜🎜🎜Die große Schicht ist Business (Geschäftslogikschicht), RPC-Schicht und Remoting-Schicht. 🎜🎜Weiter aufgeschlüsselt verfügt Dubbo über insgesamt zehn Architekturschichten und die Funktionen sind wie folgt: 🎜🎜Service, Geschäftsschicht, die die Geschäftslogikschicht in der täglichen Entwicklung ist🎜🎜Config, Konfigurationsschicht, externe Konfigurationsschnittstelle, zentriert auf ServiceConfig und ReferenceConfig, die Konfigurationsklasse kann direkt initialisiert oder die Konfigurationsklasse durch generiert werden Spring analysiert die Konfiguration🎜🎜Proxy, Service-Proxy-Schicht, transparenter Proxy der Service-Schnittstelle, generiert Service-Client Stub und Client Skeleton, verantwortlich für Remote-Aufrufe und Ergebnisse zurückgeben 🎜🎜 Registry, die Registrierungscenterschicht, kapselt die Registrierung und Erkennung von Dienstadressen, mit der Dienst-URL als Zentrum, und die erweiterten Schnittstellen sind RegistryFactory, Registry, RegistryService🎜🎜<code>ClusterDie Routing- und Cluster-Fehlertoleranzschicht kapselt das Routing, den Lastausgleich und die Cluster-Fehlertoleranz mehrerer Anbieter und Bridges das Registrierungszentrum, das für die Auswahl und den Anruf bestimmter Knoten durch Lastausgleich und die Verarbeitung spezieller Anrufanfragen und Fehlertoleranzmaßnahmen für Remote-Anruffehler verantwortlich ist🎜🎜Monitor, Überwachungsschicht, verantwortlich für die Überwachung und Zählung die Anzahl der RPC-Aufrufe und die Aufrufzeit🎜🎜Portocol, Remote-Anrufschicht, kapselt hauptsächlich die RPC-Remote-Aufrufmethode 🎜🎜Exchange, Informationsaustauschschicht, die zur Kapselung der Anforderung verwendet wird Antwortmodell 🎜🎜Transport, Netzwerktransportschicht, abstrahiert die Netzwerkübertragung, eine einheitliche Schnittstelle, wobei Mina und Netty zur Verwendung verfügbar sind🎜🎜Serialize, die Serialisierungsschicht, serialisiert Daten zur Übertragung in einen Binärstrom und kann auch Daten deserialisieren und empfangen. 🎜

Service-Offenlegungsprozess

🎜Zuerst wird der Provider gestartet Schnittstelle, die über den Proxy-Agenten in einem Invoker verfügbar gemacht werden muss. Es handelt sich um einen ausführbaren Körper, der dann über den Exporter verpackt und an das Registrierungszentrum gesendet wird, um die Registrierung abzuschließen. 🎜🎜🎜 Service-Verbrauchsprozess🎜

Das obige ist der detaillierte Inhalt vonPrinzip- und Beispielanalyse des Java-basierten verteilten Service-Frameworks Dubbo. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!