Dubbo ソースコード分析: 初心者ガイド

すでに Dubbo の使用に習熟している場合は、これをご覧くださいこの記事はあなたには適していませんが、Dubbo を理解し、Dubbo を学びたい場合には、この記事は次のような人に非常に適しています。あなた。

ダボとは何ですか?

Dubbo は最初に Alibaba によって開発され、後に Apache に貢献したため、後で ## と呼びます。 Dubbo または単に Dubbo に電話してください。

は、高性能で軽量なオープンソース サービス フレームワークです。

間違った発音: diubo、dubo

正しい発音: |ˈdʌbəʊ|

Dubbo の 6 つのコア コンピテンシー

• インターフェースの高性能プロキシ##RPCコール
インテリジェントなフォールトトレランスと負荷分散
• サービスの自動登録と検出
• 高度なスケーラビリティ機能
• ランタイム トラフィック スケジューリング
• サービス ガバナンスと運用保守の視覚化。
• 開発中、私たちは皆、
Dubbo

#RPC オープン ソース フレームワークと呼ぶことを好みます。 RPC とは何ですか?

RPC

Remote Procedure Call の省略形で、翻訳すると リモート プロシージャ コール となります。 単純に理解すると、あるノードが別のノードによって提供されるサービスを要求します。

平たく言えば:

2 台のサーバー A と B。サーバー A にアプリケーション serverA をデプロイし、サーバー B にアプリケーション serverB をデプロイします。このとき、serverA は serverB で特定のメソッドを呼び出したいと考えています。同じサーバー内にないため、直接呼び出すことはできません。呼び出しのセマンティクスを表現し、呼び出しデータを送信する必要があります。ネットワーク。

リモート メソッドの呼び出しは、ローカル メソッドの呼び出しと同じです。

私たちの開発では、2 つのサービス (異なるサーバー上のサービス) 間の呼び出しは通常、HTTP REST を使用します。

RPC フレームワーク

実際、市場には多くの RPC フレームワークがあり、Dubbo はそのうちの 1 つにすぎません。例えば： ＃＃＃

• gRPC は、Google によって開発された高性能の汎用オープンソース RPC フレームワークです。gRPC は、ProtoBuf を使用してサービスを定義します。ProtoBuf は、Google によって開発された、比較的高いパフォーマンスと圧縮率を備えたデータシリアル化プロトコルです。伝送効率が高く、構文が比較的単純です。さらに、gRPC は複数の言語をサポートしており、言語に基づいてクライアントとサーバーの関数ライブラリを自動的に生成できます。
• Thrift は Facebook で生まれ、Dubbo と同様に、後に Thrift をオープンソース プロジェクトにするために Apache Foundation に提出されました。 Facebook は、Facebook システム間の大量のデータ送信と通信の問題、およびクロスプラットフォームの問題を必要とするシステム間の異なる言語環境の問題を解決するために Thrift を作成しました。
• Motan は、Sina Weibo によってオープンソース化された Java RPC フレームワークです。公式ドキュメントは公開され、Weibo プラットフォームで広く使用されており、毎日数百のサービスに対して 1,000 億件近くの呼び出しを完了しています。 。
• ...

ダボコアキャラクター

やってみようDubbo アーキテクチャの中核となる役割を見てみましょう:

この写真は公式 Web サイトからのものです。画像の簡単な紹介:

レジストリ

登録センター。サービス アドレスの登録と検索を担当します。サービスの Provider と Consumer は、起動時にのみ登録センターと対話します。登録センターは、長い接続を通じて Provider の存在を感知します。Provider がダウンすると、登録センターは関連するイベント通知を Consumer に即座にプッシュします。

プロバイダー

サービスプロバイダー。起動すると、レジストリに登録され、独自のサービスのアドレスと関連する構成情報が URL にカプセル化され、ZooKeeper に追加されます。

コンシューマ

サービスコンシューマ。起動すると、レジストリに登録されます。サブスクリプション操作では、プロバイダーに登録された URL を ZooKeeper から取得し、対応するリスナーを ZooKeeper に追加します。プロバイダ URL を取得した後、コンシューマ は、負荷分散アルゴリズムに基づいて複数の プロバイダ から 1 つの プロバイダ を選択し、それとの接続を確立し、最終的に接続を開始します。 プロバイダー の RPC 呼び出しに接続します。 プロバイダー URLが変更された場合、コンシューマーは、前のサブスクリプションプロセス中に登録センターに追加されたリスナーを通じて最新のプロバイダーURL情報を取得し、接続の切断などの対応する調整を行います。ダウンした プロバイダー を削除し、新しい プロバイダー への接続を確立します。Consumer は Provider との長い接続を確立し、Consumer は Provider 情報をキャッシュするため、接続が確立されると、たとえ登録センターがダウンしていても、既存の接続には影響しません。Provider と Consumer を実行します。

監視

