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

イベント駆動型マイクロサービスアーキテクチャの変更を処理するためのオプションを調査している調査プロジェクトを行っています。 したがって、4つの異なるサービスを利用できるアプリケーションがあるとします。これらの各サービスには、ローカルデータを格納するための独自のデータベースがあります。 このセットアップでは、4つのサービスがイベントバスを使用して相互に通信します。したがって、サービスで何かが発生すると、イベントが発行されます。そのイベントに関心のある他のすべてのサービスは、独自の方法で処理します。 その場合、アーキテクチャー内のさまざまなサービスは、これらのイベントの内容（属性など）について「契約」を持つ必要があります。したがって、サービスはこれらのイベントに「疎結合の依存関係」を持っています 私の質問は次のとおり です。これらのイベントの変更をどのように処理できますか？ それでは、サービスAがアプリケーションに新しいユーザーを登録するとします。したがって、 "" UserRegistered "イベントを送信します。サービスBがそのイベントを取得して処理します。ただし、サービスチームCの一部の開発者は、登録済みユーザーの性別も必要であると判断しました。そのため、イベントが変更され、属性gender 「UserRegistered」イベントに追加されます。 サービスBが再デプロイせずに、その追加属性を使用して同じイベントを引き続きピックアップできることをどのように確認できますか？ そして、この問題に取り組み、これらのイベントをバージョン管理する他の方法はありますか？

9 communication  versioning  microservices  message-queue  code-contracts 

独立したマイクロサービス（RabbitMqバスで接続）に基づくシステムを設計しています。コードは（少なくとも最初のコンポーネントでは）python（python2とpython3の両方）で記述されます。マイクロサービスとしてリファクタリングして拡張したいビジネスロジックの一部を実装したモノリスアプリケーションがすでにあります。私が心配する1つの質問は次のとおりです。 異なるマイクロサービス間でコードを共有する最良の方法は何ですか。いくつかのマイクロサービスで使用する必要がある共通のヘルパー関数（データ処理、ロギング、構成解析など）があります。 マイクロサービス自体は、個別のプロジェクト（gitリポジトリ）として開発されます。共通ライブラリは、自己完結型プロジェクトとしても開発できます。これらのライブラリをマイクロサービス間で共有するにはどうすればよいですか？ 私はいくつかのアプローチを見ます： 各マイクロサービスに必要なライブラリのバージョンをコピーし、必要に応じて更新します 共通ライブラリを内部PyPiにリリースし、それらのライブラリをマイクロサービスの要件の依存関係としてリストします ライブラリリポジトリをgitサブモジュールとして含める 先に進む方法を決定する前に、提案されたアプローチ、ベストプラクティス、過去の経験についてもう少しお読みしたいと思います。提案やリンクはありますか？

9 python  microservices 

私はマイクロサービスに不慣れです。私の理解から、DDDはビジネスドメインを中心にマイクロサービスを構築するように言っています。つまり、会議予約システムのコンテキストでは、優れたマイクロサービスはAppointmentSchedulerやSendNotificationのようなものです。 この例では、これらの両方のマイクロサービスがビジネス機能を果たすためにユーザーデータにアクセスする必要があり、それを提供するための最良の方法に苦労しています。 私には、ユーザーはマイクロサービス内のエンティティとして存在する必要があるオブジェクトのように見えますが、ほとんどすべてのマイクロサービスに存在する必要があります。これにより、多くの重複が発生します。 もう1つのオプションは、ユーザーデータベースでCRUD操作を提供するユーザーマイクロサービスを用意することです。これは、他のマイクロサービスがユーザーデータにアクセスするために使用できますが、私が抱えている問題は、分散モノリスになるまでサービスを密結合することです。これは、モノリス自体よりもわずかに優れています。 私の推論は有効に見えますか？他の人はどのように問題に対処していますか？

9 microservices 

