タグ付けされた質問 「microservices」

マイクロサービスのオーケストレーションの標準パターンは何ですか？ マイクロサービスが自身のドメインのみを認識しているが、複数のサービスが何らかの方法で相互作用することを必要とするデータの流れがある場合、それについてどうするのですか？ 次のようなものがあるとします。 請求 発送 そして議論のために、注文が発送されたら、請求書を作成する必要があるとしましょう。 どこかで、誰かがのボタンを押したGUI、「完了しました、これをやりましょう！」古典的なモノリスサービスアーキテクチャでは、これをESB処理するか、出荷サービスが請求書サービスの知識を持っていて、それを呼び出すだけだと思います。 しかし、人々がこの勇敢な新しいマイクロサービスの世界でこれに対処する方法は何ですか？ これは非常に意見に基づいたものと考えることができると思います。しかし、マイクロサービスは上記を行うことを想定していないため、具体的な側面があります。したがって、意見に基づくものではない「定義上、代わりに何をすべきか」が必要です。 シュート。

200 http  orchestration  hypermedia  microservices 

ユーザー、ウォレットRESTマイクロサービス、および物事を接着するAPIゲートウェイがあるとします。BobがWebサイトに登録するとき、APIゲートウェイは、Userマイクロサービスを介してユーザーを作成し、Walletマイクロサービスを介してWalletを作成する必要があります。 次に、問題が発生する可能性があるいくつかのシナリオを示します。 ユーザーBobの作成は失敗します。問題ありません。エラーメッセージをBobに返します。SQLトランザクションを使用しているため、システム内でBobを見た人はいません。すべて良し ：） ユーザーBobが作成されましたが、ウォレットを作成する前に、APIゲートウェイがハードクラッシュします。これで、ウォレットのないユーザー（データに一貫性がない）ができました。 ユーザーBobが作成され、ウォレットを作成すると、HTTP接続がドロップします。ウォレットの作成が成功したか、成功しなかった可能性があります。 この種のデータの不整合が発生しないようにするには、どのような解決策がありますか？トランザクションが複数のRESTリクエストにまたがることを可能にするパターンはありますか？私はこの問題に触れていると思われる2フェーズコミットのWikipediaページを読みましたが、実際にそれを適用する方法がわかりません。このAtomic Distributed Transactions：RESTfulなデザインペーパーも興味深いですが、まだ読んでいません。 あるいは、RESTがこのユースケースに適していない可能性があることも知っています。この状況を処理してRESTを完全に削除し、メッセージキューシステムのような別の通信プロトコルを使用する正しい方法でしょうか？または、アプリケーションコードに整合性を適用する必要がありますか（たとえば、不整合を検出して修正するバックグラウンドジョブを実行するか、ユーザーモデルに「作成」、「作成」の値などの「状態」属性を設定するなど）。

195 rest  architecture  transactions  microservices 

マイクロサービスアーキテクチャ内でGraphQLを使用するのに最適な場所を理解しようとしています。 APIゲートウェイとして機能する1つのGraphQLスキーマのみを使用して、リクエストされたマイクロサービスにリクエストをプロキシし、そのレスポンスを強制することについては、いくつかの議論があります。マイクロサービスは依然として通信の考え方にREST / Thriftプロトコルを使用します。 代わりに、マイクロサービスごとに1つずつ、複数のGraphQLスキーマを使用する方法もあります。リクエストのすべての情報とGraphQLクエリを使用して、リクエストをターゲットのマイクロサービスにルーティングする小さなAPIゲートウェイサーバーを用意します。 最初のアプローチ 1つのGraphQLスキーマをAPIゲートウェイとして使用すると、マイクロサービスコントラクトの入出力を変更するたびに、それに応じてAPIゲートウェイ側でGraphQLスキーマを変更する必要があるという欠点があります。 2番目のアプローチ マイクロサービスごとに複数のGraphQLスキーマを使用する場合、GraphQLがスキーマ定義を適用し、コンシューマーはマイクロサービスから提供される入出力を尊重する必要があるため、ある意味で理にかなっています。 ご質問 GraphQLがマイクロサービスアーキテクチャの設計に適しているかどうか。 GraphQLを実装できるAPIゲートウェイをどのように設計しますか？

176 architecture  microservices  graphql 

マイクロサービスアーキテクチャにまともな/安全な認証戦略を選択するのに苦労しています。このトピックで私が見つけた唯一のSO投稿はこれです：マイクロサービスアーキテクチャでのシングルサインオン ここでの私の考えは、各サービス（たとえば、認証、メッセージング、通知、プロファイルなど）で各ユーザーへの一意の参照（論理的には彼のuser_id）と、idログインした場合に現在のユーザーの固有の参照を取得することです。 私の研究から、2つの可能な戦略があることがわかります。 1.共有アーキテクチャ この戦略では、認証アプリは他のサービスの1つです。しかし、各サービスは変換を行うことができる必要がありますsession_id=> user_idしたがって、非常にシンプルでなければなりません。それが私がRedisを考えた理由です、それがkey：valueを保存するでしょうsession_id:user_id。 2.ファイアウォールアーキテクチャ この戦略では、認証アプリによってのみ処理されるため、セッションストレージはそれほど重要ではありません。その後、user_id他のサービスに転送できます。Rails + Devise（+ Redisまたはmem-cached、またはcookieストレージなど）について考えましたが、可能性はたくさんあります。重要なのは、Service Xがユーザーを認証する必要がないことです。 これらの2つのソリューションは、次の点でどのように比較されますか。 安心 堅牢性 スケーラビリティ 使いやすさ それとも、ここで言及していない別の解決策を提案するでしょうか？ 私はソリューション1の方が好きですが、私が正しい方向に進んでいるという事実で私を保護するデフォルトの実装をあまり見つけていません。 私の質問が閉じられないことを願っています。他にどこに質問すればいいのか本当にわからない。 前もって感謝します

