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

マイクロサービスは、相互に通信して言語に依存しないAPIを利用する複雑なアプリケーションを形成する小さな独立したプロセスです。これらのサービスは小さなビルディングブロックであり、高度に分離されており、小さなタスクの実行に重点を置いており、システム構築へのモジュール式アプローチを容易にします。

5
マイクロサービスに移行すると、実行時の問題がどのように発生しますか？
次のコメンテーターは書いています： マイクロサービスは、組織の機能障害をコンパイル時の問題から実行時の問題に移行します。 このコメンテーターは、問題について次のように説明しています。 機能はバグではありません。実行時の問題=>製品の問題=>責任者への機能障害に関するより強力で迅速なフィードバック 今、私はそれを取得しmicroservicesあなたは： スループットのレイテンシーを潜在的に増加させます-これは生産および実行時の懸念です。 解析の実行時エラーが発生する可能性があるコード内の「ネットワークインターフェイス」の数を増やします。 潜在的に青緑の展開を行うことができます。これらは、インターフェイスの不一致によって保持される可能性があります（ネットワークインターフェイスを参照）。ただし、青緑の展開が機能する場合は、実行時の懸念が大きくなります。 私の質問は、マイクロサービスに移行すると実行時の問題が発生するということです。
7
マイクロサービスで最も受け入れられているトランザクション戦略は何ですか
マイクロサービスを備えたシステムで発生した主要な問題の1つは、トランザクションが異なるサービスにまたがる場合のトランザクションの動作方法です。独自のアーキテクチャ内では、これを解決するために分散トランザクションを使用してきましたが、独自の問題があります。特にこれまでのところ、デッドロックは苦痛です。 別のオプションは、システム内のフローを認識し、システム全体にまたがるバックグラウンドプロセスとしてロールバックを処理する、カスタムメイドのトランザクションマネージャーのようです（他のサービスにロールバックするよう指示します）ダウンしている場合は、後で通知します）。 別の受け入れられるオプションはありますか？これらの両方に欠点があるようです。最初のものはデッドロックやその他の問題を引き起こし、2番目のものはデータの不整合を引き起こす可能性があります。より良いオプションはありますか？
7
マイクロサービスシステムアーキテクチャはどのようにネットワークのボトルネックを回避しますか？
私はサーバーアプリケーションのマイクロサービスアーキテクチャについて多くのことを読んでおり、内部ネットワークの使用がモノリスアーキテクチャに比べてボトルネックや重大な欠点ではないことを疑問に思っていました。 正確さのために、2つの用語の解釈を以下に示します。 モノリスアーキテクチャ：すべての機能、データなどを処理する単一言語の1つのアプリケーション。ロードバランサーは、アプリケーションの1つのインスタンスを実行する複数のマシンにエンドユーザーからのリクエストを分散します。 マイクロサービスアーキテクチャ：機能とデータのごく一部を処理する多くのアプリケーション（マイクロサービス）。各マイクロサービスは、（同じマシン上のプロセス間通信または共有メモリとは対照的に）ネットワークを介してアクセスされる共通のAPIを公開します。API呼び出しは、主にサーバー上でページを生成するためにスティッチングされますが、おそらくこの作業の一部は、個々のマイクロサービスを照会するクライアントによって行われます。 単純な想像では、マイクロマシンアーキテクチャは、同じマシン（メモリとディスク）の高速リソースとは対照的に、低速ネットワークトラフィックを使用するようです。内部ネットワークを介したAPIクエリにより、全体の応答時間が遅くならないようにするにはどうすればよいですか？
5
別のマイクロサービスによって「所有」されているデータベースからデータを読み取ることがなぜそれほど悪いのか
最近、マイクロサービスアーキテクチャに関する次の優れた記事を読みました。http：//www.infoq.com/articles/microservices-intro AmazonにWebページをロードすると、100以上のマイクロサービスが協力してそのページを提供することが記載されています。 その記事では、マイクロサービス間のすべての通信はAPIを介してのみ行うことができると説明しています。私の質問は、すべてのデータベースの書き込みはAPIを介してのみ可能であると言うのがなぜ悪いのかということですが、さまざまなマイクロサービスのデータベースから直接読み取ることができます。たとえば、マイクロサービスの外部からアクセスできるデータベースビューはごくわずかであるため、マイクロサービスを管理するチームは、これらのビューをそのまま保持している限り、マイクロサービスのデータベース構造を変更できることを知ることができます。欲しいです。 ここに何かが足りませんか？API経由でのみデータを読み取る必要がある他の理由はありますか？ 言うまでもなく、私の会社はAmazonよりもずっと小さく（常にそうです）、私たちが持つことのできるユーザーの最大数は約500万人です。
5
異なるマイクロサービス間の共有ドメインモデル
2つの異なるマイクロサービスのシナリオを想像してください。1つはサービス内で認証を処理し、もう1つはユーザー管理を処理します。どちらもユーザーの概念を持ち、お互いの呼び出しを通じてユーザーについて話します。 「ユーザー」のドメインモデルはどこに属しますか？それらは両方とも、ユーザーがデータベースのレベルで何であるかの異なる表現を持っていますか？API呼び出しで使用するUserDTOがある場合、両方ともそれぞれのAPIに1つありますか？ この種のアーキテクチャの問題に対して一般的に受け入れられているソリューションは何ですか？
6
マイクロサービスでは、サービスごとに単一のデータベースまたは単一のデータベースインスタンスですか？
マイクロサービスアーキテクチャの各サービスには独自のデータベースが必要であることを理解しています。しかし、独自のデータベースを持つということは、実際には、同じデータベースインスタンス内に別のデータベースを単に持つことを意味しますか、それとも文字通り別のデータベースインスタンスを含むことを意味しますか？ これにより、私はデータベースの共有を意味するのではなく、これはノー・ノーであり、むしろデータベースのインスタンスです。 たとえば、AWSを使用していて3つのサービスがある場合、単一のRDSインスタンスで各サービスに3つのデータベースを作成しますか、3つのサービスのそれぞれで独立して使用されるデータベースを含む3つのRDSインスタンスを作成しますか？ 単一のRDSインスタンスで複数のデータベースを使用することをお勧めする場合、次の理由により、独立したサービスを持つという目的を無効にします。 RDSインスタンスのリソースはサービス間で共有されます。特定の時間にデータベースの使用量が多い可能性のあるサービスAは、同じRDSインスタンス上で異なるデータベースを使用するサービスBに影響しますか？ すべてのサービスは、そのRDSインスタンスのデータベースバージョンに依存します。
2
マイクロサービスアーキテクチャで共有の概念をどのように処理しますか？
開発中のアプリケーションのアーキテクチャパターンを調査しており、マイクロサービスアプローチが適切な選択のように思えますが、サービス間の相互作用を処理する方法はわかりません。 このアプリケーションは主に、ユーザー、ユーザーが所有するプロファイル、写真、および写真内の1つから多数のプロファイルを表すタグを扱います。ユーザーがアップロードした写真を返す方法、特定のタグ付きプロファイルを含む写真を返す方法などが考えられます。 これはマイクロサービスベースのアーキテクチャを設計する最初の試みであり、モノリシックなドメインモデルに触発された歴史から来ています。その世界では、コントローラーはこれらのドメインオブジェクトをつなぎ合わせますが、これがマイクロサービスの方法でどのように機能するかについて頭を包むのに苦労しています。
5
マイクロサービスとストアドプロシージャ
ストアドプロシージャは、マイクロサービスアーキテクチャで悪い習慣と見なされますか？ 私の考えは次のとおりです。 マイクロサービスに関するほとんどの書籍では、マイクロサービスごとに1つのデータベースを推奨しています。通常、ストアドプロシージャはモノリシックデータベースで機能します。 繰り返しますが、ほとんどのマイクロサービスアーキテクチャの本は、自律的で疎結合である必要があると述べています。特にOracleで作成されたストアドプロシージャを使用すると、マイクロサービスとそのテクノロジが緊密に結合されます。 私が読んだほとんどのマイクロサービスアーキテクチャの本は、マイクロサービスをビジネス指向（ドメイン駆動設計（DDD）を使用して設計）にすることを推奨しています。データベースのストアドプロシージャにビジネスロジックを移動することにより、これはもはや事実ではありません。 これについて何か考えはありますか？
3
マイクロサービス間でDTOを共有する方法は？
私のシナリオは次のとおりです。 さまざまな種類のセンサーからデータを受信し、後でさまざまなフロントエンドおよび分析サービスで使用できるように変換して保持するように設計されたシステムを設計しています。 私はすべてのサービスを可能な限り独立したものにしようとしていますが、問題があります。チームは、使用したいDTOを決定しました。外向きサービス（センサーデータ受信者）は、独自の方法でデータを受信し、JSONオブジェクト（DTO）に変換して、メッセージブローカーに送信します。メッセージのコンシューマーは、センサーデータメッセージの読み取り方法を正確に知ることができます。 問題は、いくつかの異なるサービスで同じDTOを使用していることです。更新プログラムは複数の場所に実装する必要があります。明らかに、ここでDTOのいくつかの余分なフィールドや不足しているフィールドを設計しました。サービスが更新されるまで問題はあまりありませんが、それでも私を悩ませ、気分が良くなります。間違いを犯す。簡単に頭痛になります。 システムを間違って設計しようとしていますか？そうでない場合、これを回避する方法は何ですか、または少なくとも私の心配を緩和するために？
1
自分でシステムを開発する場合、マイクロサービスを使用する必要がありますか？
私は仕事で新しいプロジェクトを始めており、おそらくプロジェクトのほぼ唯一の開発者になりますが、他の1人または2人の開発者は、既存のアプリケーションまたは単純なスクリプトをメインプロジェクトに統合する必要があります。このプロジェクトでは、小規模のバルクデータとストリーミングデータの取り込み/処理、およびイベント駆動型とオンデマンドの両方のコード実行を処理する必要があります。フレームワークの一部はCPUに強く依存し、一部はI / Oに強く依存します。ほとんどのデータは単一のマシン上に存在する必要がありますが、クラスターを作成してVMを接続し、利用可能な計算能力を向上させることができます。おそらく、このコアフレームワークが提供するサービスに依存する1つ以上の小さなWebアプリケーションがあるでしょう。主な言語は、ほぼすべてのPythonです。 私の質問は、開発の大部分を自分で行うことを考えると、このような取り組みにマイクロサービスアプローチを採用すべきか、モノリシックアプリケーションに固執すべきかということです。私の考えでは、マイクロサービス（Namekoを使用）は、異なる実行モデル（データパイプライン、イベント起動、オンデマンド、Webアプリケーションなど）を持つフレームワークの要素を自然に分離し、ワークロードと複数のプロセスにわたる通信。私の懸念は、おそらくシステムの実行を容易にするために必要な複数のサービス（rabbitmq、redisなど）を管理するKubernetesクラスター（私はDockerに精通していますが、Kubernetesにはまだかなり新しい）になることです。そして、潜在的に私たちが必要なすべての機能を実際に実装するための多くの小さなコードの塊 開発者が1人しかいないプロジェクトの場合、マイクロサービスはこのような複雑なシステムの開発と保守を引き続き簡素化しますか？代わりに使用することを検討する必要があるメソッド/システム/フレームワークはありますか、またはこの方法でシステムを設計する際のオーバーヘッドを削減するためにありますか？
4
マイクロサービスは相互に通信する必要がありますか？
Micro-Servicesを使用してアプリケーションを設計していますが、複数のサービスからデータを収集するために使用する最適なメカニズムがわかりません。 私は2つのオプションがあると信じています： サービスが直接対話できるようにする「サービス間」通信メカニズムを統合します。API Gatewayは、統合された応答をAPI Gatewayに返す前に、個々のサービスを呼び出してから、他のサービスを呼び出してデータを収集します。その後、APIは呼び出し元に応答を返します。（これは、serviceBへの呼び出しがserviceAからの応答を必要とする場合、同期呼び出しである必要があります。IEは、個人とアドレスサービスを分離します。） API Gatewayで各サービスを直接呼び出し、応答を返す前にAPI内のデータを統合します。 サービスが相互に通信するとカップリングが導入されるため、2番目のオプションに傾いています。この場合、モノリシックアプリケーションを設計することもできます。ただし、このオプションを使用すると頭から離れて考えることができる重大な欠点がいくつかあります。 APIに複数のサービスへの複数の呼び出しを実行させると、特にそれらの呼び出しの一部がブロックしている場合に、APIサーバーの負荷が増加します。 このメソッドは、APIがアプリケーションが実行しようとしていることを「認識」する必要があることを意味します（IEロジックをAPIにプログラミングして、サービスの呼び出しを処理し、データを統合する必要があります）。マイクロサービスの愚かな「エンドポイント」として機能します。 この問題に対する標準的なアプローチが何であるか、そして私が見逃している別の3番目のオプションがあるかどうかを知りたいですか？
4
マイクロサービスとデータストレージ
モノリシックREST APIをマイクロサービスアーキテクチャに移行することを検討していますが、データストレージについて少し混乱しています。私が見るように、マイクロサービスの利点のいくつかは次のとおりです。 水平方向にスケーラブル-負荷やサーバーのダウンに対処するために、マイクロサービスの複数の冗長コピーを実行できます。 疎結合-他のマイクロサービスを変更することなく、マイクロサービスの内部実装を変更できます。また、独立して展開および変更することもできます。 私の問題はデータストレージです。ご覧のとおり、いくつかのオプションがあります。 すべてのマイクロサービスで共有される単一のデータベースサービス-これは、疎結合の利点を完全に排除するようです。 各マイクロサービスにローカルにインストールされたデータベースインスタンス-これを水平方向にスケーリングする方法が見当たらないため、オプションとは思わない。 各マイクロサービスには独自のデータベースサービスがあります-疎結合と水平スケーリングの利点を保持するため、これは最も有望であると思われます（冗長データベースコピーの使用および/または複数でのシャーディング） 私には、3番目のオプションが唯一のオプションのように思えますが、私には信じられないほど重く、非常に過剰に設計されたソリューションです。私がそれを正しく理解している場合、4-5マイクロサービスを備えたシンプルなアプリケーションでは、16-20サーバーを実行する必要があります-マイクロサービスごとに2つの実際のマイクロサービスインスタンス（サーバー障害の場合、およびダウンタイムなしでデプロイするため）、およびマイクロサービスごとに2つのデータベースサービスインスタンス（サーバー障害などの場合）。 これは、率直に言って、少しばかげているようです。16〜20台のサーバーでシンプルなAPIを実行しますが、現実的なプロジェクトにはおそらく4〜5以上のサービスがあることに留意してください。これを説明する基本的な概念がありませんか？ 回答中に役立ついくつかのこと： 私はこのプロジェクトの唯一の開発者であり、近い将来になります。 Node.jsとMongoDBを使用していますが、言語に依存しない回答に興味があります。答えは、間違ったテクノロジを使用しているだけかもしれません。
3
分散データ管理-データベースをマイクロサービスにカプセル化する[終了]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 私は最近ソフトウェア設計のコースを受講しており、サービスのコンポーネントが可能な限り独立したマイクロサービスサブコンポーネントに分離される「マイクロサービス」モデルの使用について、最近の議論/推奨がありました。 言及された部分の1つは、すべてのマイクロサービスが通信する単一のデータベースを持つという非常によく見られるモデルに従うのではなく、マイクロサービスごとに個別のデータベースを実行することでした。 これについてのより適切な言葉で詳細な説明は、http：//martinfowler.com/articles/microservices.htmlの分散型データ管理セクションにあります 。 これを言っている最も顕著な部分： マイクロサービスは、各サービスが独自のデータベース、同じデータベーステクノロジーの異なるインスタンス、または完全に異なるデータベースシステムを管理できるようにすることを好みます-Polyglot Persistenceと呼ばれるアプローチ。モノリスでポリグロット永続化を使用できますが、マイクロサービスではより頻繁に表示されます。 図4 私はこの概念が好きで、他の多くのことの中でも、保守と複数の人が取り組んでいるプロジェクトの強力な改善と考えています。とはいえ、私は決して経験のあるソフトウェアアーキテクトではありません。誰もそれを実装しようとしましたか？どのようなメリットとハードルに遭遇しましたか？
4
Microservice Architectureでの大容量ファイル/データ転送
私の会社は現在、マイクロサービスアーキテクチャの採用に取り組んでいますが、その過程で成長中の痛み（衝撃！）に直面しています。私たちが直面している主要な競合ポイントの1つは、異なるサービス間で大量のデータを通信する方法です。 ちょっとした背景として、社内全体で処理する必要があるドキュメントのリポジトリとして機能するドキュメントストアがあります。このストアとのやり取りは、クライアントに一意のIDとドキュメントをストリーミングする場所を提供するサービスを介して行われます。ドキュメントの場所は、指定されたIDを使用したルックアップを介して後でアクセスできます。 問題はこれです-すべてのマイクロサービスが、ドキュメントとやり取りする目的のために、APIの一部としてこの一意のIDを受け入れることは理にかなっていますか？私にとってこれは本質的に間違っているように感じます-サービスはもはや独立しておらず、ドキュメントストアのサービスに依存しています。これによりAPIの設計が簡素化される可能性がありますが、おそらく、パフォーマンスを改善するだけでなく、結果として得られるカップリングの利点が相殺される可能性もあります。 レインボーユニコーン（Netflix、Amazon、Googleなど）がサービス間の大きなファイル/データ交換を処理する方法を知っている人はいますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.