web-dev-qa-db-ja.com

潜在的なボトルネックを回避することによるキャッシングマイクロサービスの実装

私が取り組んでいるシステムは、外部のサードパーティに対して非常に洗練されたキャッシング/プリロードメカニズムを採用しており、マイクロサービスアーキテクチャに基づいて構築されているため、機能マイクロサービスからキャッシング/プリロード機能全体を抽出したいと思います（たとえば、予約/検索）専用のものに：

+-----+      +--------------------+            +----------+
| API | <--> | booking | internal | <--------> | external |
|     |      | service | cache    |            | service  |
+-----+      +--------------------+            +----------+

versus

+-----+      +---------+      +---------+      +----------+
| API | <--> | booking | <--> | caching | <--> | external |
|     |      | service |      | service |      | service  |
+-----+      +---------+      +---------+      +----------+

これがもたらす可能性のある潜在的なボトルネックに懸念があります。バックエンドと通信する内部キャッシュシステムを使用してマイクロサービスを予約する代わりに、すべてのget/set呼び出しに対して個別のマイクロサービスと通信します（それがバックエンドと通信します）。私が目にするボトルネックは、主に追加のマイクロサービスを介して通信するために追加される時間です。これは大きな問題でしょうか？予約マイクロサービスとキャッシュサービス（REST、メッセージキュー）間の通信にどのように取り組むべきですか？私が見る限り、同期通信でなければなりません。このセットアップから他に（非表示の）ボトルネックが発生する可能性はありますか？

restcachingmicroservicesmessage-queue
5
linkyndy

私の提案は、外部キャッシュと内部キャッシュのどちらを使用するかを心配する代わりに、予約サービスが気にしない外部サービスを使用しているかどうか。

つまり、予約サービスは、具体的な実装が注入されたインターフェースに対してキャッシュする必要があります。それが使用されているかどうかは知りませんし、気にしません：

  1. 外部キャッシュサービス（アウトプロセス）
  2. 内部キャッシュ（処理中）
  3. 外部サービスに直接行ったパススルーキャッシュ

ある時点で、外部と内部のスマートな組み合わせを使用するシステムを開発することもできます。

この動作が適切に分離されると、特定のユースケースの各ソリューションの長所と短所を自由に探ることができます。

8
TheCatWhisperer

実際、深刻なボトルネックが発生し、チェーンの単一障害点が発生しています。

キャッシュサービスの複数のインスタンスを実際の各サービスのプロキシとして設定することをお勧めします（一部のネットワークポートを節約するために、すべてのサービスではなく、すべてのサービスに対して各プロキシプロキシを設定する場合があります）。別のオプションは、汎用キャッシュシステムを使用して各サービスに独自のキャッシュを実装させることです（各キャッシュは、たとえばキャッシュを作成して処理する抽象サービスから拡張し、実装クラスは外部サービスを直接呼び出さずに、メソッドに任せます）キャッシングも処理する抽象ベース）。

両方の亜種について言うべきことがあります。もちろん、1つ目は、初期コーディングの労力は少なくて済みますが、内部のネットワーク負荷が高くなることを意味します。 2つ目はネットワーク負荷が低くなりますが、既存のサービスを書き換えて実装するためにさらに多くの作業を行う必要があります（将来のサービスについては、構成するときではなくコーディングするときに準拠する必要がある場合、プログラマーを信頼するか、あなたの実装スペシャリストはもっといますか？それとも彼らは同じ人ですか...）.

2
jwenting

キャッシュを抽出する必要がある理由は3つだけです。

  • 複数の内部サービスが同じ外部サービスと対話します。すべてのサービスがキャッシュを共有する場合、キャッシュヒットが多くなり、キャッシュ間の重複が少なくなるため、これは正味のメリットになる可能性があります。

  • 外部サービスとのやり取りはかなり複雑であり、内部サービスに簡略化されたAPIを提供したいと考えています。ここでは、キャッシングサービスはむしろ「アダプタ」になります。ただし、ネイティブライブラリもおそらく機能するため、アダプタを個別のサービスに変換する必要はありません。

  • リソース要件のため、キャッシュは予約サービスとは異なるハードウェアで実行する必要があります。他のサービスとは別にキャッシュをスケーリングしたいとします。例えば。予約サービスとキャッシュの両方がRAMに制約がある場合、2つの中規模サーバーは、両方に十分なリソースを持つ巨大なサーバーよりも安価になる可能性があります。

2
amon