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

特定のドメインのデータをマイクロサービスとレガシーデータベースの間で分散しています。レガシーデータベースとマイクロサービスデータベースの両方のフィールドにまたがる検索があります。以前（マイクロサービスの分割前）、1つのSQLクエリで実行されていました。この検索機能を提供するには、REST呼び出しとレガシーデータベースへのクエリが必要です。ここでは数百万行について話しています。これをどのように最適にモデル化できますか？データ量が多いため、REST呼び出しは通常、ページ分割された結果も返します。SQL呼び出しを起動し、結果をREST応答と結合およびマージする単純なアプローチは遅すぎて、実際的ではありません。

12 microservices  search 

マイクロサービスアーキテクチャを使用するSpring Bootアプリケーションがあると仮定しましょう。各サービスには独自のドメインモデルがありますが、各サービスはユーザードメインオブジェクトを参照する必要があります。この問題を解決する最善の方法は何でしょうか？各サービスが単にuserIdを持ち、必要に応じてユーザーの詳細をユーザーサービスに問い合わせる方が良いでしょうか、それともすべてのマイクロサービス用の共有ドメインライブラリを持つ方が良いでしょうか？

12 spring  microservices 

他のサービスが安定している間、ダウンまたはダウンするサービスを支援するために使用できる設計パターンまたはプラクティスはありますか？ 3つのマイクロサービスがあり、そのうち2つが正常で、1つがPOSTの途中で停止した場合はどうなりますか？2つはPOSTを受け取り、1つは受け取りません。リクエストをサービスに発送しているため、取引ができないと思います。 そのためにどのように設計しますか？さまざまなデータベースに孤立したデータは必要ありません。

12 database  concurrency  microservices  data-integrity 

現在の状況 私たちは、マイクロサービスアーキテクチャでオンラインショッピングWebアプリケーションを実装しています（そして現在保守しています）。 要件の1つは、エクスペリエンスと最終的な注文をカスタマイズするために、顧客がカートに追加するものにルールを適用できる必要があることです。明らかに、ビジネスルールエンジンを導入する必要があり、このために特定の「マイクロサービス」を実装しました（まだそう呼べる場合）。 1年の間に、このルールエンジンはますます複雑になり、より多くのデータ（カートのコンテンツだけでなく、ユーザー情報、役割、既存のサービス、請求情報など）が必要になりました。それらのルールを計算します。 現時点では、shopping-cartマイクロサービスは他のマイクロサービスからこのデータをすべて収集しています。このデータの一部はで使用されますがshopping-cart、ほとんどの場合、主にルールエンジンのフィードに使用されます。 新しい要件 これで、同様の要件にルールエンジンを再利用する他のアプリケーション/マイクロサービスが必要になりました。したがって、現在の状況では、ルールエンジンを呼び出すことができるように、同じ種類のデータを送信し、同じマイクロサービスを呼び出し、（ほぼ）同じリソースを構築する必要があります。 そのまま続行すると、いくつかの問題に直面します。 誰もが（ルールエンジンを呼び出して）データのフェッチを再実装する必要があります（自分でデータを必要としない場合でも）。 ルールエンジンへの要求は複雑です。 この方向で続けると、多くの要求のためにこのデータをネットワーク全体に転送する必要があります（μsAがルールエンジンを呼び出すμsBを考えますが、Aはルールエンジンが必要とするデータの一部を既に持っています）。 shopping-cart すべてのデータ取得により巨大になりました。 おそらく多くのことを忘れてしまいます… これらのトラブルを回避するために何ができますか？ 理想的には、ルールエンジンの複雑さを増やさないようにします。また、ボトルネックにならないように確認する必要があります。たとえば、一部のデータはフェッチに時間がかかります（10秒以上）ためshopping-cart、ルールを呼び出す前にデータが存在する可能性が高くなるようにプリフェッチを実装しましたエンジン、および許容できるユーザーエクスペリエンスを維持します。 いくつかのアイデア ルールエンジンに必要なデータをフェッチさせます。これにより、さらに複雑さが増し、単一の責任原則に違反します（さらに…）。 ルールエンジンがデータを取得する前にプロキシμsを実装します。 ルールエンジンが必要なすべてのデータを一度にフェッチするために呼び出す「データフェッチャー」μsを実装します（複合照会）。

