自律マイクロサービス、イベントキュー、およびサービス検出

私は最近マイクロサービスについて多くのことを読んでいますが、これまでに得た結論のいくつかを以下に示します（私が間違っている場合は修正してください）。

1. マイクロサービスアーキテクチャは、ドメイン駆動型の設計に適しています。通常、1つのMSは1つの境界付きコンテキストを表します。
2. マイクロサービスAがマイクロサービスBにある機能を必要とする場合、私のモデルはおそらく間違っており、AとB は実際には1つのマイクロサービス/ BCである必要があります。
3. マイクロサービス（直接HTTPリクエスト）間の同期通信は不良であり、マイクロサービスの目的に反し、コンポーネント間の結合を導入します。
4. サービス間の非同期通信が望ましい。サービスはイベントをメッセージキューに発行する必要があります。これにより、他のサービスがイベントの一部をサブスクライブおよび処理したり、コンテキストを使用してデータの一部を複製したりできます。これにより、サービスは他のサービスがダウンしていても要求を処理できますが、同期通信の場合はそうではありません。
5. マイクロサービスAがイベントを発行し、マイクロサービスBがそのイベントをサブスクライブし、結果として新しいイベントを生成する場合、マイクロサービスAが新しく作成されたイベントを処理するものであってはなりません。この場合、3番目のマイクロサービスを導入するか、ABマイクロサービスにAとBを組み合わせます。
6. マイクロサービスは実際には誤解を招く用語です。私たちは小さな文脈に努めるべきですが、そうである必要はありません。用語は「マイクロサービス」ではなく、「ジョブサービスを行うのに十分な大きさ」である必要があります。
7. マイクロサービスにより、システム全体を壊すことを恐れることなく、より簡単に新しい機能を導入できます。新しいサービスを導入するか、既存のサービスをリファクタリングすることで実現できます。
8. 各マイクロサービスには、独自のデータストレージが必要です。このアーキテクチャでは、データの複製/複製が望ましい動作です。

このアーキテクチャについての私の理解を確認する以外に、質問の他の部分は主にサービスの発見に関連しています。サービスが非同期で通信しており、Amazon SQSのような中央イベントキューを使用している場合、そのようなアーキテクチャではサービスディスカバリーがその場所にないということですか？

サービスは、システム内の他のサービスに関する知識を持っていてはなりません。彼らは、自分のコンテキストと、発行または購読するイベントのみを認識していますか？

あなたの結論の大部分は根拠に基づいており、マイクロサービスの道を非常にうまくまとめています。

ただし、2、5、および8は完全にはサポートしていません。

• 2）単純な依存関係が自動的に合併することはありません。このような依存呼び出しの頻度と、他のサービスからの呼び出しの頻度を考慮する必要があります。

  したがって、マイクロサービスAがマイクロサービスBの機能を非常に頻繁に必要とし、他のマイクロサービスがマイクロサービスBを必要とすることはめったにない場合、想定される構造に挑戦し、両方のマイクロサービスをグループ化するのが適切でないかどうかを尋ねる必要があります。

• 5）もちろん、メッセージ処理の無限の循環を避ける必要があります。

  しかし、仲介者を追加してもそれを防ぐことはできません。AはBが処理するメッセージを起動するCが処理するメッセージを起動できます。AはBが処理するメッセージを起動します。

  この問題は、マイクロサービスレベルを考慮するだけでは評価できません。問題は、実際にサイクルにつながる可能性のあるメッセージタイプとコンテンツに関するものです。したがって、サービス全体のメッセージの分散と処理をモデル化するグラフは、全体として分析する必要があります（実際、これは複雑になる可能性があるため、このようなサイクルを検出して中断する監視マイクロサービスを想像できます）。

• 8）はい、各マイクロサービスには専用のストレージ/データベースが必要です。

  サービスを独立させるには、最小限の複製が必要です。ただし、ここまでは複製が望ましいとは言いません。複製プロセスを介した隠れた結合を避けるために、最小限に抑える必要があります。

  マイクロサービスは、疎結合に関するものです。これは、データをレプリケートする代わりに、別のマイクロサービスを呼び出して関連データを取得することで、より効果的に実現できる場合があります。

最後の2つの無数の断言は広すぎて、ここでしっかりと答えることはできません。あなたの提案は良い出発点だと思いますが、それは本当にアーキテクチャの要件と制約に依存するということです。

