マイクロサービスは、大規模なアプリケーションを、単純な API を通じて相互に通信する疎結合モジュールに分割する方法です。
![マイクロサービス アーキテクチャ: 長所と短所 - 1]()
最近、マイクロサービスについて話さないのは愚かな人だけです。これはますます人気が高まっています。モジュール式アーキテクチャ スタイルはクラウドベースの環境に特に適しているようで、人気が高まっています。詳細に入る前に、すべてを俯瞰してみましょう。したがって、マイクロサービスは、大規模なプロジェクトを、独立した疎結合の小さなモジュールに分割する方法です。独立したモジュールは、明確に定義された個別のタスクを担当し、シンプルでアクセス可能な API を通じて相互に通信します。言い換えれば、マイクロサービスは、複雑な、主に Web アプリケーションを設計するための異なるアーキテクチャ スタイルにすぎません。しかし、SOA (サービス指向アーキテクチャ) などの既存のアーキテクチャ ソリューションの何がそんなに悪いのでしょうか? SOA を使用して作成された最新のエンタープライズ ソリューションのほとんどは、非常にうまく動作するようです。これは、業界が最近直面しているいくつかの課題について話す絶好の機会かもしれません...簡単な例から始めましょう。Java で書かれた従来のアプリケーションを実行する必要があるとします。まずユーザー インターフェイスを開発し、次に UI と対話するいくつかのコンポーネントを含むビジネス ロジック層を開発し、最後に永続データベースにアクセスできるデータベース層を開発します。ここで、アプリケーションを実行したいという事実に従って、WAR/EAR/JAR を作成し、サーバー (JBoss、Tomcat、WebLogic など) にマウントします。これはオールインワンで行われるため、モノリシックなアプリケーションが得られます。これは、すべてのコンポーネントが 1 か所にあることを意味します。画像の例:
![マイクロサービス アーキテクチャ: 長所と短所 - 2]()
おそらく、皆さんはすでにこのアプローチに精通しており、使用したことがあると思いますが、この例を使用して、このアーキテクチャ ソリューションを使用すると開発者がどのような課題に直面することになるかを示すことが目的です。 モノリシック アプリケーション:課題への挑戦
![Java-университет]()
神のマイクロサービスが救いの手を差し伸べる アーキテクチャ ソリューションにおける最も重要な特性の 1 つはスケーラビリティです。初めてマイクロサービスを学んだとき、すべてが「The Art of Scalability」という本からの引用に非常に似ていることがわかりました。これは素晴らしい出発点であり、議論の場でもあります。この本では、3 次元のスケーラビリティ システムを説明する、いわゆる「スケーラビリティ キューブ」モデルを定義します。
![マイクロサービス アーキテクチャ: 長所と短所 - 3]()
ご覧のとおり、X 軸は「水平スケーリング」(モノリシック アーキテクチャでも利用可能であることがわかりました) を表し、Y 軸はさまざまなサービスコンポーネントを分離するという意味でのスケーリングを表します。Z 軸の概念は、データが分割され、アプリケーションがデータが存在する正確な場所にリクエストを送信するときに理解されます。つまり、それらはすべて 1 か所にあるわけではありません。Y 軸の考え方については、後で詳しく説明します。この軸は機能的分解を表します。この戦略では、さまざまな機能を独立したサービスとして考えることができます。したがって、すべてが完了した場合にのみアプリケーション全体をマウントすることで、開発者は個々のサービスを互いに独立してマウントでき、他のサービスがモジュールでの作業を完了するのを待たずに済みます。これにより、開発時間が短縮されるだけでなく、アプリケーション コンポーネントの残りの部分を気にすることなく、変更や再配線を行う柔軟性も得られます。この図を前のモノリシック図と比較してみましょう。
![マイクロサービス アーキテクチャ: 長所と短所 - 4]()
マイクロサービス: 利点 マイクロサービスの利点は、Amazon、Netflix、Ebay などのエンタープライズ開発者にこのアプローチの使用を開始させるのに十分であると思われます。モノリシック アーキテクチャ アプリケーションとは異なり、マイクロサービスは次のことを行います。
- アプリケーションが成長するにつれて、記述されるコードの量も増加し、アプリケーションを開くたびに開発環境に過負荷がかかる可能性があります。これは明らかに開発者の効率を低下させます。
- すべてを 1 か所にマウントする必要があるため、別のプログラミング言語への切り替えや他のテクノロジへの切り替えが大きな問題になります。たとえば、Java でアプリケーションを作成し、しばらくして Kotlin が登場し、Kotlin の方がクールで優れており、高速であると
宣伝されたため、Kotlin に書き直そうとしたとします。モノリシック アプリケーションでは、プロセス自体は言うまでもなく、リファクタリングについて考えるだけでも大きな苦痛を伴うことになります。現在、この方法で作成されたアプリケーションが数多くあり、そのコード行数は信じられないほどです。 - いずれかのコンポーネントが何らかの理由で動作を
停止すると、アプリケーション全体もクラッシュします。認証、支払い、履歴などのモジュールを備えた Web アプリケーションがあると想像してください。そして何らかの理由でそのうちの1つが壊れます。これはビジネスにとって、そして結果として開発者にとっては単なるショックです。 - モノリシック アプリケーションのスケーリングは、同じタイプの別のアプリケーションを起動することによってのみ実現できます。しかし、アプリケーション全体ではなく、1 つのコンポーネントのみをスケールする必要がある場合はどうなるでしょうか。どれだけの資源が無駄になるのでしょうか...
- これは、アプリケーションの開発プロセスとインストール プロセスに大きな影響を与える可能性があります。アプリケーションが大規模であればあるほど、開発者がアプリケーションをより小さな作業部分に分割できることがより重要になります。モノリシック アプリケーション内のすべてのモジュールは相互に接続されているため、開発者はこれらのモジュールを相互に独立して作業したりマウントしたりすることはできません。開発者は互いに依存しているため、開発時間が長くなります。
- コンポーネント障害の分離の向上: 単一のモジュールに障害が発生した場合でも、大規模なアプリケーションは効率的に実行し続けることができます。
- アプリケーションが 1 つのテクノロジー スタックにコミットする必要がなくなります。何らかのサービスで新しいテクノロジー スタックを試したい場合は、先に進んでください。依存関係はモノリシックなものよりもはるかに軽くなり、すべてをロールバックすることもはるかに簡単になります。1 つのアプリケーション内のコードが少ないほど、作業が簡単になります。
- 新入社員がサービスの機能を理解しやすくなります。
- 分散システムの開発は難しい場合があります。これは、すべてのコンポーネントが独立したサービスになったことを意味します。モジュール間で受け渡されるリクエストを非常に注意深く処理する必要があります。1 つのモジュールが応答せず、システムのクラッシュを避けるために追加のコードを作成する必要があるシナリオが考えられます。リモート呼び出しが遅延の影響を受けやすい場合、これはさらに困難になる可能性があります。
- 複数のデータベースとトランザクションの管理は非常に面倒な場合があります。
- マイクロサービス アプリケーションのテストは面倒な場合があります。モノリシック アプリケーションを使用すると、サーバー上で WAR/EAR/JAR アーカイブを実行し、それがデータベースに接続されていることを確認するだけで済みます。また、マイクロサービスでは、テストを開始する前に個々のサービスを開始する必要があります。
- アプリケーションのマウントは難しい場合があります。WAR コンテナほど簡単にマウントできない可能性がある複数のサービスに関する調整が必要になる場合があります。
GO TO FULL VERSION