1. はじめに
Dubbo は、Alibaba がオープンソース化した透過的で高性能な分散 RPC フレームワークです。dubbo プロトコルに基づいて実装されています。基盤となる通信方式は TCP ロング接続に基づいており、送信方式はサービス パフォーマンスを向上させるために NIO によって実装されています。 。中心となる機能は 3 つあります。インターフェイス指向のリモート メソッド呼び出し、インテリジェントなフォールト トレランスと負荷分散、自動サービス登録と検出です。
2. Dubbo の動作原理:
第 1 層: サービス層、インターフェース層、サービスプロバイダーとコンシューマー向けに実装 第
2 層: 設定層、設定層、主にダボの各種設定用 第
3 層: プロキシ層、サービスプロキシ層、透過的にスタブを生成クライアントとサービス リストのスケルトン
第 4 層: レジストリ層、サービス登録層、サービスの登録と検出を担当 第
5 層: クラスター層、クラスター層、複数のサービス プロバイダーのルーティングと負荷分散をカプセル化複数のインスタンスが 1 つのサービスに結合されます
レイヤ 6: モニタ層、モニタリング層、RPC インターフェイスのコール数とコール時間の監視 レイヤ
7: プロトコル層、リモートコール層、RPC コールのカプセル化
レイヤ 8: 交換層、情報交換層、カプセル化要求応答モード、同期から非同期
第 9 層: トランスポート層、ネットワーク トランスポート層、統一インターフェイスとしての抽象的な mina と netty
第 10 層: シリアル化層、データ シリアル化層
3. ダボ実行プロセス:
まず、プロジェクトが開始されると、初期化のために構成ファイルがロードされ、サービス プロバイダーは提供するサービスを登録センターに登録します。コンシューマーが開始すると、必要なサービスを登録センターに登録します。サービス プロバイダーにデータ変更がある場合、登録センターは長い接続フォーム (非同期) に基づいて変更データをコンシューマーにプッシュします。
デフォルトでは、dubbo プロトコルが採用されます。
接続数: シングル接続; 接続方法: ロング接続; 送信方法: NIO 非同期送信; 送信プロトコル: TCP; シリアル化: デフォルトではヘシアン バイナリが使用されます。
適用範囲: 送受信パラメータ データ パケットが小さく (100K 以内)、コンシューマの数がプロバイダの数よりも多いため、大きなファイル、ビデオ、および大きな文字列データの送信にダボ プロトコルを使用しないようにしてください。
Dubbo 機能: 少量のデータと大量の同時実行のシナリオに適しています。
4. Dubbo のセキュリティ パフォーマンスを確保する方法:
1. 登録センターがある場合は、dubbo が提供する dubbo 管理コンソールを介してルーティング ルールを設定し、アクセスする固定 IP コンシューマーを指定できます。
2. 直接接続の場合、サービスプロバイダーにトークンを設定できますが、このとき、サービスコンシューマーはアクセスするために対応するトークンを提供する必要があります。
3. Dubbo は、違法な呼び出しを防ぐためにサービス IP ホワイトリストを追加します。
5. Dubbo で分散トランザクションを確保する方法:
段階的なトランザクションを避けるために、トランザクションを必要とするメソッドをサービス層に追加しようとします。Dubbo の最下層はソケット接続に基づいており、複数のスレッドが同時にプロバイダー メソッドをリモートで呼び出すと、この時点でクライアント サーバーとサーバー間のソケット接続が確立され、多くのデータ パケットが送信されます。前後の順序を確保するのは難しくないが、混乱が生じやすい サービスプロバイダは処理が完了すると、処理結果をクライアントに送信する クライアントは大量のデータパケットを受信するどの応答データ パケットが最初に呼び出されたスレッドに対応しているかを確認するにはどうすればよいですか?
このとき、一意性を保証するために配布された一意の RequestID を使用する必要があり、コンシューマが呼び出しを行うと、一意の ID がサービス プロバイダに渡され、サービス プロバイダは処理後に ID をクライアントに応答します (たとえば、前後の消費順序を保証します)。
6. Dubbo ハートビート メカニズム:
目的: プロバイダーと顧客間の通信を維持するため
実現: Dubbo は、ハートビート時間を 1 秒にデフォルト設定します。ハートビート時間が経過してもメッセージが受信されない場合は、ハートビート メッセージを送信します。ハートビート メッセージが 3 ハートビートを超えて受信されない場合、プロバイダーはチャネルを閉じ、顧客はプロバイダーであるか顧客であるかに関係なく、再接続されます。ハートビート メカニズムの検出は、スケジュールされたタスクを開始することによって実現されます。
7. Dubbo は、zookeeper を登録センターとして使用していますが、すべての登録センターがダウンした場合でも、消費者は引き続きプロバイダーと正常に通信できますか?
はい、サービス コンシューマは開始時に登録センターで必要なサービスをサブスクライブし、サービス サブスクリプションの関連情報をローカル キャッシュ (つまり、ディスク) に書き込むためです。サービスプロバイダーは、通信のためにローカルキャッシュからプロバイダー情報を直接取得します。この時点でサービスプロバイダーにデータの変更や新しいサービスがある場合、消費者はそれらを取得できず、他の新しいサービスと正常に通信できなくなります。
8. Dubbo はどのような負荷分散戦略を提供しており、その構成方法は何ですか?
RandomLoadBalance (デフォルトではランダム): 重み、ランダム割り当て戦略に従って構成できます。
RoundRobinLoadBalance (ポーリング): 各ノードを順番に訪問します。これにより、リクエストの過剰な蓄積やリクエストの不均等な分散が容易に発生する可能性があります。
LeastActiveLoadBalance (アクティブなコールの最小数): 各サービス要求の前後のコール数の差を指し、同じアクティブな番号がランダムに割り当てられます。各サービスはアクティブな番号カウンターを維持するため、同時通話数を記録するために使用されます。現在同時に処理されているリクエスト。値が小さい場合は、サービスがリクエストを迅速に処理するか、現在のマシン負荷が比較的低いことを示し、最初にこのサービスに割り当てられます。サービスの処理速度が非常に遅い場合、サービスが重なり、同時に処理されるリクエストの数が比較的多くなります。このとき、アクティブな呼び出しの数が多いほど、サービスが受け取るリクエストの数は少なくなります。リクエストの数はアクティブなコールの数に反比例するためです。
ConsistentHashLoadBalance (一貫性ハッシュ): 同じパラメータは常に同じプロバイダーに送信されます。プロバイダーがハングアップした場合、その仮想ノードに従って他のサーバーに分散され、大きな変更は発生しません。
9. 負荷分散ポリシーはサーバーとクライアントの両方で構成できます (クライアントで構成することが望ましい)
サーバ：
<-! 服务端服务级别配置></-!>
<dubbo:service interface="接口名" loadbalance="roundrobin"/>
<-! 服务端方法级别配置></-!>
<dubbo:service interface="接口名">
<dubbo:method name="方法名" loadbalance="均衡策略名"/>
</dubbo:service>
クライアント：
<-! 客户端服务级别配置></-!>
<dubbo:reference interface="接口名" loadbalance="roundrobin"/>
<-! 客户端方法级别配置></-!>
<dubbo:reference interface="接口名">
<dubbo:method name="方法名" loadbalance="均衡策略明"/>
</dubbo:reference>
クラスタ構築時の注意点（2点）：
1. 同じクラスタ環境内のアプリケーション名は一貫している必要があります。
2. ポートは異なる必要があります
10. Dubbo と SpringCloud の間に違いはありますか?
公式説明:
Dubbo の公式ドキュメントによると、dubbo は Java をベースとした高性能で軽量な RPC フレームワークです。彼は rpc を効率化するためにカプセル化しただけであり、それがどんなに牛革であっても、それは単なる通信プロトコルです。
Spring Cloud の公式ドキュメントには次のように書かれています。 Spring Cloud は、一般的なユースケースにすぐに使える優れたエクスペリエンスと、他の状況をカバーする拡張メカニズムを提供することに重点を置いています。すぐに使える優れたエクスペリエンスを提供することに重点を置いています。通信プロトコルをカプセル化しただけの dubbo とは大きく異なり、springcloud の目標は、フレームワークを迅速に構築し、サービスを迅速に実行できるように多くの使いやすいコンポーネントを提供し、ユーザーが優れたサービスを利用できるようにすることです。経験。したがって、Spring Cloud はマイクロサービス アーキテクチャの下でのワンストップ ソリューションという位置づけになります。
概要の比較:
- バイナリ送信のため、Dubbo が占有する帯域幅は少なくなります。
- SpringCloud は送信に http プロトコルを使用するため、帯域幅が増加しますが、同時に http プロトコルを使用すると一般に JSON メッセージが使用されるため、消費量も増加します。
- Dubbo の開発は、多くの大規模プロジェクトでは Dubbo の jar パッケージの依存関係の問題を解決できないため、困難です。
- SpringCloud のインターフェイス プロトコル協定は比較的自由かつ緩やかで、インターフェイスの無秩序なアップグレードを制限するには強力な管理措置が必要です。送信、
帯域幅は増加し、HTTP プロトコルは一般に JSON メッセージを使用するため、消費量も増加します。 - Dubbo の開発は、多くの大規模プロジェクトでは Dubbo の jar パッケージの依存関係の問題を解決できないため、困難です。
- SpringCloud のインターフェイス プロトコル協定は比較的自由かつ緩いため、インターフェイスの無秩序なアップグレードを制限するには強力な管理措置が必要です。
- Dubbo の登録センターでは、Zookeeper、Redis などを選択できます。SpringCloud の登録センターでは、Eureka、Consul、Nacos などが使用されます。