長所
Building Microservices のSam Newmanは、次のようにMicroservicesの主な利点を列挙しています。
技術の異質性
複数のコラボレーションサービスで構成されるシステムでは、各サービス内で異なるテクノロジーを使用することを決定できます。これにより、より標準化された万能型のアプローチを選択する必要がなくなり、最終的には共通点となることが多いため、各ジョブに適したツールを選択できます。
回復力
レジリエンスエンジニアリングの重要な概念は、bulkheadです。システムの1つのコンポーネントに障害が発生しても、その障害がカスケードしない場合は、問題を切り分けて、システムの残りの部分が機能し続けます。サービスの境界は明らかな隔壁になります。モノリシックサービスでは、サービスが失敗すると、すべてが機能しなくなります。モノリシックシステムでは、複数のマシンで実行して障害の可能性を減らすことができますが、マイクロサービスでは、サービスの障害全体を処理し、それに応じて機能を低下させるシステムを構築できます。
スケーリング
大規模なモノリシックサービスでは、すべてを一緒にスケーリングする必要があります。システム全体の一部がパフォーマンスに制約されていますが、その動作が巨大なモノリシックアプリケーションでロックされている場合、すべてを1つの要素としてスケーリングする必要があります。より小さなサービスでは、スケーリングが必要なサービスをスケーリングするだけで、システムの他の部分をより小さく、より強力でないハードウェア上で実行できます。
導入のしやすさ
100万行のモノリシックアプリケーションへの1行の変更では、変更をリリースするためにアプリケーション全体を展開する必要があります。これは、影響が大きくリスクの高い展開になる可能性があります。実際には、理解できる恐怖のために、影響が大きくリスクの高い展開がまれにしか発生しません。
マイクロサービスを使用すると、単一のサービスに変更を加えて、システムの他の部分から独立して展開できます。これにより、コードをより迅速に展開できます。問題が発生した場合、個々のサービスに迅速に切り分けることができ、高速ロールバックを簡単に実現できます。
組織の調整
マイクロサービスを使用すると、アーキテクチャを組織に合わせて調整できるため、1つのコードベースで作業する人数を最小限に抑えて、チームの規模と生産性の最適な場所に到達できます。また、チーム間でサービスの所有権を移動して、1つのサービスで作業している人々が同じ場所にいるようにします。
コンポーザビリティ
分散システムとサービス指向アーキテクチャの重要な約束の1つは、機能を再利用する機会を開くことです。マイクロサービスを使用すると、さまざまな目的でさまざまな方法で機能を使用できます。これは、消費者がソフトウェアをどのように使用するかを考えるときに特に重要です。
交換可能性の最適化
中規模以上の組織で働いている場合は、隅に座っている大きな厄介なレガシーシステムに気付いている可能性があります。誰も触れたくない人。会社の運営に不可欠なものですが、偶然のFortranバリアントで記述されており、25年前に寿命に達したハードウェアでのみ実行されます。なぜ置き換えられなかったのですか？理由はわかっています。大きすぎて危険な仕事です。
個々のサービスのサイズが小さいため、それらをより優れた実装に置き換えたり、完全に削除したりするコストは、管理がはるかに簡単です。
短所
マイクロサービスの最も重要な欠点は、分散システムに関連する複雑さをすべて備えていることです。分散システムを適切に管理する方法について多くのことを学びましたが、依然として困難です。モノリシックシステムの観点から来ている場合は、展開、テスト、および監視の処理をはるかに改善して、利点を引き出す必要があります。また、システムをどのように拡張し、復元力があることを確認するかについても異なる考え方が必要です。分散トランザクションやCAP定理などが頭痛の種になり始めても驚かないでください！
閉会の辞
Martin Fowler から引用するだけです：
私たちが聞いた合理的な議論の1つは、マイクロサービスアーキテクチャから始めるべきではないということです。代わりに、モノリスから始めてモジュール化し、モノリスが問題になったらマイクロサービスに分割します。
マイクロサービスの長所は、アプリケーションのスケーラビリティが非常に高いことです。アプリケーションを小さなサービスに分割します。必要な境界サービスを決定するのは難しいことです。ただし、一度これを行うと、アプリケーション全体をスケールアップする必要なく、特定のサービス（実際に最も負荷がかかるサービス）を簡単に複数回スケールアップできます。
別の利点は、新しい開発者がアプリケーションの新しい機能の作成を開始しやすくなることです。すべてがこれらの分離されたサービスに分割されるためです->各サービスには独自の（小さな）コードベースがあります。
マイクロサービスを使用する最大の欠点は、もちろん、異なるサービス間の通信中に障害が発生する可能性が高くなることです。
通常、マイクロサービスの使用は、モノリシックアプリケーションとして維持するにはアプリケーションが大きくなりすぎたときにのみ成果を上げ始めます。モノリシックとして開始してみてください。ただし、後で必要に応じてマイクロサービスに移行できるように開発中（可能な限り分離してください）、境界のあるコンテキストを念頭に置いてください。
利点
1.オーケストレーションではなくコレオグラフィーを使用した分散型および分離型アーキテクチャにより、サービスはパブリッシュ/サブスクライブベースになり、結果として完全に分散されます
2. 1つのことを実行し、それをうまく実行します（Unixの哲学）。
3.ビジネスプロセスの観点からよりきめ細かいため、並列処理と負荷分散が容易
4.ただし、ステートレスなマイクロサービスを持つことは有効ですが、理想的ではありません
5.個々のデータストレージによりサービスが緩和され、データフローを追跡し続ける
6. Dockerなどのコンテナエンジンベースのテクノロジーの使用による簡単で自動化された展開と検出
7.より多くの相互運用性。これにより、サービスは、新しい/現在のサービスまたはプロトコルを受け入れ/ドロップする際の柔軟性を高めることができます。
8.ステートレスサービスの作成を可能にするRepresentational State Transfer（REST）との完全な互換性
9.例えばバッチ自動化プロセスなどの個別システムに適しています
短所1.サービスの同期、サービスの協調的な同期の維持
2.体系的な問題を見つけるのが難しい。たとえば、プロセスに論理的なエラーがある場合、ビジネスアクティビティのチェーンで問題を見つけるのはより難しく、複数のログファイルを1つにまとめる必要がある
3.マイクロサービスの数が数個を超える場合、自動化された展開と検出が必須
4.適切なサービスの粒度を見つけることが困難であり、ネットワーク通信とエラー率が圧倒されるため、システム全体が不安定になる可能性がある
5.プロセス制御を継続するなど、ビジネスシステムが十分に分離されていない場合の挑戦
6.自動テストの開発は、モノリシックシステムよりもかなり難しい
以下は、コードプロジェクトのマイクロサービスについて公開された一連の記事です。必要に応じて、質問を読んでコメントすることができます。
https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-Ihttps://www.codeproject.com/Articles/1264113/ Dive-into-Microservices-Architecture-Part-IIhttps://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-III