138 authentication  architecture  microservices 

モノリシックアプリケーションをマイクロサービスに分割している人々にとって、データベースを分解するという難問をどのように処理していますか。私が取り組んだ典型的なアプリケーションは、パフォーマンスと単純さの理由から、多くのデータベース統合を行っています。 論理的に異なる2つのテーブル（境界コンテキストがある場合）があり、そのデータの大容量に対して集約処理を行うことが多い場合、モノリスではオブジェクト指向を避け、代わりにデータベースの標準を使用します。統合されたビューをアプリ層に戻す前に、データベース上のデータを処理するJOIN機能。 データベースではなくAPIを介してデータを「結合」する必要があると思われるマイクロサービスに、そのようなデータを分割することをどのように正当化しますか。 私はSam NewmanのMicroservicesの本を読み、Monolithの分割に関する章で、「外部キーの関係の破壊」の例を挙げています。彼は、API全体での結合の実行が遅くなることを認めていますが、とにかくあなたのアプリケーションは十分に速いです、それが以前より遅いことが重要ですか？ これは少しグリブのようですか？人々の経験は何ですか？API結合を許容範囲内で実行するためにどのようなテクニックを使用しましたか？

112 database  integration  microservices 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 5年前休業。 この質問を改善する 最近、共同作業する複数のマイクロサービスをデプロイするために、Docker Composeでいくつかの実験を行っています。マイクロサービスが提供する多くの利点を見ることができ、それらを管理するための優れたツールセットがあるので、マイクロサービスワゴンに飛び込むことはそれほど難しくないと思います。 しかし、私はElixirも実験しており、それ自体がもたらす利点をとても気に入っています。それはあなたのコードを複数の分離されたアプリケーションに詰め込むことを奨励し、ホットコードのアップグレードをサポートすることを考えると、どのようにdockerをelixir（またはそのことについてはerlang）と混合しますか？ たとえば、dev-prodパリティを提供するためにdockerを使用したい場合、elixirはそれにどのように適合しますか？Dockerコンテナーは不変であることを考えると、ホットコードのアップグレードを実行できなくなりますよね？青/緑のデプロイメントまたはカナリアリリースについてはどうですか？ つまり、Elixirでマイクロサービスを作成して、他の言語で作成されているかのようにそれらを使用することができます。ポリグロティズムは、いずれにせよマイクロサービスの利点の1つですが、OTPプラットフォームを使用することの完全な利点は得られません。純粋なコラボレーティブerlangアプリケーションは、中間のキューを使用して異なる（または異なる）言語で記述されたマイクロサービス間で通信するよりもはるかに最適であると推測します。

109 architecture  erlang  docker  elixir  microservices 

マイクロサービスアーキテクチャを処理するために、リバースプロキシ（nginxやapache httpdなど）と一緒に使用されることが多く、横断的な懸念のために APIゲートウェイパターンが使用されます。リバースプロキシがAPIゲートウェイの機能を実行する場合があります。 これら2つのアプローチの明確な違いを確認するとよいでしょう。APIゲートウェイの使用の潜在的な利点は、複数のマイクロサービスを呼び出して結果を集約することです。APIゲートウェイの他のすべての責任は、リバースプロキシを使用して実装できます。 認証（nginx LUAスクリプトを使用して行うことができます）; 輸送のセキュリティ。それ自体が逆プロキシタスクです。 負荷分散 .... したがって、これに基づいていくつかの質問があります： APIゲートウェイとリバースプロキシを同時に使用することは理にかなっていますか（たとえば、リクエスト-> APIゲートウェイ->リバースプロキシ（nginx）->具体的なmictoservice）。どのような場合に？ APIゲートウェイを使用して実装でき、リバースプロキシで実装できない他の違いは何ですか？

107 nginx  reverse-proxy  microservices  aws-api-gateway  tyk 

クローズ。この質問はもっと焦点を合わせる必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てるようにします。 4年前に閉鎖されました。 この質問を改善する マイクロサービスについて読んだのですが、少し興味があります。面白いコンセプトのようです。しかし、モノリシックアーキテクチャよりもマイクロサービスを使用する場合の長所と短所は何ですか。その逆も同様です。 マイクロサービスがより適切な場合、およびモノリシックアーキテクチャを使用するのに適した場所。

83 microservices 

