相互に呼び出す複数のサービス(フロントエンド->バックエンド->ストレージなど)で構成されるシステムの場合、「ダウンストリーム」または「アップストリーム」サービスなどの用語を使用している人の話をよく耳にしました。私はこれらがどの方向を意味するのか明確ではありません。データは両方向に流れます。要求はより多くのユーザー向けからより多くのバックエンドサービスに流れますが、応答は反対方向に流れるので、どちらか一方の方法で議論することができます
ダウンストリームサービスは、アップストリームサービスを使用するサービスです。特に、アップストリームサービスではdependです。したがって、フロントエンドはバックエンドに依存しているため、バックエンドのダウンストリームになります。バックエンドはフロントエンドがなくても有意義に存在できますが、フロントエンドはバックエンドがなければ意味がありません。
依存関係は、前の段落で確認したほど強力である必要はありません。より一般的には、アップストリームサービスはダウンストリームサービスの存在を認識したり気にする必要はありません。ダウンストリームサービスは、オプションでそれらを消費するだけでも、アップストリームサービスの存在を考慮します。
残念ながら、上流/下流の意味についての意見には違いがあります。システムアーキテクチャについて話すときは、次のように定義します。
関心のあるシステムを考えると、関心のあるシステムへのメッセージ/データ交換を開始するシステムは上流システムであり、関心のあるシステムが依存するシステム(つまり、私のシステムがデータ交換を開始するシステム)は下流のシステムです。
これらの製品の1つとの相互作用を説明するibmからのこのリンクは、このビューを裏付けています: 上流および下流システムとの統合https: //www.ibm.com/support/knowledgecenter/en/SSWSR9_11.3.0/com.ibm.pim.dev.doc/integration/pim_con_dev_creatingjobsforintegrationcontainer.html
上流システムは、Collaboration Serverシステムにデータを送信するシステムです。ダウンストリームシステムは、Collaboration Serverシステムからデータを受信するシステムです。
「上流」と「下流」という用語を考えると、川との類推が役立つ場合があります。川にメッセージ(データ)をドロップすると、上流(開始者)から下流(受信者)に流れます。
事例として、アーキテクトとミドルウェアの開発者がこの定義を使用し、Web開発者が反対の定義を使用していることを発見しました(おそらく「アップロード」が原因です)。
イベントタイムラインでは、イベントはタイムライン上のポイントの前に発生すると(つまり、別のイベントをトリガーします)アップストリームになり、後で発生すると(つまり、イベントを受信すると)ダウンストリームになります。したがって、一連のイベントの上流と下流は、タイムラインのどこにいるかによって異なります。開始点がイベントの前か後かによって、イベントはダウンストリームとアップストリームの両方になります。
@Jackが指摘しているように、RFC7230 tools.ietf.org/html/rfc7230#section-2.3 には次のように記述されています。
「上流」および「下流」という用語は、
メッセージフローに関連する方向の要件:すべて
メッセージは上流から下流に流れます
最も一般的な使用法である投票を見てみたいです!
これについて考える最良の方法は、川について考えることです。
川の下流部分は、上流から来ない限り水を得ることができません。つまり、下流はその上流の水に依存しています。
誰かが川の下流部分を破壊した場合、これは上流に影響を与えません。誰かが川の上流部分を破壊した場合、これは下流に影響を及ぼします。つまり、水がまったく流れません。
したがって、ダウンストリームサービスはアップストリームサービスに依存しています。アップストリームサービスが削除されると、ダウンストリームサービスは正しく機能しません。
これは、技術的な問題よりも言語的および地理的な問題である可能性があります。
情報の要求は上流に送られます。それは下流のシステムから来ています。
情報の要求(要求された情報)への応答は、ダウンストリームに送信され、アップストリームシステムによって送信されます。
従来のIBMの見解と今日のWebコミュニティでの用語の使用法に違いはありません。
サービスプロバイダー(サーバー)は、サービスコンシューマーと比較してlocatedアップストリームになり、sendsコンシューマーのダウンストリーム情報になります。
サービスコンシューマー(クライアント)は、サービスプロバイダーと比較してlocatedダウンストリームになり、sendsプロバイダーへのアップストリームリクエストになります。
理論的には、物理システムの役割は瞬時に変化し、システム間のストリームの方向も変化する可能性があります。ピアツーピアネットワークでは、これが当てはまる場合があります。
アップロードおよびダウンロードという用語は、クライアント中心の用語です。クライアントの観点からは、要求がアップロードされ、応答がダウンロードされます。これは、ストリームのメタファーと一致しています。