監視センター。サービスコールの回数やコール時間をカウントするために使用されます。実行プロセス中、Provider と Consumer はメモリ内の通話数と通話時間をカウントし、統計データを毎分定期的に監視センターに送信します。監視センターは、上記のアーキテクチャ図では必要な役割を果たしません。監視センターのダウンタイムは、Provider、Consumer、Registry の機能には影響しません。 、監視のみが失われ、データだけが失われます。

淫らに展開し後半爆発します(序盤はあまり気にならないかもしれませんが後半は特に香ばしいです)

コンテナ:

サービス実行コンテナ。これは独立したコンテナです。通常、サービスは Tomcat や JBoss などの Web コンテナの機能を必要としないため、サービスをロードするために Web コンテナを使用する必要はありません。サービス コンテナは単純な main メソッドであり、サービスを公開するために単純な Spring コンテナをロードします。

処理説明

上の図では、複数の文字とたくさんの線が描かれていますが、これを簡単に説明します。

• サービス コンテナは、サービス プロバイダーの起動、読み込み、および実行を担当します。
• サービス プロバイダーは、開始時に、提供するサービスを登録センターに登録します。
• サービス利用者は、サービスを開始するときに、必要なサービスの登録センターに登録します。
• #登録センターはサービス プロバイダーのアドレス リストをコンシューマに返します。変更がある場合、登録センターは長い接続に基づいて変更データをコンシューマにプッシュします。
• サービス コンシューマーは、ソフト ロード バランシング アルゴリズムに基づいて、プロバイダー アドレス リストから呼び出すプロバイダーを選択します。呼び出しが失敗した場合は、呼び出す別のプロバイダーを選択します。
• サービス利用者とプロバイダーは、通話回数と通話時間をメモリに蓄積し、統計データを毎分監視センターに定期的に送信します。

ダボ公式ウェブサイト

ダボの公式ウェブサイト: https: //dubbo .apache.org/

Dubbo は Alibaba 技術チームによって開発されているため、用語的には私たち中国人にとって、それはとてもフレンドリーです。

その他、ダボ公式サイトにはたくさんのことが載っているので、ここではいちいち紹介しません。

皆さんも公式ウェブサイトにアクセスすることをお勧めします。

早速、 まずは楽しんでみましょう!

デモ ケース 1

登録センターのないケースから始めましょう。

プロジェクトを構築し、3 つの モジュールを作成します:

• ##dubbo-demo
• dubbo-demo-api
• ##dubbo-demo-provider
• # #dubbo-demo-consumer
プロジェクトの全体的な構造は次のとおりです:

それでは、コードについて簡単に説明しましょう。

最初は pom 依存関係です:

<!--dubbo的依赖-->
<dependency>
     <groupId>org.apache.dubbo</groupId>
     <artifactId>dubbo</artifactId>
     <version>3.0.4</version>
</dependency>
<!-- provider和consumer共用类-->
<dependency>
     <groupId>com.tian.dubbo</groupId>
     <artifactId>dubbo-demo-api</artifactId>
     <version>1.0-SNAPSHOT</version>
</dependency>

コンシューマー プロジェクトとプロバイダー プロジェクトの両方で、これら 2 つの依存関係を追加する必要があります。

api

api は主にサービス インターフェイスといくつかのツール クラスを定義しており、これらは主にコンシューマーとプロバイダーによって共有されます。

API では、サービス インターフェイスを 1 つだけ定義します: DemoService

package com.tian.dubbo.service;

public interface DemoService {
    String sayHello(String msg);
}

次に、それを jar に入力し、コンシューマの pom.xml に追加します。プロバイダー プロジェクト 依存関係では、最後の 2 回を使用できます。

provider

リソース ディレクトリに META-INF.spring ディレクトリを作成し、そのディレクトリに application.xml を作成します。次の内容:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
       xsi:schemaLocation="http://www.springframework.org/schema/beans        http://www.springframework.org/schema/beans/spring-beans.xsd        http://code.alibabatech.com/schema/dubbo        http://code.alibabatech.com/schema/dubbo/dubbo.xsd">
    <!--Dubbo服务名称--> 
    <dubbo:application name="dubbo-provider"/>
    <!--不需要注册到服务注册中心--> 
    <dubbo:registry address="N/A"/>
    <!--端口和协议--> 
    <dubbo:protocol name="dubbo" port="20880"/>
    <!--我们的服务--> 
    <dubbo:service interface="com.tian.dubbo.service.DemoService" ref="demoService"/>
    <bean id="demoService" class="com.tian.dubbo.service.DemoServiceImpl"/>
</beans>

リソース ディレクトリにログ出力設定ファイルを作成します: log4j.properties

###set log levels###
log4j.rootLogger=debug, stdout
###output to the console###
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=[%d{dd/MM/yy HH:mm:ss:SSS z}] %t %5p %c{2}: %m%n

ビジネス実装クラスを定義します: DemoServiceImpl

package com.tian.dubbo.service;