モデル（製品、ID、タイトル、価格）を制御するサービスA（CMS）と、与えられたモデルをどのように表示する必要があるかを示す必要があるサービスB（配送）とC（メール）があるとします。イベントソーシングアプローチでこれらのサービス全体で特定のモデル情報を同期するには 商品カタログがめったに変更されない（ただし変更される）と、出荷および電子メールのデータに頻繁にアクセスできる管理者がいるとします（機能例：B：display titles of products the order containedおよびC：）display content of email about shipping that is going to be sent。各サービスには独自のDBがあります。 解決策1 イベント内の製品に関する必要なすべての情報を送信します-これは以下の構造を意味しますorder_placed： { order_id: [guid], product: { id: [guid], title: 'Foo', price: 1000 } } サービスBおよびCでは、製品情報はテーブルのproductJSON属性に格納されordersます そのため、必要な情報を表示するために、イベントから取得されたデータのみが使用されます 問題：BとCで提示する必要のある他の情報によっては、イベントのデータ量が増える可能性があります。BとCはProductについて同じ情報を必要としない場合がありますが、イベントには両方を含める必要があります（イベントを2つに分割しない限り）。特定のデータが特定のイベント内に存在しない場合、コードはそれを使用できません- 特定の製品に色オプションを追加すると、BおよびCの既存の注文に対して、イベントを更新して再実行しない限り、特定の製品は無色になります。 。 解決策2 イベント内の製品のガイドのみを送信-これは以下の構造を意味しますorder_placed： { order_id: [guid], product_id: [guid] } サービスBおよびCでは、製品情報はテーブルのproduct_id属性に格納されますorders 製品情報は、A/product/[guid]エンドポイントへのAPI呼び出しを実行することにより、必要に応じてサービスBおよびCによって取得されます 問題：これにより、BとCが（常に）Aに依存します。製品のスキーマがAで変更された場合、それらに依存するすべてのサービスで（突然）変更を行う必要があります。 …

10 microservices  event-sourcing 

Amazon fargateを使用したDockerコンテナーを使用した最初のマイクロサービスを作成しています。Spring Bootを使用した実装レベルには多くの疑問があります 私たちはプロジェクトに複数のマイクロサービスを用意します。すべてのマイクロサービスを単一のコンテナーで作成することは良い習慣ですか、それとも個別のマイクロサービス用に個別のDockerコンテナーを作成する必要がありますか。費用対効果の高い方法で単一のコンテナを使用していますが、それが将来のプロジェクト構造に問題を引き起こすのでしょうか？ 私たちはアプリケーションをAWSファーゲートにデプロイすることを計画しており、私たちのアプリケーションは将来拡張する大きなオプションがあり、約100から150の異なるマイクロサービスを期待しています。この場合、これらのすべてのマイクロサービスを別のコンテナーにアップロードするのも費用対効果が高いですか？

9 docker  microservices  docker-container  aws-fargate 

要旨 マイクロサービスベースのアーキテクチャ（Kubernetes）で実行されるアプリケーションがあります。アプリケーションの外部とのすべての通信は、API Gatewayを介して行われます。 つまり、私のフロントエンドからのリクエストはサービスに直接送信されませんが、ゲートウェイを経由する必要があります。 動かす 次に、フロントエンドと内部サービス間のリアルタイム通信を必要とする機能を実装する必要があります。しかし、内部サービスは外部に公開されていないため、ゲートウェイを介してリアルタイムデータを「ルーティング」する方法が必要です。 すべてのサービスがNode.jsで実行されているため、Socket.IOを使用してリアルタイム通信を実装したいのです。 問題 しかし、スケッチから紫色の二重矢印を実装する方法は？ そのため、通常、フロントエンドクライアントは、Socket.IOが実行されているサーバーに接続します。しかし、私の場合、このサーバー（リアルタイム機能サーバー）はクライアントからアクセスできません（アクセスできないはずです）。つまり、クライアントはゲートウェイに接続する必要があります。したがって、ゲートウェイは、すべての着信メッセージをリアルタイムサービスとその逆にルーティングするメカニズムを実装する必要があります。 アイデア （1）ゲートウェイでイベントをリッスンする2番目のHTTPサーバーを用意し、それらのイベントをリアルタイムサーバーに送信します。反対の方向では、リアルタイムサーバーはゲートウェイにイベントを発行し、ゲートウェイはそれをフロントエンドに発行し​​ます。このアプローチは間違いなくうまくいくと思いますが、すべてを2回放出するのは冗長なようです。そして、それは間違いなくパフォーマンスを損なうでしょうか？ （2）Socket.IOアダプターを使用して「ノード間でイベントを渡す」。これは「プロセスまたはコンピューター間でメッセージを渡す」ために使用されるため、正しい方法と思われます。しかし、ドキュメントやサンプルが不足しているため、使用を開始するのに問題があります。私もRedisを使用していません（アダプターを使用するために必要ですか？） （3）socket.io-emitterパッケージを使用します。これは、最後のコミットが3年前からあったため、良いオプションとは思えません。 （4）他に何かありますか？

8 node.js  sockets  kubernetes  socket.io  microservices