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

Question

私はマイクロサービスについて読んでみましたが、少し興味をそそられました。興味深いコンセプトのようです。しかし、モノリシックアーキテクチャよりもマイクロサービスを使用する場合の長所と短所、およびその逆は何でしょうか。

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

Kaj · Accepted Answer

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

マイクロサービスアーキテクチャを使用すると、懸念の分離と分離が増加します。あなたはアプリケーションを散らかしているので。

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

また、独立したマイクロサービスを個別に構築し、別々のサーバーに展開するため、アプリケーションの展開が簡単です。これは、アプリケーションの他の部分を再構築することなく、いつでも好きなときにサービスを構築およびデプロイできることを意味します。

さまざまなサービスは小さく、個別にデプロイされるため、明らかですスケーリングが容易それらは、アプリケーションの特定のサービスをスケーリングできるという利点があります過度の負荷がかかっているのは、アプリケーション内の特定の部分にすぎません）。

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

Paulo Merson · Answer

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

利点

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

課題

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

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

Will C · Answer

@Luxoが注目されています。ちょっとしたバリエーションを提供し、組織的な観点をもたらしたいと思います。マイクロサービスを使用すると、アプリケーションを切り離すことができるだけでなく、組織レベルでも役立ちます。たとえば、組織は複数のチームに分割し、それぞれがチームが提供するマイクロサービスのセットで開発することができます。

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

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