リモートコールサービス(RPC)とメッセージ(Message Queue)の比較とその適用/非適用の場合
転載先:http://oldratlee.com/post/2013-02-01/synchronous-rpc-vs-asynchronous-message
(原作者)アリのプラットフォーム技術部でDubbo(リモートコールサービス)とNapoli(メッセージソリューション)の開発に参加し、ウェブサイトアプリケーションにこの2つの製品を2年間サポートし、この2つの製品の実現と応用がこの2つの製品の使い方を理解した.
ほとんどの場合、「与えられたシーンでこの2つの製品のうちどれを使うべきか」という問題は、簡単に決定され、あまり議論する必要はありません.
なぜ私が議論しなければならないのか:
一部のシーンはぼやけていて、使えると思います.この場合、優位性を見るのではなく、製品の欠点を知る必要があります.
一部の新人は製品の機能が交換できると思っているので、説明してください.
ここでは両者の違いを簡単に説明します.
システム構造
1
2
3
4
5
6
7
8
9
10
11
12
13
14
機能の特徴
アーキテクチャ上、RPCとMessageの違いは、Messageにはメッセージを格納できる中間ノードMessage Queueがあることです.
メッセージの特徴
Message Queueはリクエストの圧力を保存し,徐々に解放し,処理者に自分のペースで処理させる.
Message Queueは新しいノードを導入し,システムの信頼性がMessage Queueノードの影響を受けるようにした.
Message Queueは非同期一方向のメッセージです.送信メッセージは、メッセージ処理の完了を待つ必要がないように設計されている.
したがって,同期リターンの必要性に対してMessage Queueを用いることは面倒になる.
RPCの特徴
RPCは、結果/結果の処理を待つシーンで、非常に自然な直感的な使い方です.RPCは非同期呼び出しであってもよい.
結果を待つため、Consumer(Client)はスレッドを消費します.
非同期RPCで使用する場合、Consumerスレッドの消費は削除できます.しかし、メッセージのようにメッセージ/リクエストを一時的に保存することはできません.圧力はサービスプロバイダに直接伝わります.
適用する場合の説明
同期して結果を得たい場合はRPCが適当です.
簡単に使用したい場合はRPC;RPC操作はインタフェースに基づいて、簡単な方法でローカルコールをシミュレートします.非同期方式のプログラミングは複雑です.
送信側(RPC Consumer、Message Sender)が処理側(RPC Provider、Message Receiver)の速度に制限されないようにする場合は、Message Queueを使用します.
ビジネスが増加するにつれて、処理側の処理量がボトルネックになり、非同期メッセージへの同期呼び出しの改造が行われる場合があります.
このような改造には実際に業務を調整する使い方がある.
例えば、元の操作ページがコミットされると、次のページに処理結果が表示されます.非同期メッセージを変更すると、次のページが「操作がコミットされ、完了すると通知されます」になります.
適用されない場合の説明
RPC同期呼び出しは、Message Queueを使用して呼び出し情報を送信する.上記の分析から分かるように、送信側は待機しながら中間点のリソースを占有している.複雑になりましたが、対等な収益はありません.
戻り値がvoidの呼び出しの場合、実際には、この呼び出しビジネスでは、処理結果を同期して得る必要がないことが多いため、処理が保証されている限り、このようにすることができます.(RPC方式では呼び出しが返されると処理が完了することが保証され,メッセージ方式を使用するとこの点は保証されない.
戻り値はvoidの呼び出しであり,メッセージを用い,効果的にはメッセージの使用方式Wrapをサービス呼び出し(サービス呼び出しの使用方式は簡単で,ビジネスインタフェースに基づく)とする.
補足,デカップリングについての議論
微博でinter 12のいくつかの討論をして、とても意義があると思って追記します.
inter 12:この2つを比較することができますが、個人的な感覚は同じレベルの問題ではありません.RPCは分散型サービス間で呼び出されるソリューションであり、アーキテクチャ設計の意思決定を行う際に分散型オブジェクト、RESTなどのレベルのものと比較し、意思決定を行うソリューションです.メッセージシステムは、システム間のデカップリングやパフォーマンスの問題などを解決するために考慮されているものが多い.話が少し乱れているので,鼎兄の指図を見てください.
oldratlee:返信@inter 12:多くのキーについてお話ししましたが、「分散オブジェクト」「デカップリング」「パフォーマンス」は、両者の違いを見ることができます.2つのマシン間のデータの伝達(呼び出し、メッセージはすべてデータ)の観点から見ると、両者の効果は同じで、違いは使用方法、技術指標だけである:同期非同期(例えばフィードバックがあるかどうか)、データが一時的に保存されているかどうか、強弱タイプ(例えば独立したビジネス方法、データタイプがある)など
inter 12は「デカップリング」に言及し、「システム間のデカップリングを解決する」メッセージを使用する際によく言われるポイントは、重要なバランスの面です.
個人的には、「デカップリング」は「一時保存」に及ばず、RPCに対するメッセージの重要な違いだと思います.理由は以下の通りです.
メッセージのデカップリングの特徴は、主に以下のとおりです.
メッセージの送信者は、受信者の情報に関心を持つ必要はありません.サービスは、登録センターを介して行うこともできます.すなわち、サービス呼び出し者が登録センターにサービスプロバイダ情報を照会し、呼び出し者が知る必要はありません.
メッセージの送信者は、いくつかの関心のあるメッセージコンポーネントを送信することに関心を持たなくてもよい.この点RPCはサービス編成によって行うことができる.
(原作者)アリのプラットフォーム技術部でDubbo(リモートコールサービス)とNapoli(メッセージソリューション)の開発に参加し、ウェブサイトアプリケーションにこの2つの製品を2年間サポートし、この2つの製品の実現と応用がこの2つの製品の使い方を理解した.
ほとんどの場合、「与えられたシーンでこの2つの製品のうちどれを使うべきか」という問題は、簡単に決定され、あまり議論する必要はありません.
なぜ私が議論しなければならないのか:
一部のシーンはぼやけていて、使えると思います.この場合、優位性を見るのではなく、製品の欠点を知る必要があります.
一部の新人は製品の機能が交換できると思っているので、説明してください.
ここでは両者の違いを簡単に説明します.
システム構造
1
2
3
4
5
6
7
8
9
10
11
12
13
14
RPC ： +----------+ +----------+ | Consumer | <=> | Provider | +----------+ +----------+ Consumer Provider 。 Message Queue ： +--------+ +-------+ +----------+ | Sender | <=> | Queue | <=> | Receiver | +--------+ +-------+ +----------+ Sender Queue；Receiver Queue 。 機能の特徴
アーキテクチャ上、RPCとMessageの違いは、Messageにはメッセージを格納できる中間ノードMessage Queueがあることです.
メッセージの特徴
Message Queueはリクエストの圧力を保存し,徐々に解放し,処理者に自分のペースで処理させる.
Message Queueは新しいノードを導入し,システムの信頼性がMessage Queueノードの影響を受けるようにした.
Message Queueは非同期一方向のメッセージです.送信メッセージは、メッセージ処理の完了を待つ必要がないように設計されている.
したがって,同期リターンの必要性に対してMessage Queueを用いることは面倒になる.
RPCの特徴
RPCは、結果/結果の処理を待つシーンで、非常に自然な直感的な使い方です.RPCは非同期呼び出しであってもよい.
結果を待つため、Consumer(Client)はスレッドを消費します.
非同期RPCで使用する場合、Consumerスレッドの消費は削除できます.しかし、メッセージのようにメッセージ/リクエストを一時的に保存することはできません.圧力はサービスプロバイダに直接伝わります.
適用する場合の説明
同期して結果を得たい場合はRPCが適当です.
簡単に使用したい場合はRPC;RPC操作はインタフェースに基づいて、簡単な方法でローカルコールをシミュレートします.非同期方式のプログラミングは複雑です.
送信側(RPC Consumer、Message Sender)が処理側(RPC Provider、Message Receiver)の速度に制限されないようにする場合は、Message Queueを使用します.
ビジネスが増加するにつれて、処理側の処理量がボトルネックになり、非同期メッセージへの同期呼び出しの改造が行われる場合があります.
このような改造には実際に業務を調整する使い方がある.
例えば、元の操作ページがコミットされると、次のページに処理結果が表示されます.非同期メッセージを変更すると、次のページが「操作がコミットされ、完了すると通知されます」になります.
適用されない場合の説明
RPC同期呼び出しは、Message Queueを使用して呼び出し情報を送信する.上記の分析から分かるように、送信側は待機しながら中間点のリソースを占有している.複雑になりましたが、対等な収益はありません.
戻り値がvoidの呼び出しの場合、実際には、この呼び出しビジネスでは、処理結果を同期して得る必要がないことが多いため、処理が保証されている限り、このようにすることができます.(RPC方式では呼び出しが返されると処理が完了することが保証され,メッセージ方式を使用するとこの点は保証されない.
戻り値はvoidの呼び出しであり,メッセージを用い,効果的にはメッセージの使用方式Wrapをサービス呼び出し(サービス呼び出しの使用方式は簡単で,ビジネスインタフェースに基づく)とする.
補足,デカップリングについての議論
微博でinter 12のいくつかの討論をして、とても意義があると思って追記します.
inter 12:この2つを比較することができますが、個人的な感覚は同じレベルの問題ではありません.RPCは分散型サービス間で呼び出されるソリューションであり、アーキテクチャ設計の意思決定を行う際に分散型オブジェクト、RESTなどのレベルのものと比較し、意思決定を行うソリューションです.メッセージシステムは、システム間のデカップリングやパフォーマンスの問題などを解決するために考慮されているものが多い.話が少し乱れているので,鼎兄の指図を見てください.
oldratlee:返信@inter 12:多くのキーについてお話ししましたが、「分散オブジェクト」「デカップリング」「パフォーマンス」は、両者の違いを見ることができます.2つのマシン間のデータの伝達(呼び出し、メッセージはすべてデータ)の観点から見ると、両者の効果は同じで、違いは使用方法、技術指標だけである:同期非同期(例えばフィードバックがあるかどうか)、データが一時的に保存されているかどうか、強弱タイプ(例えば独立したビジネス方法、データタイプがある)など
inter 12は「デカップリング」に言及し、「システム間のデカップリングを解決する」メッセージを使用する際によく言われるポイントは、重要なバランスの面です.
個人的には、「デカップリング」は「一時保存」に及ばず、RPCに対するメッセージの重要な違いだと思います.理由は以下の通りです.
メッセージのデカップリングの特徴は、主に以下のとおりです.
メッセージの送信者は、受信者の情報に関心を持つ必要はありません.サービスは、登録センターを介して行うこともできます.すなわち、サービス呼び出し者が登録センターにサービスプロバイダ情報を照会し、呼び出し者が知る必要はありません.
メッセージの送信者は、いくつかの関心のあるメッセージコンポーネントを送信することに関心を持たなくてもよい.この点RPCはサービス編成によって行うことができる.