分散サービスガバナンスの設計上の問題はありますか?

C++ を使用してマイクロサービスの [登録センター] を実装し、この登録センターの高可用性を実装しました。サービスがオンラインになると、[登録センター] に登録されます。登録センター] がプッシュされます。このサーバー アドレスは [サービス コンシューマー] に送信されます。このように、[サービス コンシューマ] はすべての [マイクロサービス マップ] を保持します。負荷分散は [サービス コンシューマ] 内で行われるため、[サービス コンシューマ] はメモリ上に常駐する必要があります。 Python にとっては Java の方が簡単ですが、FPM を使用する PHP にとっては、従来の FPM PHP がこのアーキテクチャをサポートできるように PHP を変換する方法に相当します。 Dubboも似たような感じでやっているようなので、フロントエンドをPHPでやるとちょっと大変ではないでしょうか？

返信内容:

負荷分散には 2 つの方法があります:

クライアント負荷分散、通常は Finagle と Dubbo。利点は、実装が簡単で、サービスが直接接続されており、パフォーマンスが高いことです。欠点は、複数の言語を使用する場合、言語ごとにクライアントを実装する必要があることです。

サーバー側のロードバランシング、典型的なロードバランサーはNginxとHAProxyです。通常、リバース プロキシはサービスの前に追加されます。クライアントはリバース プロキシを介してサーバーと通信し、特定の負荷分散ロジックはロード バランサーによって実装されます。ロードバランサー自体をレジストリに登録することもできます。利点は、クライアントが非常にシンプルであり、複数の言語をサポートしていることです。欠点は、パフォーマンスが若干低下することです。

具体的な選択は、ビジネスと企業のテクノロジーの選択によって異なります。多言語シナリオでは、サーバー側のソリューションにより、クライアントを保守するチームがいる場合は、もちろん、そのことについては言及しませんが、結局のところ、そのチームは何をする必要があるのでしょうか。

純粋な Java シナリオの場合、Dubbo または同様のフレームワークがすでにサポートされている場合は、気にする必要はありません。

メインのシナリオに戻ると、PHP サービスでサービス検出を実装する必要がある場合は、サービス レジストリを memcache に置くなどしてキャッシュし、時々再度プルすることができます。

上 最も簡単な (そしておそらく最も信頼できる) 解決策は、PHP サーバー上でエージェントを実行して登録センターを監視することです。このエージェントは、FPM によって PHP が呼び出された後、この構成を読み取ります。 。

一般的に、ほとんどすべてのフレームワークには設定ファイルがあります。このファイルを直接変更するだけで済みます (設定ファイルを読み取る必要があるため)。 この設計方法には一定の利点があります。つまり、サービス バスに属する一部の機能がサービス コンシューマ ノードに完全に下位層化されており、この方法ではバス自体の機能が軽くなり、サービスの登録と登録の配布のみを管理します。情報。登録センターのダウンタイムは、基本的にサービスの消費と呼び出しには影響しません。

先ほど述べた問題を考慮すると、解決策は 2 つあります。1 つは、ルーティングや負荷分散など、バスに戻るサービス エージェントの機能を改善することです。これを実行したくない場合は、別のサーバーをセットアップして、このサーバーにサービス消費とルーティング バランシング ロジックを実装することも検討できます。このサーバーは、PHP アプリケーションに対応するバックエンド プロキシとみなすことができます。 マイクロサービスでクライアント負荷分散を使用することは大きなトレンドだと思います。理由は 3 つあります。1 つはパフォーマンス上の利点です。2 つ目は、登録センターがダウンしても正常に実行できることです。ダウングレードなどのロジックについては、クライアント自体がサーキット ブレーカーとサービスを実装する必要があるため、単純な負荷分散ロジックを実装することをお勧めします。 PHP にはあまり詳しくありませんが、サービス構成を特定の service_config.php ファイルに書き込み、この service_config.php を他のファイルに含めることは可能ですか?以前に検出されたファイルのタイムスタンプが含まれます。一定時間 (1 分など) を超えると、構成書き込みファイルが登録センターから再度取得されます。 2 つのソリューション

1. Swoole: PHP の非同期、並列、高性能ネットワーク通信エンジン
swoole を使用して、永続的な内部テスト PHP サーバーを作成できます

2. キャッシュ
APCu を使用します (PHP: APCu - マニュアル)
) または redis では、サーバー アドレス リストをキャッシュします。これは、特定のパフォーマンス要件とサービス リストの一貫性要件によって異なります。ネットワーク オーバーヘッドが心配な場合は、キャッシュが短くなる可能性があります。 Redis キャッシュの読み取りと書き込みの場合、APCu を使用できます。このローカル キャッシュ むくむ