SOA とマイクロサービス – それらの違い

サービス指向アーキテクチャ (SOA) とは何ですか?

SOA は、コンピュータ ソフトウェア設計におけるアーキテクチャ パターンです。このタイプのアプリケーションでは、コンポーネントは、通常はネットワークを介して通信プロトコルを介して他のコンポーネントにサービスを提供します。サービス指向の原則は、製品、ベンダー、またはテクノロジに依存しません。SOA の完全な形式は、サービス指向アーキテクチャです。

SOA により、さまざまなネットワーク上のソフトウェア コンポーネントが相互に連携しやすくなります。SOA アーキテクチャに従って構築された Web サービスは、Web サービスの独立性を高める傾向があります。

マイクロサービスとは何ですか？

Microservices アプリケーションがさまざまな最小の独立したサービス ユニットの集合として構築されるサービス指向アーキテクチャ パターンです。これは、アプリケーションを明確に定義されたインターフェイスを持つ単機能モジュールに分解することに重点を置いたソフトウェア エンジニアリング アプローチです。

これらのモジュールは、サービスのライフサイクル全体を所有する小規模なチームによって独立して展開および運用できます。

「マイクロ」という用語は、単一の開発チーム (5 ～ 10 人の開発者) が管理できる必要があるマイクロサービスのサイジングを指します。 この方法では、大きなアプリケーションが最小の独立したユニットに分割されます。

SOA とマイクロサービスの違い

SOA とマイクロサービスの違いは次のとおりです。

SOA (サービス指向) Archi構造)	Microservices
SOA モデルには、そのアプリケーション内のすべてのサービスによって共有される単一のデータ ストレージ層があります。	マイクロサービス アプリは、ほとんどの場合、データベースまたはその他の種類のストレージを、それを必要とするサービス専用にします。
SOA アプリ内の異なるサービス間の通信には、シンプルで単純なアプローチが使用されます。	マイクロサービスは複雑な API を使用します。
アプリケーションサービスの再利用性を最大化することに重点を置いています。	デカップリングにさらに焦点を当てます。
体系的な変更にはモノリスの変更が必要です。	体系的な変更は、新しいサービスの作成に役立ちます。
DevOps と継続的デリバリーは人気が高まっていますが、まだ主流にはなっていません。	DevOpsと継続的デリバリーを重視
本質的に一枚岩	自然の中でのフルスタック
複数のメッセージ プロトコルをサポートします。	HTTP、REST、Thrift API などの軽量プロトコルを使用します。
サービス間でリソースを共有するように設計されています。	独立して機能できるサービスをホストするように設計されています。
コンポーネントの共有が頻繁に発生する	通常、コンポーネントの共有は含まれません。
サービス間でのデータ ストレージの共有が含まれます	各サービスは独立したデータ ストレージを持つことができます。
大規模な統合に適しています	小規模な Web ベースのアプリケーションに適しています。
ESB経由で通信します	API レイヤーを介して通信する
リソースの共有に依存している	結合のために境界付けられたコンテキストに依存します。
Less 展開の柔軟性	迅速かつ簡単な導入。
SOA の技術スタックは、マイクロサービスに比べて低いです。	マイクロサービス テクノロジ スタックは非常に大規模になる可能性があります。
ビジネスユニットは依存しています。	ビジネスユニットは互いに独立しています。
XNUMX つまたは XNUMX つのサービスで構成される SOA アプリ。	マイクロサービス アプリには数十のサービスが含まれる場合があります。
SOA アプリケーションは、多数のビジネス タスクを実行するために構築されています。	これらは、単一のビジネス タスクを実行するように構築されています。
導入は時間のかかるプロセスです。	導入は簡単で、時間がかかりません。
ビジネス ロジック コンポーネントは、単一のサービス ドメイン内に保存されます。シンプルなワイヤ プロトコル (XML JSON を使用した HTTP) API は、SDK/クライアントで駆動されます。	ビジネス ロジックは、サービス間の個別のレイヤーのように、エンタープライズ サービス バスのドメイン全体に存在できます。
通信にエンタープライズ サービス バス (ESB) を使用します	それほど複雑ではない単純なメッセージング システムを使用します
従来のソフトウェアに比べてソフトウェアサイズが大きい	マイクロサービスではソフトウェアのサイズが小さい
I/Oを処理するための複数のオーバーヘッドを備えたマルチスレッド	シングルスレッドは主に、非ロック I/O 処理のためのイベント ループ機能と併用します。
モノリスを修正するには体系的な変更が必要	マイクロサービスにおける体系的な変更とは、新しいサービスを作成することです
アプリケーション サービスの再利用性を最大限に高めることに重点を置きます。	デカップリングを重視します。
共通のガバナンスと標準。	人々の協力と選択の自由に重点を置いた、緩和されたガバナンス。
導入プロセスには時間がかかります。	導入は簡単で、時間もかかりません。
Less スケーラブルなアーキテクチャ。	高度にスケーラブルなアーキテクチャ。

