マイクロサービス (MicroServices) は、もともと Martin Fowler が 2014 年に発表した論文「MicroServices」で提案した用語です。提案されると、技術界で大きな話題になりました。
マイクロサービスは文字通り「小さなサービス」と理解できますが、以下では「サービス」と「小さなサービス」という 2 つの側面からマイクロサービスを紹介します。
1) いわゆる「サービス」とは、実際にはプロジェクト内の機能モジュールを指し、ユーザーが特定の問題または一連の問題を解決するのに役立ち、IDE (Eclipse や IntelliJ などの統合開発環境) の 1 つとして表示されます。 IDEA) 開発プロセスのエンジニアリングまたはモジュール。
2) 「Tiny」は 1 つのサービスのサイズを強調しており、これは主に次の 2 つの側面に反映されています。
- マイクロサービスはサイズが小さく、複雑さが低いです。マイクロサービスは通常、単一のビジネス機能サービスのみを提供します。つまり、マイクロサービスは 1 つのことをうまく実行することだけに重点を置いているため、通常、マイクロサービスのコードは少なく、サイズは小さく、複雑さは高くなります。
- マイクロサービス チームに必要なメンバーは少なくて済みます。通常、マイクロサービス チームは、設計、開発、テストから運用、保守までのすべての作業を完了するのに、8 ～ 10 人 (開発者 2 ～ 5 人) だけで済みます。
マイクロサービスアーキテクチャ
マイクロサービス アーキテクチャは、システム アーキテクチャの設計スタイルです。従来のモノリシック アーキテクチャ (ALL IN ONE) とは異なり、マイクロサービス アーキテクチャでは、単一のアプリケーションを複数の小さなサービスに分割することを推奨しています。これらの小さなサービスはすべて独自の独立したプロセスで実行され、軽量のサービスがサービス間で使用されます。 レベルの通信メカニズム (通常はHTTP RESTFUL API) を使用して通信します。
通常、これらの小規模なサービスは特定のビジネスを中心に構築されており、各サービスは 1 つのタスクを完了し、それをうまく実行すること、つまり「プロフェッショナルな人がプロフェッショナルな仕事をする」ことだけに重点を置いています。
各サービスは開発環境、テスト環境、本番環境などのさまざまな環境に独立してデプロイでき、各サービスは他のサービスに影響を与えることなく独立して起動または破棄できます。
これらのサービス間の対話は標準の通信テクノロジを使用して実行されるため、異なるサービスは異なるデータ ストレージ テクノロジを使用し、異なるプログラミング言語を使用することもできます。
マイクロサービス アーキテクチャとモノリシック アーキテクチャ
今日のソフトウェア開発分野では、主に 2 つのシステム アーキテクチャ スタイル、つまり、新興の「マイクロサービス アーキテクチャ」と従来の「モノリシック アーキテクチャ」が存在します。
モノリシック アーキテクチャは、マイクロサービス アーキテクチャが登場する前の業界で最も古典的なタイプのソフトウェア アーキテクチャであり、初期のプロジェクトの多くもモノリシック アーキテクチャを採用していました。モノリシック アーキテクチャでは、同じプロジェクト内のアプリケーション内のすべてのビジネス ロジックを記述し、最終的にそれをコンパイル、パッケージ化して、サーバー上で実行できるようにデプロイします。
プロジェクトの初期段階では、モノリシック アーキテクチャには、開発速度と運用保守の難易度の点で明らかな利点があります。ただし、ビジネスの複雑さが継続的に改善されるにつれて、モノリシック アーキテクチャの多くの欠点が徐々に明らかになり、主に次の 3 つの側面が挙げられます。
- ビジネスの複雑化に伴い、モノリシックアプリケーション（モノリシックアーキテクチャを採用したアプリケーション）のコード量も増大し、コードの可読性、保守性、スケーラビリティが低下しています。
- ユーザーが増えるにつれて、プログラムの同時実行性はますます高くなっていますが、高い同時実行性を処理する単一のアプリケーションの能力には限界があります。
- モノリシック アプリケーションはすべてのサービスを同じプロジェクトに集中させるため、サービスの変更または追加が他のサービスに一定の影響を与える可能性があり、その結果テストの難易度が高くなります。
モノリシック アーキテクチャのこうした欠点のため、多くの企業や組織はプロジェクトをモノリシック アーキテクチャからマイクロサービス アーキテクチャに変換し始めています。
マイクロサービス アーキテクチャとモノリシック アーキテクチャの違いを比較してみましょう。
| 違い | マイクロサービスアーキテクチャ | モノリシックアーキテクチャ |
|---|---|---|
| チームの規模 | マイクロサービス アーキテクチャでは、従来のモードの単一アプリケーションを複数の独立したサービスに分割でき、各マイクロサービスを独立して開発、デプロイ、保守できます。設計、開発、保守まで各サービスに必要なチーム規模が小さく、チーム管理コストが小さい。 | モノリシック アーキテクチャのアプリケーションでは、通常、巨大なアプリケーションを扱うために大規模なチームが必要となり、チーム管理のコストが高くなります。 |
| データの保存方法 | マイクロサービスが異なれば、異なるデータ ストレージ方法を使用できます。たとえば、あるものは Redis を使用し、あるものは MySQL を使用します。 | 単一アーキテクチャのすべてのモジュールは同じパブリック データベースを共有し、保存方法は比較的単一です。 |
| 導入方法 | マイクロサービス アーキテクチャ内の各サービスは、独立してデプロイでき、他のサービスとは独立してスケーリングできます。マイクロサービスベースのアーキテクチャを適切に導入すると、企業がアプリケーションをより効率的に導入できるようになります。 | モノリシック アプリケーションに対するすべての機能変更またはバグ修正には、アプリケーション全体の再デプロイメントが必要です。 |
| 開発モード | マイクロサービス アーキテクチャを使用したアプリケーション プログラムでは、異なるテクノロジや言語を使用して異なるモジュールを開発でき、開発モデルがより柔軟になります。 | モノリシック アプリケーションでは、すべてのモジュールが同じテクノロジと言語を使用する必要があり、開発モデルは限られています。 |
| 誤った隔離 | マイクロサービス アーキテクチャでは、障害が単一のサービスに分離され、システム全体の崩壊が回避されます。 | モノリシック アーキテクチャでは、コンポーネントに障害が発生すると、その障害がプロセス全体に伝播し、システムがグローバルに使用できなくなる可能性があります。 |
| プロジェクト構造 | マイクロサービス アーキテクチャは、単一のアプリケーションを複数の独立した小さなサービスに分割し、それぞれを独立して開発、展開、保守することができ、それぞれが特定のビジネス要件を満たすことができます。 | 単一アーキテクチャ アプリケーションの場合、すべてのビジネス ロジックが同じプロジェクトに集中します。 |
マイクロサービスの特徴
マイクロサービスには次のような特徴があります。
- サービスはビジネスに応じて分割されており、各サービスは通常、特定のビジネスのみに焦点を当てており、必要なコードの量が少なく、複雑さが低く、保守が容易です。
- 各マイクロサービスは、より少ないコードで個別に開発、デプロイ、実行できるため、起動と実行が高速になります。
- 設計、開発、テスト、保守まで各サービスに必要なチームは通常8～10名程度と小規模であり、チーム管理コストも少なくて済みます。
- モノリシック アーキテクチャのアプリケーションに変更がある限り、有効にするためにアプリケーション全体を再デプロイする必要がありますが、マイクロサービスはこの問題を完全に解決します。マイクロサービス アーキテクチャでは、マイクロサービスを変更した後、アプリケーション全体ではなく、サービスのみを再デプロイする必要があります。
- マイクロサービス アーキテクチャでは、開発者はプロジェクト ビジネスとチームの特性に基づいて、開発とデプロイに使用する言語とツールを合理的に選択でき、マイクロサービスごとに異なる言語とツールを使用できます。
- マイクロサービスは優れたスケーラビリティを備えています。ビジネスが拡大し続けると、マイクロサービスの量とコード量は急速に拡大します。そのとき、ビジネスに応じてマイクロサービスを再度分割することができます。また、ユーザー数や同時実行数が増加した場合には、マイクロサービスをデプロイすることもできます。クラスタ内で使用してシステムの負荷容量を増やします。
- マイクロサービスをコンテナー (Docker) と組み合わせて使用すると、迅速な反復、迅速な構築、迅速なデプロイメントを実現できます。
- マイクロサービスには優れた障害分離機能があり、アプリケーション内のマイクロサービスに障害が発生した場合、他のマイクロサービスに影響を与えたり、システム全体に障害を引き起こすことなく、現在のサービスで障害が分離されます。
- マイクロサービス システムには、リンクを追跡する機能があります。
マイクロサービスフレームワーク
マイクロサービス アーキテクチャはシステム アーキテクチャのスタイルと考え方であり、本当にマイクロサービス システムを構築したい場合は、マイクロサービス フレームワークのサポートが必要です。マイクロサービスの普及に伴い、多くのプログラミング言語が次々とマイクロサービスフレームワークをリリースしていますので、以下に簡単に列挙してみましょう。
Java マイクロサービス フレームワーク
市場には主に 5 種類の Java マイクロサービス フレームワークがあります。
- Spring Cloud: REST サービスに基づいてサービスを構築でき、アーキテクトが完全なマイクロサービス テクノロジーのエコロジカル チェーンを構築するのに役立ちます。
- Dropwizard: 高パフォーマンスの Restful Web サービスを開発するために、構成、アプリケーション メトリック、ロギング、運用ツールのすぐに使用できるサポートを提供します。
- Restlet: このフレームワークは RST アーキテクチャ スタイルに従っており、Java 開発者がマイクロサービスを構築するのに役立ちます。
- Spark: Java 8 および Kotlin を介したマイクロサービス アーキテクチャ アプリケーションの作成をサポートする、最高の Java マイクロサービス フレームワークの 1 つ。
- Dubbo: Alibaba がオープンソース化した分散型サービス ガバナンス フレームワーク。
Go言語マイクロサービスボックス
Go言語のマイクロサービスフレームワークは少なく、ロードバランシング、サービスディスカバリ、同期通信、非同期通信、メッセージエンコードなどの機能を備えたRPCフレームワークであるGoMicroが多く使われています。
Phyton マイクロサービス フレームワーク
Phyton のマイクロサービス フレームワークには、主に Flask、Falcon、Bottle、Nameko、CherryPy が含まれます。
NodeJS マイクロサービス フレームワーク
Molecular は、NodeJS で構築されたイベント駆動型のアーキテクチャであり、このフレームワークには、サービス レジストリ、動的サービス検出、ロード バランシング、フォールト トレランス、組み込みキャッシュなどの組み込みコンポーネントが含まれています。
SpringCloud+RabbitMQ+Docker+Redis+Search+Distributed、システム詳細な SpringCloud マイクロサービス テクノロジー スタック コース