public class DemoServiceImpl implements DemoService {
    public String sayHello(String msg) {
        System.out.println("msg= " + msg);
        return "SUCCESS";
    }
}

次に、プロバイダー起動クラスを定義します: ProviderMain

package com.tian.dubbo;

import org.apache.dubbo.container.Main;

public class ProviderMain {
    public static void main(String[] args) {
        Main.main(args);
    }
}

注意：这里的Main类是Dubbo

最后，我们启动ProviderMain类，日志输出：

好了，已经启动成功了。

我们继续来看看consumer项目，在项目中，也就是调用我们服务的项目。

consumer

在consumer项目中application.xml配置文件和provider有所区别。

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
       xsi:schemaLocation="http://www.springframework.org/schema/beans        http://www.springframework.org/schema/beans/spring-beans.xsd        http://code.alibabatech.com/schema/dubbo        http://code.alibabatech.com/schema/dubbo/dubbo.xsd">
    <!-- 服务名称-->
    <dubbo:application name="dubbo-consumer"/>
    <!--不需要注册到服务注册中心--> 
    <!-- 通过url直接调用-->
    <dubbo:reference id="demoService"
                     interface="com.tian.dubbo.service.DemoService"
     url="dubbo://127.0.0.1:20880/com.tian.dubbo.service.DemoService"/>
</beans>

这个url地址，我们在provider启动的时候，可以从日志中找到。

日志文件和provider一样，然后就是ConsumerMain启动类了。

package com.tian.dubbo;

import com.tian.dubbo.service.DemoService;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class ConsumerMain {
    public static void main(String[] args) {
        DemoService demoService = null;
        ApplicationContext context = new ClassPathXmlApplicationContext
                ("classpath:META-INF/spring/application.xml");
        demoService = context.getBean(DemoService.class);
        //调用服务
        System.out.println(demoService.sayHello("tian"));
    }
}

前面，我们已经把provider成功启动了，下面我们就来启动ConsumerMain。

从日志可以看出我们已经成功调用了provider，我们再来看看provider的日志输出：

也成功的输出了我们想要的。

到此，一个简单的入门无注册中心（通过url直接调用）的方式就完成了。

url は、登録センターへの依存を取り除くため、共同デバッグを開発するときに依然として非常に役立ちます。

デモ ケース 2

これまで登録センターのデモを行ったことはありませんでしたが、今回は登録センターのデモを行います。

Dubbo 現在、市場のほぼすべての登録センターをサポートしています:

• consul
• #zookeeper
• eureka
• redis
• etcd
• nacos
• ....

実際の開発では、ほとんどの Dubbo 登録センターが使用されます 動物園の飼育員とナコス。

以下は Zookeeper に基づくデモンストレーションです (nacos も同様で、これについては後述します)。

コードレベル

前のケースに基づいて修正しました。変換では 2 か所を調整するだけで済みます:

• consumer和provider中添加pom依赖
• application.xml中添加注册中心

pom依赖

我们需要在前面demo中consumer和provider的pom.xml中添加Zookeeper的依赖：

<dependency>
     <groupId>org.apache.dubbo</groupId>
     <artifactId>dubbo-dependencies-zookeeper</artifactId>
     <version>3.0.4</version>
     <type>pom</type>
</dependency>

provider端

在provider项目中我们需要调整：

<dubbo:registry address="N/A"/>

改成：

<dubbo:registry address="zookeeper://127.0.0.1:2181" timeout="10000"/>

这个timeout建议配上，我这里其实没必要配，因为dubbo服务和Zookeeper都在我本地。

然后我们启动provider项目：

看到我们的项目已经启动成功，并且已经注册到Zookeeper上了。

我们可以使用Zookeeper的可视化工具，看看注册上去的信息。

我们再看看consumer端的调整。

consumer端

我们需要在application.xml中添加

<dubbo:registry address="zookeeper://127.0.0.1:2181" timeout="10000"/>

同时，去掉reference中的url：

<dubbo:reference id="demoService"
                     interface="com.tian.dubbo.service.DemoService"
     url="dubbo://127.0.0.1:20880/com.tian.dubbo.service.DemoService"/>

因为是通过Zookeeper注册中心拿到地址，所以这里的url就可以去掉了。

最后，启动ConsumerMain类：

可以看到我们也成功调用服务，另外也有大量的Zookeeper日志。

到此，说明，我们的Zookeeper为注册中心的demo案例也成功了。

注意：provider和consumer项目都需要依赖相关jar包（api、zookeeper、dubbo）

其他

关于Nacos，我们这里就不演示了，因为太简单了，如果你把Nacos搭建好了后，直接配置就好了。

<dubbo:registry address="nacos://127.0.0.1:8848" timeout="10000"/>

就是把address地址改一下就可以了。

Nacos 的演示，我们下一篇文章中见。

总结

本文分享了Dubbo入门案例的两个版本：无注册中心和Zookeeper注册中心。