SOAとは Archi構造？

サービス指向アーキテクチャはソフトウェア設計のスタイルです。アーキテクチャは2つの部分に分類されます。

1. 機能面と
2. サービスの品質の側面。

両方を詳しく見てみましょう:

機能的側面

機能面には次のものが含まれます。

輸送: このコンポーネントは、サービス リクエストをサービス コンシューマからサービス プロバイダに転送し、サービス リクエストからサービス コンシューマにサービス応答を転送します。

サービス通信プロトコル: サービスプロバイダーとコンシューマーが相互に通信できるようにします。

サービス Descriptexpression CMS: サービスとそれを呼び出すために必要なデータについて説明します。

サービス：実際のサービスです。

ビジネスプロセス： このコンポーネントは、ビジネス要求を満たすために、特定のルールに関連付けられた特定の事前定義されたシーケンスで呼び出されるサービスのグループを表します。

サービスレジストリ: このレジストリには、サービス プロバイダーがサービスを公開するために使用するデータの説明が含まれています。

サービス品質の側面

サービスの品質には次のものが含まれます。

• ポリシー： これは、サービスプロバイダーがサービスを作成し、消費者に提供する際に従う一連のプロトコルです。
• セキュリティ： これは、識別および認可プロセスに必要なプロトコルのセットを表します。
• トランザクション： 一貫した結果が確実に得られます。
• 管理： SOA のこのコンポーネントは、サービスの管理に使用される属性のセットを定義するのに役立ちます。

マイクロサービスとは Archi構造？

これは、ビジネス ドメイン向けに開発された小さな自律的なサービスのコレクションとしてアプリケーションを構築できるアーキテクチャ開発スタイルです。

マイクロサービス アーキテクチャで開発された電子商取引アプリケーションの例を見てみましょう。この例では、各マイクロサービスは単一のビジネス機能に焦点を当てています。検索、評価とレビュー、支払いにはそれぞれインスタンス (サーバー) があり、相互に通信します。

このモノリシックでは Archiこの構造では、すべてのコンポーネントが 1 つのモジュールに結合されます。しかし、マイクロサービスでは Archi構造上、それらは相互に通信する個々のモジュール (マイクロサービス) に分散されます。

マイクロサービス間の通信は、リクエストとレスポンスの各ペアが独立したステートレス通信です。したがって、マイクロサービスは簡単に通信できます。マイクロサービスでは Archiこの構造では、データはフェデレーションされます。各マイクロサービスには個別のデータ ストアがあります。

SOAの特徴

SOA の重要な機能は次のとおりです。

• SOA は、大規模システムにおける困難な統合問題を解決するインターフェイスを使用します。
• SOA は、XML スキーマを使用して顧客、プロバイダー、およびサプライヤーと通信します。
• SOA はメッセージ監視を使用してパフォーマンス測定を改善し、セキュリティ攻撃を検出します。
• サービスを再利用するため、ソフトウェアの開発と管理のコストが若干低くなります。

