Azure Service Fabric の BUILD カンファレンス ビデオを見た後、これが現在のマイクロサービス ベースのアーキテクチャにどのように適合するかを想像しました。ただし、解決方法が完全にはわからないことが 1 つあります。それは、API ゲートウェイ/プロキシです。
REST エンドポイントを公開する Azure Service Fabric 内で N 個のサービスが実行されている、それほど重要ではないマイクロサービス アーキテクチャを考えてみましょう。多くの場合、これらのフラグメント化された API エンドポイントを、コンシューマーが使用できる単一エントリ API にパッケージ化して、サービス ファブリック インスタンスに直接接続することを避ける必要があります。Azure Service Fabric ソリューションはあらゆる点で非常に完成度が高いように見えるので、BUILD の説明で言及された機能の範囲内でこれを自明に解決する方法が見当たらない場合、明らかな何かを見落としているのではないかと思うほどです。
Vulcanのようなサービスは、サービスにルーティングしたいパスをetcdに登録させることで、この問題を解決することを目指しています。これを解決する1つの方法は、他のサービスが自分自身を登録できる別のステートフルWebサービスを作成し、サービス名とそれらにルーティングする必要があるパスを提供することだと思います. ステートフル Web サービスは、その状態に基づいてトラフィックを正しいインスタンスにルーティングできます。ただし、アプリケーションが削除されたときにルートを削除したり、通常はクラスター内にデプロイされたサービスと状態を同期させたりするなど、これは完全に理想的ではないようです。誰かがこれについて何か考えたことはありますか、または Azure Service Fabric 内でこれを解決する方法についてアイデアを持っていますか?