注意してください、迷子にならないでください; Java関連の技術と情報を更新し続けてください！！！
ダボインタビュートピック
1.DubboとDubboXの違い
DubboxとDubboは基本的に同じです。名前の意味は、Dubboの単なる拡張です。次の拡張機能も、Dubboxを選択する際の重要な考慮事項です。
- RESTスタイルのリモート呼び出し（HTTP + JSON / XML）をサポートします。
- KryoとFSTに基づく効率的なJavaシリアル化の実装をサポートします。
- Jacksonに基づくJSONシリアル化をサポートします。
- 組み込みTomcatに基づくHTTPリモーティングシステムをサポートします。
- Springを3.xにアップグレードします。
- ZooKeeperクライアントをアップグレードします。
- 完全にJavaコードに基づくDubbo構成をサポートします。
2. DubboのZookeeperがレジストリとして機能します。レジストリクラスターがすべてダウンしている場合でも、パブリッシャーとサブスクライバーは通信できますか？
はい、Dubboが起動すると、消費者は登録されたプロデューサーのアドレスインターフェイスとその他のデータをzkからプルし、ローカルにキャッシュします。呼び出されるたびに、ローカルに保存されているアドレスに従って呼び出されます
- 登録センターはピアツーピアクラスターであり、いずれかがダウンすると、自動的に別のクラスターに切り替わります。
- レジストリはすべてダウンしており、サービスプロバイダーとコンシューマーは引き続きローカルキャッシュを介して通信できます
- サービスプロバイダーはステートレスであり、いずれかがダウンした後は、使用に影響しません
- すべてのサービスプロバイダーがダウンし、サービスコンシューマーが利用できなくなり、無期限に再接続してサーバーが回復するのを待ちます
3. Dubboでの役割は何ですか？
①①。レジストリ
レジストリ。サービスを公開およびサブスクライブするためのプラットフォームです。SOAフレームワークのESBサービスバスを置き換えるために使用されます。
- 公開：サーバーコードの開発が完了すると、サービス情報が公開されます。サービスを公開します。
- サブスクリプション：クライアントプログラムは、登録センターからサービスコンテンツをダウンロードします。このプロセスはサブスクリプションです。
サービスに加入すると、公開されたサービスのすべての情報が一度にクライアントにダウンロードされます。
クライアントは、サービス構成情報の一部をカスタマイズおよび変更することもできます。たとえば、タイムアウト期間、呼び出しの再試行などです。
②。消費者
サービスの利用者は、サービスのクライアントです。
消費者は、Dubboテクノロジーを使用してコードの一部を開発する必要があります。基本的には、構成ファイルの定義です。
③。プロバイダー
サービスのプロバイダーはサーバーです。
サーバーは、コードの一部を開発するためにDubboテクノロジーを使用する必要があります。主に構成ファイルを使用します。
④。コンテナ
コンテナ。Dubboテクノロジーサーバー（プロバイダー）は、実行を開始するときに、コンテナーに依存して正常に起動する必要があります。
デフォルトの依存関係はSpringコンテナであり、DubboテクノロジーをSpringフレームワークから分離することはできません。
Dubboの2.5.3バージョンでは、デフォルトの依存関係はSpring2.5バージョンテクノロジーです。Spring4.5以下のバージョンを使用できます。
バージョン2.5.7のDubboでは、デフォルトの依存関係はSpring4.3.10バージョンテクノロジです。任意のSpringバージョンを選択できます。
⑤。モニター
モニタリングセンター。Dubboが提供するjarプロジェクトです。
主な機能は、サーバー（プロバイダー）とコンシューマー（コンシューマー）の使用状況データを監視することです。たとえば、サーバーとは何か、インターフェイスの数、メソッドの数、呼び出しの数、圧力情報などです。クライアントの数、呼び出されたサービス終了、何回呼び出されたかなど。
4. Dubboはセキュリティメカニズムをどのように解決しますか？
Dubboはトークンを使用して、ユーザーが登録センターをバイパスして直接接続するのを防ぎ、登録センターでの承認を管理します。Dubboは、サービスによって許可される発信者を制御するためのサービスの黒と白のリストも提供します。
5.ダボ実行プロセス？
- 開始：Springコンテナが開始されると、Dubboのプロバイダーが自動的に開始されます
- 登録：Dubboのプロバイダーは、起動後に自動的に登録センターに移動してコンテンツを登録します。登録されたコンテンツには、
2.1プロバイダーの
IP2.2プロバイダーのポート
2.3プロバイダーの外部提供インターフェースのリスト。どのメソッド。どのインターフェースクラス
2.4Dubboバージョン
。2.5プロバイダーにアクセスするための合意。 - サブスクライブ：サブスクリプション。コンシューマーが起動すると、自動的にレジストリに移動して、登録されたサービスの情報を取得します。
- 通知：通知プロバイダーの情報が変更されると、レジストリは自動的に通知をコンシューマーにプッシュします。
- Invoke：Invoke。コンシューマーはプロバイダー
5.1同期要求のメソッドを呼び出します。特定のパフォーマンスを消費します。ただし、メソッドの呼び出し結果を受信する必要があるため、同期要求である必要があります。 - カウント：回数.2分ごとに、ProvoiderとConsumerは自動的に訪問数をモニターに送信します。モニターは統計を実行します。
6. Dubboはどのプロトコルをサポートしていますか？
①。ダボ協定（公式推薦協定）
- 利点：NIOを使用して単一の長い接続を再利用し、スレッドプールを使用して要求を同時に処理し、ハンドシェイクを減らし、同時実行効率を高め、パフォーマンスを向上させます（推奨）
- 短所：大きなファイルをアップロードするときに問題が発生する可能性があります（Dubboファイルのアップロードを使用しないでください）
②.RMI（リモートメソッド呼び出し）プロトコル
- 利点：JDK独自の機能。TCPプロトコルに基づいて、ネイティブRMIと相互運用可能
- 短所：接続が失敗することがあります。
③。ヘッセ合意
- 利点：HTTPプロトコルに基づいて、ネイティブHessianと相互運用可能
- 短所：Hessian.jarのサポートが必要、Httpの短い接続は高価です
7. Dubboがサポートする登録センターは何ですか？
①.Zookeeper（公式推奨）
- 利点：分散サポート。多くの周辺製品。
- 短所：Zookeeperソフトウェアの安定性によって制限されますZookeeperの特別な分散補助ソフトウェア、安定性が向上します
②。マルチキャスト
- 利点：分散化。ソフトウェアを個別にインストールする必要がありません。
- 短所：プロバイダー、コンシューマー、およびレジストリがコンピュータールームを通過できない（ルーティング）
③。Redis
- 利点：クラスターのサポート、高性能
- 短所：サーバー時間の同期が必要です。そうしないと、クラスター障害が発生する可能性があります。
④。シンプル
- 利点：標準RPCサービス。互換性の問題はありません。
- 短所：クラスターをサポートしていません。
8.ダボサービスの負荷分散戦略？
①①。lランダムロードバランス
ランダム、重みでランダム確率を設定します。断面での衝突の可能性は高いですが、呼び出しの量が多いほど、分布が均一になり、確率に応じて重みが均一になり、プロバイダーの重みを動的に調整するのに役立ちます。（重量はDubboコントロールコンソールで構成できます）
②。l RoundRobin LoadBalance
ラウンドロビン、ラウンドロビン比は、大会後の重量に応じて設定されます。遅いプロバイダーからのリクエストの蓄積に問題があります。たとえば、2番目のマシンは遅いがハングアップしていません。リクエストが2番目のマシンに転送されると、そこでスタックします。時間の経過とともに、すべてのリクエストが2番目のマシンでスタックします。
③。l LeastActive LoadBalance
アクティブな呼び出しの最小数、同じアクティブな数はランダムであり、アクティブな数は呼び出しの前後のカウントの差を指します。遅いプロバイダーは、呼び出しの前後のカウントの差が大きくなるため、受信する要求が少なくなります。
④。l ConsistentHash LoadBalance
一貫性のあるハッシュ、同じパラメーターを持つ要求は常に同じプロバイダーに送信されます。特定のプロバイダーが電話を切ると、そのプロバイダーに最初に送信された要求は、大幅な変更を行うことなく、仮想ノードに基づいて他のプロバイダーに拡散されます。デフォルトでは、最初のパラメーターHashのみを変更する場合は、構成してください
9. Dubboのコア構成は何ですか？Dubboはどのプロトコルを推奨していますか？
核心配置有dubbo：service / dubbo：reference / dubbo：protocol / dubbo：registry / dubbo：application / dubbo：provider / dubbo：consumer / dubbo：method /
デフォルトでは、Dubboプロトコルが使用されます。
10.ダボ登録センターと直接接続の違い
開発およびテスト環境では、レジストリをバイパスして、指定されたサービスプロバイダーのみをテストする必要がある場合がよくあります。この場合、ポイントツーポイント直接接続またはポイントツーポイント直接接続が必要になる場合があります。サービスインターフェイスがユニットとして使用され、レジストリのプロバイダーリストは無視されます。レジストリは、サービスを動的に登録および検出し、サービスの場所を透過的にし、消費者側のサービスプロバイダーアドレスリストを取得することでソフトロードバランシングとフェイルオーバーを実現し、レジストリは、変更があった場合にサービスプロバイダーアドレスリストを消費者に返します。 、レジストリは、長い接続に基づいて変更データをコンシューマーにプッシュします。サービスコンシューマーは、ソフトロードバランシングアルゴリズムに基づいて、プロバイダーアドレスリストから、呼び出すプロバイダーを1つ選択し、呼び出しが失敗した場合は、呼び出す別のプロバイダーを選択します。レジストリは、ディレクトリサービスに相当するサービスアドレスの登録と検索を担当します。サービスプロバイダーとコンシューマーは、起動時にのみレジストリと対話します。レジストリは要求を転送しません。サービスコンシューマーは、レジストリからサービスプロバイダーアドレスリストを取得します。ロードアルゴリズムに従ってプロバイダーを直接呼び出すと、レジストリ、サービスプロバイダー、およびサービスコンシューマーは、監視センターを除いてすべて永続的な接続になります。レジストリは永続的な接続を通じてサービスプロバイダーの存在を認識し、サービスプロバイダーはダウンして登録されます。センターはすぐにイベントをプッシュして、レジストリと監視センターがダウンしていることを消費者に通知し、すでに実行されているプロバイダーと消費者には影響しません。消費者はプロバイダーリストをローカルにキャッシュします。レジストリと監視センターはオプションです。サービスの消費その人はサービスプロバイダーに直接接続できます。
11.Dubbo通信プロトコルDubboプロトコルが大きなパケットを送信できないのはなぜですか
Dubboプロトコルは単一の長い接続を使用するため、各要求のパケットサイズが500KByteの場合、ネットワークがギガビットネットワークカード（1024Mbit = 128MByte）であると仮定すると、各接続の最大値は7MByteです（参考までに、環境によって異なる場合があります）。
- 単一のサービスプロバイダーの最大TPS（1秒あたりのトランザクション数）は、128MByte / 500KByte = 262です。
- 単一の消費者が単一のサービスプロバイダーを呼び出すための最大TPS（1秒あたりのトランザクション数）は、7MByte / 500KByte = 14です。
許容できる場合は、使用を検討してください。そうでない場合、ネットワークがボトルネックになります。
12. Dubbo通信プロトコルDubboプロトコルがプロバイダーよりも多くのコンシューマーを必要とするのはなぜですか？
Dubboプロトコルは単一の長い接続を使用するため、ネットワークがギガビットネットワークカード（1024Mbit = 128MByte）であると仮定すると、テストエクスペリエンスのデータによると、各接続は最大7MByte（参考までに異なる環境は異なる場合があります）、理論的には1つのサービスしか満たすことができません。プロバイダーは、ネットワークカードに記入するために20人のサービスコンシューマーを必要とします。
13.Dubbo通信プロトコルDubboプロトコルが非同期シングルロング接続を採用する理由
サービスの現在の状況は、ほとんどの場合、サービスプロバイダーが少なく、通常はマシンが少なく、サービスの消費者が多いため、Webサイト全体がサービスにアクセスしている可能性があります。たとえば、モーガンのプロバイダーには6つのプロバイダーしかありませんが、数百の消費者がいます。 1日あたり1億5000万件の通話があります。従来のヘッセサービスを使用すると、サービスプロバイダーは簡単に圧倒されます。1回の接続で、1人の消費者がプロバイダーを押しつぶしたり、接続が長くなったり、接続のハンドシェイク検証が減少したりすることがなくなります。また、非同期IOを使用し、スレッドプールを再利用してC10Kの問題を防ぎます。
14.ダボ通信プロトコルダボプロトコルの範囲とアプリケーションシナリオ
①。ダボ協定
- 適用範囲：着信および発信パラメータデータパケットは小さく（100K未満を推奨）、プロバイダーよりも多くのコンシューマーがあり、単一のコンシューマーはプロバイダーを埋めることができません。dubboプロトコルを使用して大きなファイルや大きな文字列を転送しないようにしてください。
- 該当するシナリオ：従来のリモートサービスメソッドを呼び出す
ダボ契約の補足：
- 接続数：単一接続
- 接続モード：長い接続
- 伝送プロトコル：TCP
- 送信方法：NIO非同期送信
- シリアル化：ヘシアンバイナリシリアル化
②.RMIプロトコル
RMIプロトコルは、JDK標準Java.rmi。*、ブロッキングショート接続とJDK標準シリアル化、およびJava標準リモート呼び出しプロトコルを使用して実装されます。
- 接続数：複数の接続
- 接続モード：短い接続
- 伝送プロトコル：TCP
- 送信方法：同期送信
- シリアル化：Java標準のバイナリシリアル化
- 適用範囲：着信パラメータデータと発信パラメータのデータパケットサイズが混在しており、コンシューマとプロバイダーの数が類似しており、ファイルを転送できます。
- 該当するシナリオ：従来のリモートサービスメソッド呼び出し、ネイティブRMIサービスとの相互運用性
③。ヘッセ合意
Hessianプロトコルは、Hessianのサービスを統合するために使用されます。Hessianの最下層はHttp通信を使用し、Servletを使用してサービスを公開します。DubboはデフォルトでJettyをサーバーとして埋め込みます。これは、Hessianのリモート呼び出しプロトコルに基づいています。
- 接続数：複数の接続
- 接続モード：短い接続
- 送信プロトコル：HTTP
- 送信方法：同期送信
- シリアル化：ヘシアンバイナリシリアル化
- 適用範囲：着信および発信パラメータデータパケットが大きく、プロバイダーの数がコンシューマーの数よりも多く、プロバイダーに大きなプレッシャーがかかり、ファイルを転送できます。
- 該当するシナリオ：ページ転送、ファイル転送、またはネイティブヘシアンサービスとの相互運用性
④。http
SpringのHttpInvokerによって実装されます。Httpフォームに基づくリモート呼び出しプロトコル。
- 接続数：複数の接続
- 接続モード：短い接続
- 送信プロトコル：HTTP
- 送信方法：同期送信
- シリアル化：フォームシリアル化（JSON）
- 適用範囲：受信および送信パラメーターデータパケットのサイズは混合されており、ブラウザーで表示できるプロバイダーの数はコンシューマーよりも多く、パラメーターはフォームまたはURLを介して渡すことができます。ファイルのアップロードは現在サポートされていません。
- 該当するシナリオ：アプリケーションとブラウザーJSが同時に使用する必要があるサービス。
⑤。ウェブサービス
フロントエンドの実装-シンプルおよびトランスポート-CXFに基づくhttp; WebServiceに基づくリモートコールプロトコル。
- 接続数：複数の接続
- 接続モード：短い接続
- 送信プロトコル：HTTP
- 送信方法：同期送信
- シリアル化：SOAPテキストのシリアル化
- 該当するシナリオ：システム統合、クロスランゲージコール。
⑥。スリフ
Thriftは、FacebookからApacheに寄贈されたRPCフレームワークです。dubboでサポートされている現在のthriftプロトコルは、ネイティブthriftプロトコルの拡張です。サービス名、マジックナンバーなど、いくつかの追加のヘッダー情報がネイティブプロトコルに追加されます。
これで記事の終わりです！
上記のインタビューの質問に対する回答は、ドキュメントノートにまとめられています。また、2020年にいくつかの大企業によって収集されたいくつかのインタビュー資料と最新のインタビュー質問を整理しました（すべてドキュメントに整理され、スクリーンショットのごく一部です）。必要に応じて、 クリックして入力して資料を表示できます。
注意してください、迷子にならないでください！この記事があなたに役立つなら、好きでサポートすることを忘れないでください！