12 design  architecture  enterprise-architecture  microservices  business-rules 

HTTPサーバーとそのクライアントの間でインターフェースを共有する方法を見つけたとき、Spring Cloud Netflixのドキュメントを読んでいました。彼らはこの例をマイクロサービスに使用していますが、一般的なHTTP通信に拡張できない理由はありません： // The shared interface, in a common library public interface UserService { @RequestMapping(method = GET, value = "/users/{id}") User getUser(@PathVariable long id); } // The controller, on the server @RestController public class UserResource implements UserService { } // The same interface used for the client @FeignClient("users") public …

12 spring  microservices 

マイクロサービスが独自の承認を処理する必要がありますか、それともマイクロサービスのすべてまたはサブセット（同じビジネスドメイン内）で共有される個別の承認サービスを使用する方が良いと思いますか？ 私にとって後者は、変更の適用、ポリシーの実施を容易にするため、より理にかなっています。DRYなどです。ただし、あらゆる種類のサービスがルールを1か所にダンプすることで簡単に手に負えなくなる可能性があり、ネットワークのオーバーヘッドも心配します。 何かご意見は？

12 architecture  authorization  microservices 

私はモノリシックなアプローチに慣れているので、マイクロサービスアーキテクチャに頭を抱えようとしています。 非常に簡素化された Uber予約システムを構築しようとしているとします。：物事を単純化するために、我々は、我々は3つのサービスとクライアントのゲートウェイAPIを持っているとしましょうBooking、Drivers、Notificationと私たちは、次のワークフローを持っています： 新しい予約を作成する場合： 既存のユーザーがすでに予約しているかどうかを確認する 利用可能なドライバーのリストを取得する ドライバーに通知を送信して予約を受け取ります 運転手が予約をピックアップ すべてのメッセージングがkafkaのようなメッセージングバスではなくhttp呼び出しを介して行われるとしましょう。 したがって、この場合、Bookingサービスは既存の予約の確認を行うことができると思いました。しかし、利用可能なドライバーと通知のリストを誰が取得する必要がありますか？ゲートウェイレベルで実行することを考えていますが、ロジックは次の2つの場所に分割されています。 Gateway -利用可能なドライバーのリストを取得+通知を送信 Booking -既存の予約を確認する そして、ゲートウェイはそれを行うのに適切な場所ではないと確信していますが、Bookingサービスでそれを行っている場合、緊密に結合されているように感じますか？ さらに複雑にするために、予約システムを再利用したいが、独自のビジネスロジックを追加した別のプロジェクトがある場合はどうなるでしょうか。新しいプロジェクトゲートウェイが独自のビジネスロジックを既存のものから分離できるように、ゲートウェイレベルでそれを行うことを考えたのはそのためです。 それを行う別の方法は、各プロジェクトがコア予約サービスと通信する独自​​の予約サービスを持っていることですが、ここでの最善のアプローチは何なのかわかりません:-)

11 architecture  microservices  business-logic 

APIゲートウェイ経由でのみ外部からアクセスできるマイクロサービスがたくさんあります。 API GatewayはOAuthリソースとして設定され、1つ以上のマイクロサービスにダウンストリームのリクエストを渡す前にトークンを検証します（署名の確認など）。 私のマイクロサービスはスコープとクレームを検証するためにトークンを必要としますが、このサービスがトークンを検証する必要もあるでしょうか？ 少しやりすぎのようですが、このシナリオについてオンラインでアドバイスを見つけることはできません。 APIゲートウェイでのトークンの検証は十分ですか？または、後でもう一度検証するのがベストプラクティスですか？

10 microservices 