マイクロサービスとは、異なる機能ドメインを分離することです。各サービスは、異なる技術スタックを使用して、異なるチームが異なるペースで開発できます。これにより、組織の柔軟性が生まれます。トレードオフは運用の複雑さであり、各追加サービスは運用環境で管理する必要のあるものをもう1つ作成します。したがって、モノリスとマイクロサービスの基本的なトレードオフは、依存関係を回避することではなく、すべてを一度に出荷しなければならないロックステップ開発と展開を回避することですが、より多くの可動部品。

サービスは、システム内の他のサービスに関する知識を持っていてはなりません。彼らは、自分のコンテキストと、発行または購読するイベントのみを認識していますか？

依存関係回避の問題は、ニシンです。製品の各部分には常に依存関係があり、それらが別のサービスにあるか、同じコードの一部にあるかによって、依存関係が壊れるという事実は変わりません。キーサーバーがダウンするため、運用レベルで中断する可能性があり、運用上の冗長性とフェールオーバーの実践を通じて管理します。また、部品は互換性のない方法で変更されるため、統合レベルで破損する可能性があります。これは統合テストで検出されます。サービス間でコードをシャッフルしても、依存関係が破損する可能性のある問題は解決されません。依存関係の破損を回避するためのソリューションは、運用上の冗長性と統合テストであり、サービスのサイズとは関係ありません。

サービスが非同期で通信し、Amazon SQSのような中央イベントキューを使用している場合、それはサービスディスカバリーがそのようなアーキテクチャでその場所を持たないことを意味しますか？

その質問に答えるには、まずこの質問に答えてください。なぜ非同期に通信したいのですか？個別のコンポーネントの独立した開発を容易にするためですか？年中無休のシステムの運用可用性を向上させるためですか？後者の場合、キューを使用してデータをローカルデータベースに複製するとします。さて、今あなたのデータは古くなっています。ある時点で古すぎるでしょう。どのように対処しますか？さらに、別のランタイムコンポーネントであるキューの運用上の可用性をどのように確保しますか？そして、それらのローカルデータベースの可用性をどのように確保しますか？1つのデータベースクラスターを管理する代わりに、複数のデータベースクラスターがあります。運用チームはこのワークロードを処理できますか？本当に、単純なモノリスを構築した場合、ユーザーがより多くの機能と毎月数時間のダウンタイムで幸せになるとしたら、複雑さは価値がありますか？

あなたは私のポイントを見ると思います。システム設計は正しいことも間違っていることもありません。さまざまなトレードオフから選択することです。間違っているものはすべて正しい場合がありますが、正しいコンテキストでのみ表示される場合は、逆も同様です。あなたのコンテキストは、あなたにユニークであるので、私たちはあなたを与えることができながら答えを、それができなくなります答え。あなたの聴衆が誰であるか、彼らのニーズが何であるかを思い出してください、そして、正しいデザインはそれ自身を明らかにします。

1. マイクロサービスアーキテクチャは、ドメイン駆動型の設計に適しています。通常、1つのMSは1つの境界付きコンテキストを表します。

同意しない。DDDは非常にオブジェクト指向になる傾向があります。注文は配達されますか？Order.Deliver（）に対して、マイクロサービスにはDeliveryService.Deliver（order）があります

2. マイクロサービスAがマイクロサービスBにある機能を必要とする場合、私のモデルはおそらく間違っており、AとBは実際には1つのマイクロサービス/ BCである必要があります。

同意しない、あなたはマイクロサービスをマイクロにしてみてください それらをさらに小さく分割します！

3. マイクロサービス（直接HTTPリクエスト）間の同期通信は不良であり、マイクロサービスの目的に反し、コンポーネント間の結合を導入します。

同意しない。サービスは誰が呼び出しているかを気にするべきではなく、呼び出し側はロジックがマイクロサービスに実装されていることを気にするべきではありません。

4. サービス間の非同期通信が望ましい。サービスはイベントをメッセージキューに発行する必要があります。これにより、他のサービスがイベントの一部をサブスクライブおよび処理したり、コンテキストを使用してデータの一部を複製したりできます。これにより、サービスは他のサービスがダウンしていても要求を処理できますが、同期通信の場合はそうではありません。

