3. Dubbo の登録とサブスクリプションの原則の分析

コース概要：

分散プロジェクト開発と共同デバッグ
管理職の経歴の使用を制御する
ダボ登録センターの詳しい説明

1. 分散プロジェクト開発と共同デバッグ

インターフェースの公開とリファレンス

RPC シナリオでは、呼び出し元はインターフェイスを通じてサーバーを呼び出し、パラメーターを渡し、返された結果を取得します。このようにして、サーバーのインターフェイスとモデルを呼び出し元のプロジェクトに公開する必要があります。サーバーはどのように公開されるのでしょうか? クライアントはそれをどのように参照しますか?

インターフェース情報

、機種情報

、異常な

インターフェイスを公開する通常の方法は、インターフェイスを実装から分離することであり、サーバーはインターフェイス、モデル、例外などを 1 つのモジュールに配置し、実装を別のモジュールに配置します。呼び出し元は Maven を通じて参照されます。

ビルドを自動化して共同作業する

プロジェクトが増え、サービスの依存関係がますます複雑になると、コラボレーションの効率を向上させるために、自動化ツールを使用して、インターフェースの作成から JAR パッケージの構築、そして最終的にそれらの引用までのプロセス全体を完了する必要があります。

過程説明：

サービスプロバイダーのプロジェクト開発者はクライアントインターフェイスを作成します
遠隔倉庫にプッシュ
jenkins ビルド指定バージョン
Jenkins のプライベートサーバーウェアハウスネクサスへのデプロイ
サービスコンシューマープロジェクト開発者は、Maven に基づいてプライベートサービスウェアハウスからダウンロードします

インターフェイスのスムーズなアップグレード:

プロジェクトの反復プロセスでは、同じインターフェイスに依存する複数のプロジェクトが存在することがよくあります。次の図に示すように、プロジェクト B と C は両方ともプロジェクト A のインターフェイス 1 に依存しています。このとき、プロジェクト B のビジネスニーズには、インターフェイス 1 の追加パラメータ。アップグレードが完了した後。プロジェクト B は正しくビルドして起動できますが、プロジェクト C はできません。

解決策と原則:

インターフェイスは下位互換性がある必要があります。インターフェイスパラメータは可能な限りオブジェクトの形式でカプセル化する必要があります。Model 属性は追加のみ可能ですが、削除はできません。無効にする必要がある場合は、@Deprecated マークを追加できます。
互換性のない変更がある場合は、呼び出し元に修正して起動計画を立てるように通知する必要があります。

開発共同デバッグ:

プロジェクトの開発プロセス中、開発環境またはテスト環境の登録センターは同時に複数のサービスを実行する可能性があります。2 つのサービスセットが共同でデバッグされている場合、ターゲットサービスが確実に呼び出されるようにするにはどうすればよいでしょうか?

1. 一時的なグループ化に基づく共同デバッグ

グループ分け

リファレンスとサーバーで同じ一時グループを使用し、グループごとに設定します

2. 直接接続プロバイダー:

直接接続するには、参照にプロバイダーの URL を指定します。

<dubbo:reference  url="dubbo://127.0.0.1:20880" id="demoService"
                  timeout="2000"
                  interface="com.tuling.teach.service.DemoService" check="false"/>

3. 登録のみ:

プロジェクトは、サービスプロバイダーであると同時にコンシューマーである可能性があります。テスト時には、特定のサービスを呼び出す必要があると同時に、開発中のサービスが他のサブスクライバーに影響を与えないようにする必要があります。それを実装するにはどうすればよいですか?

<dubbo:registry address="multicast://224.5.6.7:1234" register="false"/>

## 2. Dubbo の制御および管理のバックグラウンド使用

Dubbo コントロールのバックグラウンドバージョンの説明:

2.5.8 バックグラウンド管理者

2.6 ダボ管理者

Dubbo コントロールのバックグラウンドインストール:

#从github 中下载dubbo 项目
git clone https://github.com/apache/incubator-dubbo.git
#更新项目
git fetch
#临时切换至 dubbo-2.5.8 版本
git checkout dubbo-2.5.8
#进入 dubbo-admin 目录
cd dubbo-admin
#mvn 构建admin war 包
mvn clean pakcage -DskipTests
#得到 dubbo-admin-2.5.8.war 即可直接部署至Tomcat
#修改 dubbo.properties 配置文件
dubbo.registry.address=zookeeper://127.0.0.1:2181

注: ビルドするのが本当に面倒な場合は、ビルドしたものを直接ダウンロードできます。

リンク: https://pan.baidu.com/s/1zJFNPgwNVgZZ-xobAfi5eQ抽出コード: gjtv

コントロールバックグラウンドの基本機能の紹介:

サービス検索:
サービス関係を表示します。
サービス重量調整:
運行ルート：
```
服务禁用
```

3.ダボ登録センターの詳しい説明

レジストリの役割

サービスクラスターの動的拡張の目的を達成するために、登録センターはサービスのアドレス情報と利用可能ステータス情報を保存し、関連するサービスに加入しているクライアントにリアルタイムでプッシュします。

完全な登録センターには、次の機能を実装する必要があります。

サーバーの登録とクライアントの参照を受け取り、つまり参照と消費を関連付け、多対多をサポートします。
サービスが異常にシャットダウンした場合、サービスの状態を即座にクリアします
登録センターが再起動されると、登録データとサブスクリプション要求は自動的に復元されます。
レジストリ自体のクラスター

