問題タブ [microservices]

すべてのマイクロ サービスがクラスター化されたアーキテクチャを設計しています。例: 5 つの Web サーバー、1 つのクラスター化されたデータベース、1 つのクラスター化されたキュー システム、キューから消費する 8 つのクラスター化されたワーカー (電子メールの送信、SMS の送信など) (タスクは Web サーバーによってプッシュされます)

各「マイクロ サービスのクラスター」が正常であることを検出するためのベスト プラクティスと、マイクロ サービスの 1 つが利用できない場合にサービス全体を「迅速に失敗させる」方法について疑問に思っています。

すべてのサービスは、ha プロキシ用の nginx の背後にあります。すべてを監視して失敗するのは nginx である必要がありますか? すべてのマイクロ サービスの正常性を確認するにはどうすればよいですか?

内部サービス間の通信用に、強く型付けされた (読み取り - 事前定義されたスキーマを使用) データ交換形式を導入することを考えています。たとえば、Thrift や Cap'n Proto のようなものだと思います。

JSONのようなものよりもこれを使用することの（私にとっての）少なくとも2つの明らかな利点は、

1. サービスが期待できるデータの正確な形式を知っている (したがって、通信中のあいまいさとエラーの余地が少なくなります)。
2. 通常、実装は生のメッセージを逆シリアル化し、オブジェクトにアクセスするためのメソッドを提供します。

JSON のようなものと比較して、このルートに進むことの実際的な欠点は何ですか?

コンテキスト - 私たちのシステムは、Python と Java で書かれたサービスで構成されています。また、将来的には他の言語で書かれる可能性もあり、HTTP エンドポイントを介して、サービスと rabbitmq などのメッセージ ブローカーとの間で通信します。

私は、複数の (多数の) サーバーを使用してソリューションを開発する環境で働いています。彼らのマイクロサービス スタイルはロール モデルです。

システムをアップグレードできるようにするには、実行時に切り替え可能/交換可能 (ユーザー インターフェイスを含む) である必要があります。決定された主な解決策は、

1. ポータル/プロキシは、エンド ユーザーに表示される唯一のシステムです。
2. プロキシは、サポートしているサーバーを「認識」しています
3. プロキシには、メニューなどの基本的なユーザー インターフェイスがあります。サブシステムと連携している可能性があります (メニューのいくつかのエントリなど)。
4. ユーザーが何らかの動的コンテンツを含むページをリクエストします
5. ポータルは、ページの「コンテンツ」部分のクエリをサブシステムにリレー/プロキシします。
6. クライアントが必要とする REST 呼び出しも、メイン サーバーを介してプロキシされます。

もちろん、REST 呼び出しは非常に単純ですが、私は Angular に慣れていないため、「ミックス」を作成する方法を本当に理解できません。ポイント 5 はもちろん難しい部分です。サブサーバーが表示されていれば、iframe (eeek!) が使用されていますが、この場合は使用されていません。

ページ内である種の「委任」が必要ですが、以前に行ったことはありますか? マイクロサービスの主力製品はユーザー インターフェイスをどのように処理しますか?

シングル サインオン認証/承認マイクロサービス アーキテクチャの優れた設計とは?

私の考え：

メッセージング バス (RMQ または Kafka) を介して非同期インターフェイスで認証と承認を処理するためのマイクロサービスを構築する必要があります。

• 認証サービスは、ユーザーの ID (ユーザー名、パスワード、電子メール) を管理するユーザー マイクロサービスである可能性があります。

• 認可サービスは次のことを担当します。

  1. 許可されたアクセス ロールを持つユーザーに Auth-Token を提供します。
  2. SSO サービスとして機能します。
  3. 他のマイクロサービスを承認して、誰もがバスにメッセージを発行するわけではありません。

いくつかの調査を行ったところ、2-legged OAuth が内部 Web/マイクロ サービスに使用されることがあることがわかりました。しかし、OAuth は主に HTTP 301 に依存しているため、内部で HTTP 呼び出しを行うと、内部システムのオーバーヘッドになると思います。

ありがとう！

キューからメッセージを受信し、指定された Id を持つ製品をドキュメント データベースから読み取り、メッセージに基づいて何らかの操作ロジックを適用し、最後に更新された製品をデータベースに書き戻すワーカー サービスがあるとします (a)。

この作業は、異なる製品を扱う場合でも安全に並行して実行できるため、水平方向にスケーリングできます (b)。ただし、複数のサービス インスタンスが同じ製品で動作する場合、同時実行の問題またはデータベースからの同時実行例外が発生する可能性があります。その場合、何らかの再試行ロジックを適用する必要があります (それでも、再試行は再び失敗する可能性があります)。 .

