マイクロサービスとモノリシックアーキテクチャ[クローズ]

マイクロサービスについて読んだのですが、少し興味があります。面白いコンセプトのようです。しかし、モノリシックアーキテクチャよりもマイクロサービスを使用する場合の長所と短所は何ですか。その逆も同様です。

マイクロサービスがより適切な場合、およびモノリシックアーキテクチャを使用するのに適した場所。

私はマイクロサービスの世界に比較的慣れていませんが、可能な限り完全にあなたの質問に答えようとします。

マイクロサービスアーキテクチャを使用すると、関心の分離と分離が増加します。あなたは文字通りあなたのアプリケーションを分割しているので。

これにより、コードベースの管理が容易になります（各アプリケーションは、稼働状態を維持するために他のアプリケーションから独立しています）。したがって、これを正しく行うと、将来、アプリケーションに新しい機能を追加するのが簡単になります。一方、モノリシックアーキテクチャでは、アプリケーションが大きい場合は非常に困難になる可能性があります（そして、ある時点でそれが大きくなると想定できます）。

また、独立したマイクロサービスを個別に構築し、それらを個別のサーバーにデプロイするため、アプリケーションのデプロイも簡単です。つまり、アプリケーションの残りの部分を再構築しなくても、いつでもサービスを構築してデプロイできます。

さまざまなサービスが小さく、個別にデプロイされるため、アプリケーションの特定のサービスをスケーリングできるという利点があり、それらをスケーリングする方が明らかに簡単です（モノリシックでは、それが内の特定の部分である場合でも、完全な「もの」をスケーリングできます）過度の負荷がかかっているアプリケーション）。

ただし、将来管理するには大きくなりすぎることを意図していないアプリケーションの場合。モノリシックアーキテクチャで維持することをお勧めします。マイクロサービスアーキテクチャにはいくつかの深刻な問題があります。マイクロサービスをデプロイする方が簡単だと述べましたが、これは大きなモノリスと比較した場合にのみ当てはまります。マイクロサービスを使用すると、さまざまな場所にあるさまざまなサーバーにサービスを配布するという複雑さが増し、それらすべてを管理する方法を見つける必要があります。マイクロサービスを構築すると、アプリケーションが大きくなった場合に長期的には役立ちますが、小規模なアプリケーションの場合は、モノリシックを維持する方が簡単です。

これは非常に重要な質問です。マイクロサービスに関するすべての話題に魅了される人が少なく、考慮すべきトレードオフがあるからです。では、マイクロサービスの利点と課題は何ですか（モノリシックモデルと比較した場合）？

利点

• デプロイ可能性：ビルド+テスト+デプロイのサイクルが短いため、サービスの新しいバージョンをロールアウトするための俊敏性が向上します。また、サービス固有のセキュリティ、レプリケーション、永続性、および監視構成を採用する柔軟性。
• 信頼性：マイクロサービスの障害は、そのマイクロサービスのみとそのコンシューマーに影響を与えますが、モノリシックモデルでは、サービスの障害によってモノリス全体がダウンする可能性があります。
• 可用性：マイクロサービスの新しいバージョンをロールアウトする場合、ダウンタイムはほとんど必要ありませんが、モノリスでサービスの新しいバージョンをロールアウトする場合は、通常、モノリス全体の再起動が遅くなります。
• スケーラビリティ：各マイクロサービスは、プール、クラスター、グリッドを使用して個別にスケーリングできます。デプロイの特性により、マイクロサービスはクラウドの弾力性に最適です。
• 変更可能性：新しいフレームワーク、ライブラリ、データソース、およびその他のリソースを使用するための柔軟性が向上します。また、マイクロサービスは疎結合のモジュラーコンポーネントであり、契約を介してのみアクセスできるため、大きな泥だんごになりにくいです。
• 管理：アプリケーション開発の取り組みは、より小規模でより独立して機能するチームに分割されます。
• 設計の自律性：チームは、さまざまなテクノロジー、フレームワーク、パターンを使用して各マイクロサービスを設計および実装する自由があり、各マイクロサービスを個別に変更および再デプロイできます

課題

• 展開可能性：展開ユニットがはるかに多いため、展開を監視するためのより複雑なジョブ、スクリプト、転送領域、および構成ファイルがあります。（そのため、マイクロサービスプロジェクトには継続的デリバリーとDevOpsが非常に望ましいです。）
• パフォーマンス：サービスはネットワークを介して通信する必要がある可能性が高くなりますが、モノリス内のサービスは市内通話の恩恵を受ける可能性があります。（そのため、設計では「おしゃべりな」マイクロサービスを回避する必要があります。）
• 変更可能性：契約の変更は、他の場所に配置された消費者に影響を与える可能性が高くなりますが、モノリシックモデルでは、消費者はモノリス内にいる可能性が高く、サービスとロックステップで展開されます。また、結果整合性や非同期呼び出しなど、自律性を向上させるメカニズムにより、マイクロサービスが複雑になります。
• テスト容易性：統合テストは、さまざまなランタイム環境でさまざまなマイクロサービスにまたがる可能性があるため、セットアップと実行が困難です。
• 管理：監視するランタイムコンポーネント、ログファイル、およびポイントツーポイントの相互作用が増えるため、操作を管理するための労力が増加します。
• メモリの使用：複数のクラスとライブラリが各マイクロサービスバンドルに複製されることが多く、全体的なメモリフットプリントが増加します。
• 実行時の自律性：モノリスでは、ビジネスロジック全体が併置されます。マイクロサービスを使用すると、ロジックはマイクロサービス全体に分散されます。したがって、他のすべてが等しい場合、マイクロサービスがネットワークを介して他のマイクロサービスと相互作用する可能性が高くなります。相互作用によって自律性が低下します。マイクロサービス間の相互作用にデータの変更が含まれる場合、トランザクション境界の必要性により、自律性がさらに損なわれます。幸いなことに、実行時の自律性の問題を回避するために、結果整合性、イベント駆動型アーキテクチャ、CQRS、キャッシュ（データレプリケーション）、マイクロサービスとDDDバウンドコンテキストの調整などの手法を採用できます。これらの手法はマイクロサービスに固有のものではありませんが、私が読んだ事実上すべての著者によって提案されています。

これらのトレードオフを理解したら、他の質問に答えるために知っておく必要のあることがもう1つあります。それは、マイクロサービスとモノリスのどちらが優れているかということです。アプリケーションの非機能要件（品質属性要件）を知る必要があります。たとえば、パフォーマンスとスケーラビリティの重要性を理解したら、トレードオフを比較検討し、知識に基づいた設計上の決定を下すことができます。

@Luxoは的を射ています。ちょっとしたバリエーションを提供し、組織的な視点をもたらしたいと思います。マイクロサービスを使用すると、アプリケーションを分離できるだけでなく、組織レベルでも役立つ場合があります。たとえば、組織は複数のチームに分割でき、各チームはチームが提供する一連のマイクロサービスで開発できます。

たとえば、Amazonのような大規模なショップでは、パーソナライズチーム、eコマースチーム、インフラストラクチャサービスチームなどが存在する場合があります。マイクロサービスを利用したい場合は、Amazonがその良い例です。Jeff Bezosは、共有機能へのアクセスが必要な場合、チームが別のチームのサービスと通信することを義務付けました。簡単な説明については、こちらをご覧ください。

さらに、EtsyとNetflixのエンジニアも、Twitterでマイクロサービスとモノリスの時代に小さな議論をしました。議論は少し技術的ではありませんが、いくつかの洞察も提供できます。