Dubbo がサポートする登録センター

マルチキャストレジストリ
ネットワークブロードキャスト技術に基づいており、ローカルエリアネットワーク内でのみ使用でき、一般に単純なテストサービスに使用されます。
Zookeeper レジストリ (推奨)
Zookeeperは Apacahe Hadoop のサブプロジェクトですチェンジプッシュをサポートするツリー型のディレクトリサービスです Dubbo サービスの登録センターとして最適です工業強度が高く本番環境でも利用可能です推奨です使用する
Redis レジストリ
Redis ベースのレジストリ
簡易レジストリ
独自の Dubbo サービス実装 (SimpleRegistryService) に基づいているため、クラスターはサポートされておらず、カスタムレジストリの参照として使用できますが、運用環境での直接使用には適していません。

Redis レジストリ

Redis レジストリについて 2 つのことを知っておく必要があります。

サービスの登録とサブスクリプション関係を保存する方法
サービスのステータスが変化したときにすぐに更新する方法です

Dubbo は、Redis のパブリッシュ/サブスクライブ機能を使用して、プロバイダーとコンシューマー間のリアルタイムのデータ同期を実現します。原理は次のとおりです。

Redis パブリッシュサブスクライブ

Redis パブリッシュ/サブスクライブ (pub/sub) はメッセージ通信モードです。送信者 (pub) がメッセージを送信し、サブスクライバー (sub) がメッセージを受信します。

Redis クライアントは、任意の数のチャネルにサブスクライブできます。

次の図は、チャネル channel1 と、このチャネルにサブスクライブしている 3 つのクライアント (client2、client5、client1) 間の関係を示しています。

新しいメッセージが PUBLISH コマンドを通じてチャネル channel1 に送信されると、このメッセージはそれにサブスクライブしている 3 つのクライアントに送信されます。

Redis をレジストリとして使用する方法を示します。

Redis サービスを開始する
サーバー構成登録センター
2 つのサーバーを起動する
RedisClient クライアントを介して Redis 内のデータを観察する

Redis レジストリ構成:

<dubbo:registry protocol="redis" address="192.168.0.147:6379"/>

2 つのサーバーを起動すると、Reids にハッシュタイプのレコードが追加され、そのキーは /dubbo/tuling.dubbo.server.UserService/providers であることがわかりました。Valueには、2つのサービスプロバイダのURLと有効期限がそれぞれ格納されます。

同じコンシューマは、次のように全体的な構造も似ています。

//服务提供者注册信息 
/dubbbo/com.tuling.teach.service.DemoService/providers
  dubbo://192.168.246.1:20880/XXX.DemoService=1542619052964 
  dubbo://192.168.246.2:20880/XXX.DemoService=1542619052964 
//服务消费订阅信息
/dubbbo/com.tuling.teach.service.DemoService/consumers
  dubbo://192.168.246.1:20880/XXX.DemoService=1542619788641

主なキーはサービス名とタイプです
マップ内のキーは URL アドレスです
マップ内の値は有効期限です。これはダーティデータを判断するために使用され、ダーティデータは監視センターによって削除されます。

次に、2 番目の質問ですが、プロバイダーが突然ダウンした場合、?

ここで、Dubbo は通常のハートビートメカニズムを使用してサービス URL の有効期間を維持します。デフォルトでは、有効期間は 30 秒ごとに更新されます。つまり、URL に対応するミリ秒の値です。特定のコードについては、com.alibaba.dubbo.registry.redis.RedisRegistry#expireExecutor を参照してください。

com.alibaba.dubbo.registry.redis.RedisRegistry#deferExpired

com.alibaba.dubbo.registry.integration.RegistryDirectory

com.alibaba.dubbo.registry.support.ProviderConsumerRegTable

飼育員登録簿

Zookeeper 登録センターについては、そのストレージ構造と更新メカニズムを理解する必要もあります。

Zookeper は、変更プッシュをサポートし、redis のパブリッシュ/サブスクライブ機能よりも安定したツリー型のディレクトリサービスです。

構造：

再接続に失敗しました

com.alibaba.dubbo.registry.support.FailbackRegistry

プロバイダーが突然切断されました:

Zookeeper の一時ノードメカニズムに基づいて、クライアントセッションがタイムアウトになった後、Zookeeper はすべての一時ノードを自動的に削除します (デフォルトは 40 秒)。

// 一時ノードを作成します

com.alibaba.dubbo.remoting.zookeeper.curator.CuratorZookeeperClient#createEphemeral

質問:
Zookeeper の切断から 40 秒以内にクライアントが参加した場合、無効なプロバイダー接続が呼び出されますか?

回答: いいえ、プロバイダーがダウンすると、クライアントとの接続は直ちに切断され、クライアントは電話をかける前に長い接続状態を検出します。

// 检测连接是否有效
com.alibaba.dubbo.rpc.protocol.dubbo.DubboInvoker#isAvailable

コンフィギュレーターとルーターを作成すると永続ノードが作成されます

// 永続ノードを作成します

com.alibaba.dubbo.remoting.zookeeper.curator.CuratorZookeeperClient#createPersistent

サービスサブスクリプションメカニズムの実装:

// 注册目录
com.alibaba.dubbo.registry.integration.RegistryDirectory

ソースコード分析:

com.alibaba.dubbo.registry.integration.RegistryDirectory

構成図は以下の通りです。
ここに画像の説明を挿入