GraphQL、Kafka、Docker、Kubernetes、MongoDBを使用して、スケーラブル、コンテナ化、管理可能なAPIを構築するにはどうすればよいですか？
私はそれぞれのテクノロジーが何をするかについて疑いの余地はありません。私もそれらすべてを試しました。私が疑っているのは：
GraphQLを使用する場合、GraphQLサーバーがダウンすると、単一障害点のように動作しませんか？クラスター化できますか。クラスター化できる場合、使用可能なアーキテクチャーはありますか？
kafkaがマイクロサービスの世界で使用されている理由を知っています。GraphQLを使用している場合、kafkaは無関係になるか、KafkaはまだGraphQLで意味がありますか？
マイクロサービスを構築する場合、Dockerを使用してすべてのマイクロサービスをコンテナ化し、オーケストレーションにKubernetesを使用し、ストリーミングレイヤーにKafka=を使用することができますが、GraphQLを使用する場合、それはモノリスとして構築され、アプリケーション全体です。それとも、コードをモジュール化し、サーバーのさまざまなモジュールをコンテナー化して、GraphQLを介してそれらをクエリするのでしょうか？
GraphQLを介して実装する場合、データベースレイヤーはどこにどのように存在する必要がありますか。マイクロサービスの場合、マイクロサービスごとに1つのDBインスタンスを使用します。
コンテキストについては、GraphQLを使用してスケーラブル、コンテナ化、および管理可能なAPIを構築するアーキテクチャを考えています。
質問にdockerとkubernetesが含まれる理由がわかりません。アーキテクチャに対応するためにdockerをどのようにセットアップするかはあなた次第であり、アーキテクチャの決定において役割を果たすべきではありません。
はい、いつでもアプリケーション上の複数のgraphqlサーバーにまたがることができます。これらの複数のgraphqlサーバーで発生するリクエストをどのように処理するかは、あなた次第です。一部のアプリケーションがこれをユースケースベースで処理するのを見てきましたが、はい、あなたの質問を処理するためにこれは間違いなくスケーリングできます。これも役に立つかもしれません- https://dev-blog.apollodata.com/graphql-schema-stitching-8af23354ac37 。
データストリーミング機能が必要な場合は、Kafkaが便利です。したがって、理想的にはデータベースを持つことができます->複数Kafkaインスタンスがデータベースと通信する->各Kafkaインスタンスは、それを処理する複数のGraphQL APIを持つことができます。
私はこのビデオを見ました： https://www.youtube.com/watch?time_continue=2308&v=ykp6Za9rM58 （33分までシークします）、以下のモデルを取得しました：
追加するものは1つだけですkafkaゲートウェイとサーバーの間にあり、さまざまなサーバーに送信されるgraphqlクエリのストリーミングプラットフォームとして機能します。（主にkafkaあるモジュールが別のモジュールと直接通信することを望まないため。）複雑さを回避し、イベントソースとgraphqlのCQRSを使用するためのバスが必要でした。
次に、すべてのサーバーをコンテナー化して、スキーマステッチを使用して、1つの単一のgraphqlクエリを複数のステートメントに分割します。