マイクロサービスアーキテクチャに基づいてアプリケーションを設計しています。 このアプリケーションでは、Authマイクロサービスが必要です。 また、おそらく複数のアドレス、アバター画像などの追加のユーザー情報を保存する必要があります これにより、2つのマイクロサービス（1つは認証用、もう1つはユーザー用）を持つというアイデアにつながります。 これまでのところ、私は次のアイデアを持っています： 認証サービスが、追加のアドレス（おそらくアバターなど）を含むユーザー情報を保持するリソースサーバーになることも許可します。これは、ユーザーに関連するすべてを1か所にまとめて、新規登録などの操作の複雑さを軽減できるので、便利なソリューションです。ユーザー、ユーザーの削除。ただし、このソリューションはマイクロサービスの概念と矛盾しているようですが、私にとっては、このソリューションが最も魅力的です 2つの異なるマイクロサービス-認証とユーザー。Authはトークンの処理のみを担当し、ユーザーに関連するデータは保存しません。トークンのリクエストが受信されると、Authサービスはユーザーを呼び出してユーザーデータを受信し、決定を行います 2つの異なるマイクロサービス-認証とユーザー。Authはトークンの処理を担当し、認証に関連するユーザー情報の一部（おそらくパスワード、ロール）も格納します。ユーザーサービスは、追加のアドレス、アバターなど、他のすべての情報を保持します。この方法は、複雑なユーザーの削除/新しいユーザーの作成操作を必要とするため、複雑すぎるようです さて、これらの解決策の1つを選択する必要がありますが、迷っていて、どれが正しい解決策なのかわかりません。 これに関するアドバイスをいただければ幸いです。 ありがとう

9 design  architecture  microservices  authentication 

私が作成したいMicroservicesすべてのmicroserviceは、フロントエンドの独自の一部を担当しているアプリケーションを、。同時に、AngularJSでフロントエンドをシングルページアプリケーション（SPA）として作成したいと考えています。新しいマイクロサービスがデプロイされると、Webフロントエンドは自動的に新しいフロントエンド部分を取得してSPAに追加します。これを実現する最良の方法は何でしょうか？ これが私が思いついたものです。各マイクロサービスは、独自のAngularモジュールを担当できます。次に、顧客がアプリケーションに移動すると、サーバーコンポーネント（ASP.NETまたはJSP）は、どのマイクロサービスがオンラインであるかを確認し、それらのマイクロサービスからの角度モジュールを含むHTMLページを作成できます。 フロントエンドコンポーネントが実行できることは、管理者やVIPの顧客など、拡張された特権を持つ特定の顧客に対していくつかのマイクロサービスを有効にすることです。 もちろん、これが機能するためには、各マイクロサービスが画面上に他のマイクロサービスが何であるかを「知る」ことなく、画面の一部を占めるための優れた構造化された方法が必要です。簡単な解決策は、マイクロサービスごとにタブを作成することです。タブでは、担当のマイクロサービスがその機能をページに配置できます。フロントエンドコンポーネントは、（角度）ルーティングやルックアンドフィールなどの一般的な要素を担当します。 これはこの目標を実現する最良の方法ですか？誰もがこれで経験がありますか？

9 angularjs  front-end  microservices 

私は最近、Always Validドメインエンティティについて多くの読書をしました。エンティティが常に有効であることを保証するために、私は次のことを行う必要があると信じるようになりました。 1）ここで説明されているように、プリミティブな強迫観念を取り除き、値オブジェクトコンストラクターに検証/ドメインルールを配置します：https : //enterprisecraftsmanship.com/2016/09/13/validation-and-ddd/。2）ここで説明されているように、検証またはドメインルールをエンティティまたはプロパティセッターのコンストラクタに配置します：http ://gorodinski.com/blog/2012/05/19/validation-in-domain-driven-design-ddd/ 。 ただし、次に、https：//github.com/gregoryyoung/mrなどのいくつかのオープンソースプロジェクトを調べます。私が理解していることから、このプロジェクトの作成者は常に有効なドメインモデルの擁護者ですが、それでもInventoryItemクラス（https://github.com/gregoryyoung/mr/blob/master/SimpleCQRS/Domain.cs）を調べます。私はこれを行うことができることに気づきました： InventoryItem inventoryItem = new InventoryItem(); またはこれ： InventoryItem inventoryItem2 = new InventoryItem(Guid.Empty,null); 私の考えでは、これはエンティティが無効な状態で初期化されることを意味します。これは、私が最近見た他のすべてのオープンソースプロジェクトにも当てはまるようです。たとえば、次のプロジェクトです。https：//github.com/dcomartin/DDD-CQRS-ES-Example/blob/master/src/Domain /Customer.cs。 これらのオープンソースプロジェクト（https://martinfowler.com/bliki/ContextualValidation.html）にコンテキスト検証があることに気づきました。また、ドメインモデルにマップする場合、ORMにはデフォルトの空のコンストラクターが必要であることも理解しています。 ドメインオブジェクトは、引数なしのコンストラクタを使用してデフォルト値で初期化されている/空/ null値で初期化されている場合、有効な状態ですか？