マイクロサービスの特徴

マイクロサービスの重要な機能は次のとおりです。

• マイクロサービスでは、モジュールは疎結合されています。
• プロジェクトの管理もモジュール化できます。
• スケーラビリティのコストはわずかです
• 複数のテクノロジーをアプリケーションの複数の機能として使用するのは非常に簡単です。
• これは、いつかアプリケーションにアクセスする可能性のあるデバイスの種類を予測できない、進化するシステムにとって理想的なサービスです。

SOAの利点

SOAの長所/利点は次のとおりです

• どのサービスも編集と更新が簡単です
• サービスは同じディレクトリ構造を持っているため、コンシューマは毎回同じディレクトリからサービス データにアクセスできます。
• サービスは共通言語を使用して他のアプリケーションと通信します。つまり、プラットフォームから独立しています。
• サービスは通常、本格的なアプリケーションに比べて小さいサイズです。 したがって、独立したサービスのデバッグとテストが容易になります。
• SOA を使用すると、既存のシステムのサービスを再利用し、代わりに新しいシステムを構築できます。
• 新しいビジネス要件を満たすために、新しいサービスを導入したり、既存の設備をアップグレードしたりすることを提案します。
• サービスのパフォーマンスや機能性を強化し、システムのアップグレードを簡単に行うことができます。
• SOA はさまざまな外部環境を調整または変更できます
• 企業は、既存のアプリケーションを置き換えることなくアプリケーションを開発できます。
• 多数のコードと比較して、独立したサービスをテストおよびデバッグできる信頼性の高いアプリケーションを提供します。

マイクロサービスの利点

マイクロサービスを使用する利点は次のとおりです。

• 開発者にとって理解しやすい、より簡単なアーキテクチャパターン
• IDE の高速化により、開発者の作業スピードと生産性が向上します。
• Web コンテナの起動が速くなります。 これは、展開と開発のプロセスをスピードアップするのに役立ちます。
• これにより、チームは他のすべてのチームから独立してサービスを開発、展開、拡張できます。

SOAの欠点

サービス指向アーキテクチャを使用する場合の短所とデメリットは次のとおりです。

• すべての入力はサービスに送信される前に検証される必要があります
• SOA は、人的リソース、開発、テクノロジーの点でコストがかかるサービスです。
• 一部の Web サービスではメッセージや情報を頻繁に送受信する必要があるため、XNUMX 日あたりのリクエストは簡単に XNUMX 万件に達します。
• SOAには多額の投資コストが必要
• サービスが別のサービスと対話する場合、オーバーヘッドが大きくなり、応答時間が増加します。
• SOA サービスは GUI (グラフィカル ユーザー インターフェイス) アプリケーションには適していないため、SOA で大量のデータ交換が必要になると、サービスがより複雑になります。

マイクロサービスのデメリット

マイクロサービスの短所/欠点は次のとおりです。

• これはモノリシックアプリケーションの構築用に開発されているため、開発に対する明示的なサポートは提供していません。ping 分散アプリケーション。
• テストはさらに難しくなります
• 開発者はサービス間通信メカニズムを実装する必要があります。
• 複数のサービスにまたがるユースケースを実装するには、チーム間の調整が必要です。
• マイクロサービスは、さまざまなビジネスタスクのためにさまざまなサーバースペースを常に維持する必要があるため、コストがかかります

どの Archi構造は優れていますか？

SOA は、大規模で複雑なビジネス アプリケーションに最適なアーキテクチャ手法です。さまざまなアプリケーションとの統合を必要とする環境に最適です。

ただし、明確に定義された処理フローを持つワークフローベースのアプリケーションを SOA アーキテクチャ パターンで実装するのは困難です。したがって、小規模なアプリケーションはミドルウェア メッセージング コンポーネントを必要としないため、SOA には適していません。一方、マイクロサービス パターンは、小規模で適切に分割された Web ベースのシステムに適しています。