2

内部ノード間通信に現在 HTTP/REST を使用しているマイクロサービス アーキテクチャの最適化を検討しています。

1 つのオプションは、バックプレッシャ機能をサービスに実装することです (たとえば、Quasar のようなものをスタックに統合することによって)。これは間違いなく物事を改善するでしょう。しかし、いくつかの課題があります。1 つは、非同期クライアント スレッドが一時的 (メモリ内) であり、クライアントに障害 (クラッシュ) が発生すると、これらの再試行スレッドが失われることです。2 つ目は、理論的には、ターゲット サーバーがしばらくダウンしている場合、クエーサー ファイバーであってもスレッドが最終的に制限されるため、クライアントは再試行を試みて最終的に OOM に到達する可能性があります。

少し偏執的であることはわかっていますが、キューベースの代替手段が非常に大規模な場合により有利になるかどうか疑問に思っています。

ただし、a) キューが中央で管理され、クライアント JVM から切り離されていること、b) キューが永続的であるため、クライアントやターゲット サーバーがダウンした場合、処理中のメッセージがないことを除きます。失われます。

もちろん、キューの欠点は、ホップが多くなり、システムの速度が低下することです。しかし、Quasar の ROI がピークに達し、一元化された耐久性のあるキューがスケーリングと HA にとってより重要になるスイート スポットがおそらくあると思います。

私の質問は：

このトレードオフは議論されましたか? サービス内通信に集中型の外部キュー/ルーター アプローチを使用することに関する論文はありますか。

TL;DR; この質問はおそらく次のように表現できることに気付きました。

「マイクロサービス アーキテクチャ内で直接 HTTP を使用するのではなく、メッセージ バス ベースのサービス内通信を使用するのが適切なのはいつですか。」

4

1 に答える 1

5

大規模に実行する場合、マイクロサービス アーキテクチャで 3 つの一般的なプロトコル設計パターンを見てきました。

  1. ActiveMQ や Apache Qpid などの中央ブローカーを使用するメッセージ バス アーキテクチャ。
  2. 「回復力のある」HTTP。回復力を高めるために HTTP に追加のロジックが構築されています。ここでの典型的なアプローチは、Hystrix (Java)、または SmartStack/Baker St (スマート プロキシ) です。
  3. NSQ、ZMQ、Qpid Proton などを使用したポイントツーポイントの非同期メッセージング。

最も一般的な設計パターンは #2 で、キューが必要な場合は #1 が少し混ざっています。

理論的には、#3 は両方の長所 (回復力とスケールとパフォーマンス) を提供しますが、テクノロジはすべてやや未熟です。#2 を使用すると、非常に遠くまで到達できることがわかります (たとえば、Netflix はどこでも Hystrix を使用しています)。

あなたの質問に直接答えるために言えば、#1 はシステム全体に 1 つのボトルネックを作成するため、排他的なデザイン パターンとして使用されることはほとんどありません。#1 は、システムのサブセットに共通です。ほとんどの人に、今日は #2 をお勧めします。

于 2015-08-13T13:31:13.880 に答える