私はマイクロサービスについて読みましたが、分離を実現するためだけにサービスごとに個別のDBを作成するのは私には非論理的です。Webサービスと単一のデータベースのみを使用して同じことを実現できます。なぜそれが必要なのですか？データベースを分離することは議論の余地があります。または私は明らかに間違っていますか？これについて教えてくれませんか？

10 architecture  database  web-services  microservices  services 

私たちはプロジェクトのマイクロサービスアーキテクチャを構築しており、主にフロントエンドのSymfonyアプリケーションがバックエンドのRESTful APIと対話しています。 問題は、このアプローチがデータベースを持つDoctrineに大きく依存しているSymfonyエンティティ管理を壊していることです。Symfonyは通常、Doctrineでエンティティを処理し、ほとんどの作業を自動化しますが、APIから外部データにアクセスする必要がある場合、これは簡単に再現できません。 たとえば、クライアントエンティティの場合： Doctrineを使用すると、Clientクラスを定義するだけで、クライアントを簡単に作成、更新、取得できます REST APIアプローチを使用すると、APIを介してクライアントにアクセスできますが、クライアントの作成（POST）、更新（PUT）、取得（GET）などを定義するために多くの作業が必要です。 クライアントは、フロントエンドアプリだけでなく、専用のAPIだけでなく、いくつかのアプリケーションでも使用されています。 API呼び出しの複雑さを隠すエンティティのようなメソッドを使用してクラスを作成し、すべてのAPIデータをローカルにインポートして、Doctrineを通じて、または他の方法でそれらにアクセスする必要がありますか？

10 php  rest  api  microservices  symfony 

Webアプリケーションを形成するWebサービスがいくつかあります。クライアントはREST API呼び出しを通じてこれらのサービスにアクセスできます。 これらのサービスは互いに直接通信できる必要がありますか？もしそうなら、それらはマイクロサービスの概念に反するカップルになるでしょうか？ クライアントは、クライアントにWebページをロードするために必要なデータを取得するために、次々にそれらを直接呼び出す必要がありますか？ または、クライアントからの要求を処理し、その要求のデータをフェッチしてからクライアントに送り返す、サービスの上に別のレイヤーを配置する必要がありますか？

10 architecture  rest  microservices 

免責事項 私は誰かのつま先を踏んだり、どちらかのコンセプトの愛好家を怒らせたりしていないことを願っています バックグラウンド 私は明確な答えを見つけることなく、サービス指向アーキテクチャとマイクロサービスの真の違いを探していました。 私は次のようなものを読みます： SOAの副作用 SOAはアンチパターン マイクロサービスはSOAの障害を修正するようになりました ESBは実際にはESBではなく、EAIです。 メッセージブローカーへの過度の依存 ベンダーはSOAの概念を悪用し、自社製品の販売を試みています SOAが制御不能に成長する しかし、それでもなお、サービス指向アーキテクチャー（概念として）とマイクロサービス（概念として）の間のアーキテクチャーの違いを明確に定義するものはありません 私が理解したところによると、彼らはどちらも持っています： 1つのことだけを行うサービスプロバイダー これらのサービスをコンシューマーに公開するService Gateway / ESB ESB / Service Gatewayを介してサービスにアクセスするサービスコンシューマー 質問 では、SOAをマイクロサービスに再ラベル付けする以外に何か違いはありますか？マイクロサービスがマクロになることを制限するために配置されたテクノロジーの制約ですか？ 注：箇条書きで意見を探すのではなく、難しい事実を探しています。 参考文献 ソフトウェア工学の質問 マーティン・ファウラーのサイト（彼はそれが大いに嫌いだと思う） 情報の世界 マイケル・フェザースのウェブサイト スタックオーバーフローの質問 更新 スタックオーバーフローの質問でも同様の議論が起こったようです。意見が分かれるかどうかにかかわらず、マイクロサービスは変装したサービス指向アーキテクチャーです。 SOの質問からの結論： MSはSOAの特殊なケースです MSは、サービスをホスティングするアプリケーションのより小さなサイズを推奨します MSはテクノロジーに依存します（オープンプロトコルオプションではなくHTTPの使用） MSはテクノロジーを利用して規律を強化します（サービスの自動展開） MSはESB（悪）を考慮しますが、IMHOがESBの一種である APIゲートウェイを使用します 次の条件に当てはまる場合、MSはSOAであると結論付けます。 MSはオーケストレーションの概念をサポートしていますか？ワークフローを管理する1つ以上のマスタープロセス MSにメッセージブローカーレイヤーはありますか？メッセージフォーマットをサービスプロデューサーのメッセージスペースからサービスコンシューマーに変換する一連のアダプター マイクロサービスはモノリシックエンタープライズアプリケーションからデータを読み取ることができますか？モノリシックアプリケーションのAPIにすることはできますか？それとも独立して動作できるスタンドアロンの自己完結型アプリケーションでなければなりませんか？ 最後の質問に対する答えが「いいえ」であることが判明した場合、マイクロサービスは、クレジットカード管理システムや照合システムなどの複雑なワークフローシステムを処理することができません。

