1. ダボとは何ですか?

#1) これは初心者向けのチュートリアルであるため、多くの学生は、分散サービスコールとリモートサービスコールとは何なのか、なぜ分散する必要があるのか、なぜ必要なのかを理解していないはずです。リモート通話。簡単に比較表を描いて説明します (図 2 の図 1 を参照してください。画板に描いていますので、スプレーしないでください)。

ダボ+ゾーキーパーの基本解説

考えてみてください。以前はすべてが同じサーバー上にあり、呼び出しメソッドは直接自然に呼び出されていましたが、問題はありませんでした。現在では、需要の増加により、その多くが別々のサーバーに分割されてデプロイされていますが、以前はそれらがすべて 1 つのサーバー上に分散されていたのと比べて、Web 層のサービスはを呼び出しています。サービス層はリモート呼び出しになったのでしょうか?では、以前と同じサーバー上でメソッドを自然に呼び出すにはどうすればよいでしょうか?それを解決するためにダボ。これは以下のダボの利点です。

2. ダボの利点は何ですか?

1. 透過的なリモートメソッドの呼び出しには、ローカルメソッドの呼び出しと同様に、API の侵入を必要としない簡単な構成が必要です。

2. ソフトロードバランシングおよびフォールトトレランスメカニズムは、イントラネット上の F5 などのハードウェアロードバランサを置き換えることができ、コストとシングルポイントを削減します。

3. 自動サービス登録と検出。サービスプロバイダーのアドレスを書き留める必要がなくなり、登録センターはインターフェイス名に基づいてサービスプロバイダーの IP アドレスを照会し、サービスプロバイダーをスムーズに追加または削除できます。。 (以下で説明します)

Dubbo は、完全な Spring 構成メソッドを使用して、アプリケーションに API を侵入させることなくアプリケーションに透過的にアクセスします。Spring を使用する必要があるのは、Spring のスキーマ拡張に基づいて Dubbo の構成をロードすることだけです。

3. Dubbo のアーキテクチャ図は次のとおりです:

彼のアーキテクチャ図を説明する前に、いくつかの概念を説明しましょう。

ノードの役割の説明:

プロバイダー (プロデューサー): サービスを公開するサービスプロバイダー。

コンシューマ: リモートサービスを呼び出すサービスコンシューマ。

図に示すように、web1234 は service1234 のサービスを呼び出す必要があるため、web1234 がコンシューマーであり、service1234 がプロデューサーであることが簡単に理解できます。

ダボ+ゾーキーパーの基本解説

コンシューマが上記に従ってプロデューサーのサービスを呼び出すと、次のようになりますか:

ダボ+ゾーキーパーの基本解説

あなたは次のようになります。それを見てめまいがしますか？気絶か否か？気絶か否か？とにかくめまいがした、もっと配信されたらどうなるの？、したがって、彼が必要です:

レジストリ (登録センター): サービスの登録と検出のための登録センター。ダボは飼育員を推薦します。動物園の飼育員とは何ですか？ Zookeeper は、分散システムにおける一貫性処理のためのフレームワークです。詳細については、私の以前の記事を参照してください。つまり、zookeeper は非常に単純で、一貫性処理に使用される単なるフレームワークです。簡単に言うと、ZooKeeper は仲介業者です。不動産の売り手 (生産者) は仲介業者 (登録センター) に物件情報を提供し、不動産を購入したい人 (消費者) は仲介業者に物件リソースのリストを取得します。したがって、私たちのイメージは次のようになります:

ダボ+ゾーキーパーの基本解説

これはかなり良くなったと思いませんか?それが十分でない場合は、監視センターも必要です (何に使用しますか? もちろん監視用です。通話が失敗したらどうすればよいですか? 電話が切れたらどうすればよいですか?): モニター: 重要な監視センターサービスの通話回数と通話時間。 (これ以上の描画はありません)

次に、コンテナー内でプロバイダーが実行されます。これは、コンテナーを実行するためのコンテナーサービスと呼ばれます。 (これ以上の描画はありません)

図に示す最終的なダボアーキテクチャ (0 から開始):

ダボ+ゾーキーパーの基本解説