質問: どうすればこれを回避できますか? 2 つのインスタンスが同じ製品で動作していないことを確認する方法はありますか?

例/使用例: オンライン ストアでは、productA、productB、および productC のセールが 1 時間で終了し、何百人もの顧客が購入しています。購入ごとに、メッセージがキューに入れられます (productId、numberOfItems、price)。 目標: ワーカー サービスの 3 つのインスタンスを実行し、productA のすべてのメッセージが instanceA に、productB が instanceB に、productC が instanceC に到達するようにするにはどうすればよいでしょうか (同時実行の問題は発生しません)。

注: 私のサービスは C# で記述され、ワー​​カー ロールとして Azure でホストされています。メッセージングには Azure Queues を使用し、ストレージには Mongo を使用することを考えています。また、エンティティ ID はGUID.

それはテクニック/デザインに関するものなので、問題を解決するために別のツールを使用する場合、私はまだ興味があります.

いくつかの node.js サービスをリファクタリングしています。それらはすべてforever仮想サーバー上で開始され、プロセスがクラッシュした場合は再起動するだけでした。

さて、コンテナ化されたステートレスなアプリケーション構造に移行すると、プロセスが終了し、コンテナが失敗したときに再起動する必要があると思います。

あれは正しいですか？メリットやデメリットはありますか？

pythonに接続された多数のワーカーを持つバックエンドがありrabbitMQますcelery。Djangoと一緒に API ゲートウェイもありますpostgresql。ワーカー間のコンテキストは DB によって処理されます。

私たちそうしたい：

1. DB とワーカーを分離するには、
2. Go でワーカーを作成できるようにするため。

インフラストラクチャを調べましたがmicroservice、これは非常に興味深いようです。私たちが理解していないのは、どの種類のリクエスト/レスポンス パターンを使用する必要があるか、および共通のデータベースを使用せずにワーカー間のリクエストのコンテキストをどのように処理できるかです。

マイクロサービスの記事ではnotifications、 と を扱いsubscriptionます。これはこの状況に適用できますか、それとも HTTP リクエストを使用する必要がありますか。RPCパターンは使用されていますか？このパターンは非常に重いようです。

当然のことながら、このようなマイクロサービスと不変性の誇大宣伝により、次のような現実の問題が生じます。

不変であり、プレーンな SMTP から Sendgrid、MailJet、Mandrill、Mailgun などのトランザクション メール プロバイダーに至るまでの複数のプロバイダーをサポートするはずのコンテナー化されたアプリケーションから電子メールを送信する方法は?

過去のアーキテクチャ原則に基づいて構築されたソフトウェア システムでは、この問題は多くの場合、デフォルトの SMTP プロバイダをオーバーライドできるプラグイン メカニズムによって解決されています。ワードプレスはその一例です。ただし、これはアプリケーションの不変性を壊すため、悪い設計と見なされます。

Martin Fowler、Sam Newman、Adrian Cockcroft、Sudhir Tones の多数の記事を見て読んだ後、マイクロサービスは私のソフトウェアに非常に適しているようです。ただし、実装をより深く考えると、いくつかの懸念事項があります。

1. 私のソフトウェアには UI があります。これを Web ベースのコンポーネントと呼びましょう。このコンポーネントは、10 ～ 20 の異なるマイクロサービスへの呼び出しを内部で調整/調整し (「プライベート マイクロサービス」と呼びましょう)、AJAX 呼び出しにデータを返す必要があります。このコンポーネントでオーケストレーション ロジックを結合するのは適切な設計ですか? それとも、ジョブを実行する別のマイクロサービスを作成し、このマイクロサービスへの呼び出しを委任するために Web ベースのコンポーネントを非常に薄くする必要がありますか?
2. いくつかのパブリック API を公開する必要があります。上記の場合のように、呼び出しを委任するために別のレイヤーが必要ですか?

多かれ少なかれ、パブリック/プライベート マイクロサービスの設計パターンに関するものだと思います。

上記の懸念に対処するための良いパターンは何ですか?

2015 年 4 月 9 日更新:

API Gateway Pattern は実際に私の懸念に対処します。EAI パターンまたはセキュリティの考慮事項に関する他の回答にも同意します。

私の調査結果をさらに拡張すると、Netflix アーキテクチャにはいわゆる「エッジ サービス」があると思います。これは、Web ベースまたはデバイスからのリクエストを処理するフロント層であり、中間層サービスは実際にはマイクロサービスです。したがって、中間層サービスをエッジ サービスに昇格させるには、デリゲートが必要だと思います。これにより、中間層がクリーンで一貫した状態に保たれます。

さらにアイデアを得るには、https://github.com/cfregly/fluxcapacitor#project-overviewをご覧ください。