まず、何がそれをダボ？
1）自然：ジャーパッケージ、分散フレームワーク,,分散リモートサービスコールのフレームワーク。
それは教育への新たなので、確かに多くの学生は、分散およびリモートサービスコールは、なぜ、なぜ長距離通話を分散しているものを理解していません。私は単純にチャートが示す比較を（スプレーしないで、図2.図1の描画ボードの絵を参照）を描きます。
サーバーには、過去または何かについて、直接自然と呼ばれる方法で、何も問題を呼び出すと思います。さて、需要の増加のためには、別のサーバーにデプロイ、非常に多くの分割、それがすべて1台のサーバー上ではなく、今の分散、ウェブサービス層、層の呼び出しは、サービスは比較的リモート呼び出しがなる前に？これは、サーバー上で以前のように呼び出す方法を行うための自然な方法がありますか？解決ダボ。これは、ダボのメリットを下回っています。
二、ダボのメリット？
1.透明リモートメソッド呼び出し、任意の侵入APIなしで、ローカルメソッド呼び出しリモートメソッドだけの簡単な設定を呼び出すのと同じ。
ネットワークを含む2.ソフトの負荷分散とフォールトトレランスのメカニズムは、F5ハードウェアロードバランサを置き換え、低コスト、単一ポイントを減らすことができます。
3.オートサービスの登録と発見は、もはや死んサービスプロバイダアドレス、IPアドレス、レジストリベースのクエリインタフェース名サービスプロバイダを記述する必要がなく、スムーズにサービスプロバイダを追加または削除することができます。（後述）
フルダボ、透過的なアクセス・アプリケーション、アプリケーションなし侵入APIと春の配置は、構成が単純に春ダボ、ダボスプリング式の拡張スキーマをロードすることができます。
三、以下のダボアーキテクチャ図：
彼のアーキテクチャ図を説明するのに先立ち、私たち最初の普遍的な概念の下で。
ノードロールの説明：
プロバイダ（プロデューサー）：露出サービスサービスプロバイダ。
コンシューマー（消費者）：サービスコンシューマは、リモートサービスを呼び出します。
示されているように、我々は単にweb1234として理解することができるservice1234サービス、そうweb1234消費者、service1234生産を呼び出す必要があります。
あなたは上記に従ってそのプロデューササービスを呼び出す場合は、以下のように、消費者は、そうではありません。
あなたはヘイローヘイロー見ませんか？ハローハローないのですか？ハローハローないのですか？それは多くの分散場合とにかく、私は、めまいでしたか？だから我々は彼を必要とします：
レジストリ（レジストリ）：レジストリサービスの登録と発見。ダボは、飼育係することをお勧めします。飼育係は何ですか？分散処理のために飼育係一貫フレームワーク。あなたは私の以前の記事の多くを見ることができます：実際には、治療法と一致しているフレームワークであり、飼育係は非常に簡単です、ただ言うのをしてみましょう。簡単に言えば、飼育係は、リソースのリスト不動産業者を得るために、プロパティ（消費者）を購入したい、不動産業者（レジストリ）の調停、干潟の販売（プロデューサー）の情報です。したがって、我々は、このような図になります：
それははるかに良いではないですか？十分に、我々はまた、（もちろん、モニターの使用、およびコールをハングアップを行う方法を実行する方法を失敗した理由です???）監視センターを必要とされていません：モニタ：通話時間の統計的なサービスは、監視センタ通話時間を調整します。（未描画）
次に、コンテナの操作上のプロバイダは、コンテナを実行しているコンテナサービスと呼ばれます。（未描画）
示すように、最終的なダボアーキテクチャは、（0から読み始めました）。
自身の心は、以下に説明するように図によると、彼らが望むと外観は同じではありませんもう一度行って。
0サービスコンテナは、開始、ロード、実行するサービスプロバイダの責任です。
起動時に1.サービスプロバイダー（プロデューサー）、レジストリに提供する登録サービス。
起動時に2.消費者サービスは、あなたがサービスレジストリに登録する必要があります。
3.レジストリは、消費者にアドレスサービスプロバイダのリストを返します。変更がある場合、レジストリは、消費者への長い接続プッシュデータに基づいて変更されます。
4.サービスの消費者、リスト、ソフトの負荷分散アルゴリズムからプロバイダのアドレスは、呼び出しが失敗した場合、その後、別のコールを選択し、プロバイダのコールを選択してください。
通話の累積数のメモリ5.サービスコンシューマとプロバイダ、および時間を呼び出し、時間が監視センターに1分ごとに統計データを送りました。