10 microservices  enterprise-architecture  soa 

私はすべての長所と短所、いつ、なぜなどの高レベルの概要を取得しようとするマイクロサービスアーキテクチャを研究してきました。私が読んで/見ている情報の多くは、ThoughtWorks（Martin Fowler、Neal Fordなどからのものです） al）。 この問題に関するMartin Fowlerの仕事の大部分は数年前のものであり、Microservices（プログラミングの一般的な名称ではないが）がまだ若かったため、私はその多くを少しずつ理解しました。 特に、これは次のとおりです。 マイクロサービスアーキテクチャを使用するチームの話を聞いていると、共通のパターンに気づきました。 成功したマイクロサービスストーリーのほとんどすべては、大きくなりすぎて分割されたモノリスから始まりました。 最初からマイクロサービスシステムとして構築されたシステムについて聞いたほとんどすべての場合、それは深刻な問題に終わっています。 このパターンにより、多くの同僚は、アプリケーションが価値があるほど十分に大きいアプリケーションであっても、マイクロサービスで新しいプロジェクトを開始すべきではないと主張しました。。 （参照：https : //martinfowler.com/bliki/MonolithFirst.html-彼らを強調） さて、3年後、マイクロサービスがよりユビキタスな言葉になりましたが、新しいシステムは通常、最初により大きい（-microservice-but-smaller-than-monolith）サービスチャンクを用意し、それらは進化的測定の一部としてより細かく？ または、上記のステートメントとは対照的に、きめ細かなマイクロサービスアーキテクチャを使用してプロジェクトをゼロから開始する基準はありますか？ 正気な一般的なアプローチのようですが、コミュニティの考えに興味があります。

9 architecture  microservices 

最新のプログラムで人気のある高レベルのアーキテクチャの選択は、RESTベースのマイクロサービスシステムです。これには、疎結合、再利用の容易さ、使用できるテクノロジーの制限の制限、高いスケーラビリティなどのいくつかの利点があります。 しかし、そのようなアーキテクチャーで私が予測する問題の1つは、アプリケーションの依存関係が何であるかについての可視性が低いことです。たとえば、1組のREST呼び出しを毎日使用するアプリケーションがあるとします。このアプリケーションは、REST呼び出しの2番目のセットも使用しますが、四半期に1回だけです。過去1週間のログをスキャンすると、1日のカロリーはすべて表示されますが、四半期ごとの呼び出しは表示されません。リファクタリングの時期になると、四半期ごとの呼び出しが中断するリスクが高くなります。 このリスクを軽減し、疎結合アーキテクチャの依存関係をより詳細に可視化するために使用できるパターンまたはツールは何ですか？

9 architecture  rest  enterprise-architecture  microservices  coupling 

このサイトでマイクロサービスについて読んでいたときに、以下のステートメントに出くわしました。正規スキーマとはどういう意味ですか？ドメインモデルと同じではありませんか？ マイクロサービスアーキテクチャパターンは、正規スキーマの概念など、SOAの他の部分も拒否します。

9 web-services  soa  microservices  nginx