分散アプリケーションでの構成
複数の負荷分散されたインスタンスから提供される個別のサービスのコレクションとして構築された分散アプリケーションを開発しており、分散構成の問題を回避しようとしています。
私の背景は組み込みシステムであり、大規模なシステムについてはそれほど多くないので、SaaSシステムの場合は、私のアイデアについてのフィードバックをいただければ幸いです。構成を正しく実装することについて、さらに多くのアイデアを得ることもできます。
もう少し背景：
「構成」とは、APIを使用して認証されたユーザーが実行時に変更でき、すべてのインスタンスに適時に適用されるユーザープロファイルを意味します（電子メールフィルタールールは、DB接続文字列ではなく、ロードされ、インスタンスの存続期間中静的に保たれ、ユーザーからは隠されます）。
各サービスは、（セキュリティおよびパフォーマンス上の理由から）フォークされたHTTPサーバーとして実装され、個別のサービスは個別の構成を使用します（つまり、サービスは通常、他のサービスの構成構造/スキーマを認識しません）。ユーザーが構成を変更する頻度は比較的低く、要件は構成の変更によりサービスのダウンタイムが発生しないことです（一部の展開では各サービスのインスタンスが1つしかないため、段階的な再起動戦略は実際にはオプションではありません）。現在、構成はローカルから読み込まれますINIシグナルで再読み込みされるファイルであり、許容できるわずかな遅延が発生します。
だから私の考えに：
計画は、中央ストア（DBやKVストア（領事など））を使用し、各サービスインスタンスに沿ってエージェントを実行して変更をポーリング/受信し、エンドポイントをローカルで呼び出して新しい構成を検証し、 INIファイルをメモリにコピーして更新します（つまり、各インスタンスがローカル構成ストアを管理します）。
どうして？これにより、サービスが特定の構成プロバイダー/プロトコル/クライアントに依存しないようにすることができます。さらに、中央ストアが起動していることに依存しません。私の場合は必須であり、無効な構成が単一のインスタンスに適用されていません。 。
新しい構成がだまされたことを確認する方法：構成の一部として保存されている一意の値を添付し、各インスタンスにこの値を監視システムが監視できる/ healthエンドポイントにエクスポートさせる（これは必ずしもすべての事前フォークされたプロセスはメモリコピー内でそれ自体を更新しましたが、この問題を別の時間に残しましょう）。
分散構成ストアの更新方法：複数のサービスの構成を受信するAPIを備えた個別の構成サービス。各構成は構成済みサービスの任意のインスタンスによって検証され、その後、中央ストアにのみ保持されます。
フィードバックやアドバイスをありがとうございます。
「構成」と「アプリケーションの状態」を区別するこの種の問題の主要な問題の1つに触れます
https://www.consul.io/ などのツールがあり、分散サービスの構成の動的な変更を支援するように設計されています。しかし、私の見解では、そのアプローチは誤りです。
私は定義します：
- 構成：起動時に設定が読み込まれ、アプリケーションを再デプロイすることによってのみ変更されます
- アプリケーションの状態：ユーザーの操作によって動的に変更される設定。
構成を動的に変更しようとする場合の問題は、デプロイメントに関する変更制御が失われ、それを他のシステムで置き換えないと、アプリケーションの期待される動作を説明できないことです。特に切り替え中、またはキャッシュされた設定で。
当然、アプリケーションの状態についても同じ問題がありますが、アプリケーションは通常、これが動的に変化するという考えでプログラムされています。
言及している種類の問題を回避するには、これら2つのタイプの状態を明確に区別することが重要です。
特定の状況では、INIファイルからデータベースに状態を移動します。これで、API呼び出しでデータベースを変更し、ノードに同じAPIを呼び出して設定を読み取らせることができます。これにより、これらの設定がシステムの責任ではないことは完全に明らかです。変更をノードにプッシュアウトするために、何らかのリスンエンドポイントを追加することもできます。
現在のアプリケーションの状態を報告するヘルスエンドポイントは素晴らしいアイデアです。これらは標準的な方法である必要があり、バージョン番号、構成設定、および接続性チェックを報告することで、展開の問題が発生した場合の調査作業を大幅に節約できます。