8 c#  domain-driven-design  microservices  cqrs 

マイクロサービスを使用する上での最大の問題点の1つは、APIが十分に文書化され、APIがダウンストリームアプリケーションに影響を与えずに動作を変更しないことを確認することです。この問題は、相互に依存し合うサービスが多数ある場合に増幅されます。多分その時点であなたは間違ったマイクロサービスをやっていますが、私は余談です。 異なるチームが所有する20のマイクロサービスを継承していて、どのアプリケーションが他のどのアプリケーションのAPIエンドポイントを使用するかについての明確なドキュメントがないとします。これを文書化する規定された方法はありますか？最初に、各アプリケーションのエンドポイントを分析してデータベーステーブルに追加し、多対多テーブル（ほとんどすべてがRailsアプリケーションです）で各アプリケーションとアプリケーションのルート間にFK関係を作成することを考えました。しかし、これがこれを処理するための良い方法であるかどうか、または私はここで車輪を再発明しているかどうかわかりません。 振り返ってみると、マイクロサービスをゼロから始めている場合、これはアプリケーションの相互作用を文書化するのにそれほど悪くない方法かもしれません。これにより、データベースを使用して単一の信頼できる情報源が維持され、エンドポイントへの変更は、データベースの変更と連動してアプリケーションで実行されます。考え？

8 api-design  documentation  microservices 

当社は、数千のサービスを含むマイクロサービスアーキテクチャでアプリケーションを実行しています。50以上のサービスと通信するバックエンドアプリケーション「X」に取り組んでいます。フロントエンドサービスは他のサービスでリクエストを実行するためにサービス「X」を呼び出します。 問題点： フロントエンドは、他のサービスで何かが失敗したときに、ユーザーフレンドリーなメッセージを表示したいと考えています。 他のサービスはユーザーフレンドリーなメッセージを返しません。いくつかあるため、他のチームに変更を依頼することはできません。 そのような合意されたエラーコードはありません。他のサービスは文字列エラーメッセージを返します。現在、UIに渡されます。時々、エラーメッセージはポインタ参照です（悪いコード：/） 可能な解決策： エラーメッセージ文字列を確認し、サービスにユーザーフレンドリーなメッセージへのマッピングを含めます。ただし、呼び出し先のサービスがエラーメッセージを変更した場合は、問題が発生する可能性があります。カスタムエラーマッピングが見つからない場合のデフォルトのエラーメッセージへのフォールバック。 スケーラブルで持続可能なソリューションに関する他のアイデアはありますか？ありがとう！

8 api  microservices  error-handling 

私たちは最近、モノリシックWebアプリをマイクロサービスに分割し始め、ゆっくりと機能をスライスして個別のマイクロサービスに書き直しました。フロントエンドの作業を整理する最善の方法がわからない場合を除いて、すべて順調に進んでいます。私たちは製品チームに分かれて、少数のマイクロサービスのコードをそれぞれ管理し、検索、CMS、チェックアウトなどの機能領域を提供します。各チームには製品所有者、技術リーダー、スクラムマスターがいます。 問題は、これらの製品チームがそれぞれ独自のバックエンドコードベースを持っている一方で、フロントエンド開発者が各製品チームに座っている単一のフロントエンドReact.jsコードベースがあることです。これは多くの問題を引き起こしています： フロントエンド開発者間の製品チーム間のコミュニケーションの欠如 他のチームの新機能をサポートするために他のチームが「所有」しているフロントエンドコードに変更を加える際の問題 フロントエンドチームを代表する単一の技術エキスパートは存在しませんが、他の製品チームには技術的なリードがあり、フロントエンドでこの役割を果たしている人はいません。 私たちは他の人がこれをどのように扱っているのか疑問に思い、フロントエンドコードベースの分割、ビジネスユーザーが新機能のために通常従事するフロントエンド製品チームの作成、データ/サービスのリクエストなど、フロントエンドチームの他の製品チームですが、どちらにも独自の問題があります。