キューは良いです。しかし、あなたの推論は間違っています。同期応答と非同期の唯一の違いは、同期応答を待つことです。キューを使用してRPCスタイルの呼び出しを実装し、複数のワーカーを問題なく実装できます。

5. マイクロサービスAがイベントを発行し、マイクロサービスBがそのイベントをサブスクライブし、結果として新しいイベントを生成する場合、マイクロサービスAが新しく作成されたイベントを処理するものであってはなりません。この場合、3番目のマイクロサービスを導入するか、ABマイクロサービスにAとBを組み合わせます。

同意しない。マイクロサービスが結合されていないため、循環依存関係ではありません。また、再送シナリオに対応したい場合は、SendEmail、EmailFailed、SendAgainは3つのマイクロサービスを必要としません

6. マイクロサービスは実際には誤解を招く用語です。私たちは小さな文脈に努めるべきですが、そうである必要はありません。用語は「マイクロサービス」ではなく、「ジョブサービスを行うのに十分な大きさ」である必要があります。

同意しない。ナノサービスをご覧ください。

7. マイクロサービスにより、システム全体を壊すことを恐れることなく、より簡単に新しい機能を導入できます。新しいサービスを導入するか、既存のサービスをリファクタリングすることで実現できます。

同意しない。はい、デカップリングを取得しますが、マイクロサービスのオーケストレーションは、モノリスプロジェクトと同じくらい困難です

8. 各マイクロサービスには、独自のデータストレージが必要です。このアーキテクチャでは、データの複製/複製が望ましい動作です。

同意しない。ストレージを共有するべきではありませんが、マイクロサービスは可能な限りステートレスになるようにすべきです。飛行中でなければデータを複製しないでください

あなたの結論はいい経験則ですが、普遍的ではありません。グリーンフィールドプロジェクトであっても、これらのルールを破ることが最善の選択肢である場合があります。場合によっては、同期通信が最適なオプションです。場合によっては、2つのサービスが同期通信で結合されていても、2つのサービスを1つに統合することは適切ではありません。

また、他の質問に、キューベースの通信にはサービス検出は必要ありません。

ええと、あなたはオブジェクト指向プログラミングについて話しているだけです。または少なくとも、当初考えられていたもの：メッセージを使用して互いに通信する実行中の独立したコード。

Alan Kayは、細胞が互いに比較的独立しており、他の細胞の外部インターフェースにプラグインするメッセージを通じて通信する生物学的システムをモデルにしたOOPを考案しました。

それでは、すべてのオブジェクトが同じコンピューター上で実行されていないという理由だけで、OOPと考えるのをやめるのはなぜですか？どちらかといえば、それはだ、よりオブジェクト指向のすべてのオブジェクトが同じアプリである場合、開発者は多くの場合、すべてのクラスが共有するグローバル変数を使用してOOPを破るために、彼らは同じアプリケーションの同じコンピュータおよび一部にしている場合よりもとすべてのオブジェクトが同じものに依存する場合、それらは互いに完全に独立しているようにカプセル化されておらず、カプセル化はOOPのポイントです。

たとえば、他の回答で述べられているほぼすべてが、OOPに関する教科書の記述です。

境界コンテキストやコアドメインなどの重要な概念の誤った理解に頻繁に遭遇するため、少し詳しく説明したいと思います。

サブドメインをビジネス機能のように考えることは非常に有益です。ビジネス能力は、組織が行うことです。それはそのビジネス機能の1つです。私たちの目標はビジネスとITの連携であるため、間違いなく彼らが私の技術サービスと1対1の関係を持つことを望んでいます。

したがって、このプロセスは次のようになります。最初に、より高いレベルのビジネス機能を定義します。名詞と動詞の形式（または派生語）を使用する必要があります。通常、ビジネス機能は10個未満です。それから、私はさらに深く、ネストされた機能を特定します。など、分割するものがなくなるまで。このアプローチを使用して得られた機能は、実際のドメイン、組織の実際の方法を反映しています。これらの機能は本質的に疎結合であるため、技術サービスをこの機能にマッピングすると、自律的でイベント駆動型になります。このプロセスはビジネス機能マッピングと呼ばれますが、サービスを見つける方法は他にもありますが、最も顕著な方法はおそらくバリューチェーン分析です。

このアプローチを使用してサービス境界を識別する例を次に示します。