8 agile  microservices  organization 

アプリでは、ある種のマイクロサービスアプローチを使用しています（ただし、実際にはそれに準拠していません）。 サービスがダウンしているか例外がスローされている場合、アプローチはそれをキュー（ActiveMQ）に入れ、サービスが再びアップしたときに再試行します。 これは「標準」ソリューションですか？それとも、何らかの理由で回避する必要がありますか？ または、この問題に対するより良い、または代替の解決策はありますか？

8 microservices  message-queue 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 3年前休業。 モノリシックモンスターをマイクロサービスベースのアーキテクチャに徐々に分解することを検討しています。私たちには5つのチームがあり、各チームには2〜3人のC＃開発者、少なくとも1人のデータベース開発者、および2人のQAエンジニアが含まれています。モノリシックアーキテクチャからマイクロサービスへの大きな文化とパラダイムシフトに加えて、技術的な課題もあります。同じ間違いをしないように、コミュニティに知恵とアドバイスをお願いしたいと思います。 .NETベースのマイクロサービスが実稼働システムでうまく利用されている良い業界の例はありますか？次の戦略は何でしたか？ 組織：.NETソリューション/プロジェクトをどのように編成しましたか？ 開発計画：開発計画に関して、チーム間でどのように作業を分割しましたか？マイクロサービス全体で契約のコンプライアンスを確保するための全体的な戦略は、チーム間で交渉されましたか？ 負荷分散/ルーティング/ APIゲートウェイ：負荷分散、冗長性、スケーリングの戦略は何でしたか？完全な非同期アーキテクチャを使用して、マイクロサービス通信にキューを使用しましたか、それともロードバランサー/ APIゲートウェイを介してピアツーピアで実行しましたか？なぜ？ テスト自動化：テスト自動化をどのように処理しましたか。マイクロサービスアーキテクチャでは、これと継続的な統合が絶対に必要であるようです。どうやってそれをやりましたか？ 展開：どのように展開していますか？1つのVM /マイクロサービス、1つのコンテナー/マイクロサービス、またはその他の何か？各マイクロサービスがデータストアを持つことを考慮しなければ、数十のデータベースがあるという事実をどのように処理しましたか？それはインフラストラクチャに何を行い、DBAはそれをどのように処理しましたか？ インフラストラクチャ：このアーキテクチャでインフラストラクチャはどのように拡張されましたか。それはとてもおしゃべりで、あなたはそれを微調整する必要がありましたか、それともネットワークが問題なくそれを処理しましたか？セルフホストですか、それともクラウド内ですか？ モニタリング：あなたのモニタリング戦略は何ですか？数百のマイクロサービスではないにしても、数十のタブをどのように維持していますか？それは主にロギングと集中監視によるものですか？

8 c#  .net  microservices 

イベントソーシング、CQRS、マイクロサービスを使用するシステムを設計しています。これは珍しいパターンではないことを理解しました。このサービスの重要な機能は、記録システムから再水和/復元する機能である必要があります。マイクロサービスは、MQ（Kafka）でコマンドとクエリを生成します。他のマイクロサービスが応答します（イベント）。コマンドとクエリは、監査と復元の目的でS3に保持されます。 現在の思考プロセスは、システムを復元するために、S3からイベントログを抽出し、単純にKafkaにフィードバックできるというものでした。 しかし、これは時間の経過に伴う生産者と消費者の両方の変化を認めることができません。コマンド/クエリレベルでのバージョン管理は、問題の解決にある程度役立つようですが、復元中のコマンドが受信および処理されたときに、まったく同じになるようにコンシューマーのバージョン管理を行うことはできません。 [のバージョン]コマンドを最初に受信したときに処理を実行しているコード。 これを解決するために使用できるパターンはありますか？この機能を宣伝する他のシステムを知っている人はいますか？ 編集：例を追加します。 「バイヤー」が私のオークションサイトの「セラー」に「質問」を送信します。フローは次のようになります。 UI -> Web App: POST /question {:text text :to seller-id :from user-id} Web App -> MQ: SEND {:command send-question :args [text seller-id user-id]} MQ -< Audit: <command + args appended to log in S3> MQ -< Questions service: - Record question in DB …

8 versioning  cqrs  event-sourcing  microservices  apache-kafka