マイクロサービスとは何ですか？マイクロサービスアーキテクチャの概要

はじめに

過去10年間で、アプリケーション開発は技術の進歩と消費者のニーズに対応するために急速に進化してきました。

従来の開発は1つの大きなコードチャンクに依存していましたが、今日のほとんどのアプリは複数のミニアプリケーションから構築されています。またはマイクロサービス 、それぞれがアプリの単一の機能を担当します。

これらが一緒になって、マイクロサービスアーキテクチャと呼ばれるシステムを形成します。

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

マイクロサービス 、またはむしろマイクロサービスアーキテクチャ は、アプリケーションの開発に使用されるシステムであり、シームレスで応答性の高いパフォーマンスを確保するために連携して動作する個々のサービスの選択に基づいて構築されています。

マイクロサービスアーキテクチャを使用してウェブアプリケーションを構築している場合は、それを個々の機能に分割し、それぞれを個別のアプリとして開発およびデプロイします。

すべてがマージされ、したがって相互に依存するモノリシック開発とは対照的に、マイクロサービスアーキテクチャは、自律コンポーネントの複数のモジュールで構成されます。これは、緩い結合のシステムに依存するアーキテクチャの一種です。。

注：緩い結合とは、要素が互いに気付かないが通信できるシステムを構築することです。

たとえば、eコマースWebサイトには、オンライン支払い、返品、ユーザープロファイルなど、さまざまなサービスが必要です。 Webサイトを作成するために、開発者はチームに分かれ、それぞれが使用中のマイクロサービスの1つを構築する責任があります。

マイクロサービスはどのように相互に通信しますか？

構造を理解すると、これらの個別のエンティティがどのように集まって1つの調和のとれたサービスまたはアプリケーションを作成するのか不思議に思うかもしれません。答えは、直接的で、高速で、完璧なコミュニケーションを確立することです。すべてのサービス間。したがって、マイクロサービスは APIを介して相互に通信します。

アプリケーションプログラミングインターフェース （ API ）は、モジュールが相互作用できるようにする各モジュラ機能のアクセスポイントです。マイクロサービスはこのインターフェースを使用して、他のモジュールからのリクエストを送信および応答します。

各マイクロサービスには、明確に定義されたAPIエンドポイントが必要です。（通信チャネルの一端）問い合わせのために常にアクセスできるようにします。ほとんどの場合、これらはステートレスな REST API 。明確に定義されたエンドポイントがないと、システムは必要な情報をどこで探すべきかわかりません。

したがって、DEVチームは、公式の標準とパターンを使用して、エンドポイントをチーム間で共有します。コラボレーションと明確なコミュニケーションを通じてRESTAPIを確立するのは彼らの責任です。

従来のアーキテクチャとマイクロサービスアーキテクチャの違い

マイクロサービスをよりよく理解するために、マイクロサービスを開発前に使用されていたシステム（モノリシックアーキテクチャ）と比較してみましょう。。

モノリシック建築 従来のサーバー側システムでは正常に機能しました。これらは、単一のアプリケーションに基づくシステムです。すべての機能は1つの構造に存在し、同じファイルシステムを使用し、同じサーバーと通信し、最終的には同じマシンにデプロイされます。

この種のアーキテクチャにより、開発者は、後で他の機能を追加するために必要な機能を構築するだけでよいため、アプリケーションをより高速に作成できます。また、プロセスにAPIが含まれていないため、パフォーマンスが向上しました。

Webアプリケーションの拡張に伴い、敏捷性と一貫した稼働時間が必要になりました。モノリシック建築には、これらの要求に追いつくにはあまりにも多くの障害がありました。

モノリシック建築の短所

これらのシステムには緊密な結合プロセスがあったため、コードに変更を加えると、アプリケーション全体のパフォーマンスが危険にさらされる可能性があります。機能は相互依存しすぎて、絶え間ない革新と適応を必要とする新しい技術の時代にはなりませんでした。

モノリシックアーキテクチャのもう1つの問題は、個々の機能を拡張できないことでした。成功するビジネスの重要な側面の1つは、消費者の要求に対応する能力です。当然、これらの要求はさまざまな要因に依存し、時間とともに変動します。

ある時点で、ビジネスは、増え続ける要求に対応するために、サービスの特定の機能のみを拡張する必要があります。モノリシックアプリでは、個々の要素をスケーリングすることはできず、アプリケーション全体をスケーリングする必要がありました。

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

マイクロサービスの導入により、モノリシック開発では解決できなかった多くの問題が解決されました。

1。柔軟性が高い

まず、マイクロサービスアーキテクチャは非常に柔軟性があります 。各マイクロサービスは独立しているため、プログラマーはさまざまな言語またはプラットフォームを使用してモジュールを構築できます。これらのモジュールは、APIのおかげで相互に通信できるようになります。

さらに、マイクロサービスを使用すると、組織はテクノロジースタックに長期的に取り組む必要がありません。したがって、開発者は常に最新のテクノロジーを使用できます。

2。再利用可能な機能モジュール

さらに、この機能により、開発者は機能モジュールを再利用できます。そしてそれらを他のアプリケーションに適用します。すでに洗練されたマイクロサービスを利用すると、会社のリソースが節約され、開発者は他のプロジェクトに集中できます。

3。変化に強い

もう1つの重要な機能は、システムが変更に対して非常に回復力があることです。 ゆるく結合されているため、アプリ内の機能はそれほど相互依存していません。開発者は、新しい機能を効率的に追加したり、既存の機能を変更したりできます。アプリケーション全体ではなく、1つのモジュールのコードを変更します。

4。スケーラブル

モノリシックアプリとは異なり、マイクロサービスはスケーリングに最適です。これらは、未使用のモジュールにお金を浪費することなく、アプリケーションが常に稼働していることを保証します。機能をさまざまなサーバーにデプロイするため、システムでは必要なリソースのみをスケーリングできます。

5。より速い開発サイクル

分散モデルでは、アプリはより小さなサービスに分割されます。組織がアジャイル開発を採用している場合、チームはそれをより簡単に更新し、開発サイクルをスピードアップできます。

ビジネスの観点からは、開発サイクルの高速化は、マイクロサービスによって導入された最大の改善の1つです。

6。透明モデル

たとえば、新入社員はコードをより簡単に理解して変更できます。これは、アプリが多数のサービスに分散されているという事実に基づいています。統合システム全体に取り組むよりも、一度に1つのマイクロサービスを処理する方が簡単です。

マイクロサービスの欠点

1。複雑さ

マイクロサービスアーキテクチャの最大の欠点は、その複雑さです。。モノリシックアプリケーションと比較して、新しく開発されたシステムには、より多くのコンポーネントがあります。これらのコンポーネント（マイクロサービス）は、それ自体で、システム内で問題なく機能する必要があります。

2。経費

このシステムはまた、より高価。サービスは複数のサーバーにデプロイされるため、アプリケーションはより多くのCPUとより多くのランタイム環境を必要とすることになります。さらに、絶え間ない通信が必要なため、マイクロサービスは多くのリモート呼び出しを行います。これらの要因とその他の要因が合算されるため、開発のための予算を増やす必要があります。

3。セキュリティ

マイクロサービスには、より高いセキュリティも必要です。対策。上記のように、サービスはAPIを介して相互に通信します。これは、彼らがネットワークを介して情報を交換することを意味し、これは常に潜在的な脅威です。このため、メンテナンスとアップグレードは完璧である必要があります。

4。パフォーマンス

アーキテクチャの複雑さも、そのパフォーマンスに影響します。。マイクロサービスには複数のJVM（Java仮想マシン）インスタンスとプロセス間通信が含まれているため、それらの効率はモノリシックアプリよりも遅くなる可能性があります。

PROS	短所
サービスの独立性。各サービスコンテナには独自のビジネスロジックがあり、単一のビジネス機能に重点を置いています。このアーキテクチャは、互いに独立した個々の展開可能なユニットをサポートします。	複雑なセットアップ。個人主義のため、システムのセットアップにはより多くの構成とリソースが必要であり、運用上のオーバーヘッドが発生します。
柔軟で機敏な展開。各マイクロサービスは、さまざまなテクノロジーを使用し、さまざまなスタックや製品で実行する機会を利用して、個別に拡張できます。	運用の複雑さ。マイクロサービスエコシステムを介したトランザクションのトラブルシューティング、デバッグ、およびトレースはより困難です。システムの問題に対処するには、高度な自動化が必要です。
フォールトトレラント。マイクロサービスは、自動的に復元できる疎結合ユニットです。これらのユニットは相互に依存していないため、開発者は必要に応じて各ユニットの可用性を高めることができます。	セキュリティリスク。分離されたサービスはフォールトトレラントですが、同じ機能によってユニット間のトランザクション中にセキュリティの問題が発生する可能性があります。
CI/CDをサポートします。マイクロサービスは独立してデプロイされるため、複数のインスタンスを同時に開発およびデプロイできます。したがって、ソフトウェアのリリースがより速く、より頻繁になります。	共依存インターフェース。サービスは、相互に依存するインターフェースを介して通信します。一方のインターフェースをもう一方のインターフェースを調整せずに変更することは不可能です。
新機能の追加を合理化します。他のサービスのパフォーマンスを損なうことなく、既存のサービスを変更したり、新しいサービスを追加したりすることで、新しい機能を簡単に追加できます。	パフォーマンスが低下します。モノリシックアプリケーションと比較すると、マイクロサービスは、その複雑なアーキテクチャとプロセス間通信のために、タスクを実行するためにより多くの時間を必要とします。

マイクロサービスを採用する際の課題

1。分散モデルの設計

マイクロサービスを採用するための最初の課題は、信頼性が高く持続可能なモデルを設計することです。。マイクロサービスは大まかに分散されたシステムを使用するため、複雑な設計になってしまう可能性があります。すべてのシステム依存関係を慎重に検討し、考慮する必要があります。

2。統合テスト

もう1つの課題は、統合とエンドツーエンドのテストです。テストはこれまで以上に困難になり、さらに重要になります。マイクロサービスは相互に通信およびサポートする必要があるため、すべてのサービスにバグがない必要があります。あるサービスのバグにより、別のサービスで致命的なエラーが発生する可能性があります。これが、マイクロサービスによる継続的テストが最も重要な理由です。

3。導入

それでも手動で展開している場合、チームは最初にプロセスの自動化に時間を費やす必要があります。分散モデルは複雑であるため、手動でのデプロイは非常に複雑になります。

4。監視とロギング

マイクロサービスを採用する組織は、一元化された監視およびロギングシステムを確立する必要があります。構成されていない場合、問題の特定とデバッグは不可能になります。

5。デバッグ

上記のすべての要因と、負荷分散や遅延などの他の複雑さのために、デバッグの問題 、分散システムでは、複雑です。どのアプローチが最も効果的かについての簡単な答えはありません。プロジェクトに最適なアプローチを見つけるまでには、確かに時間がかかります。

6。 その他の考慮事項

最後に、組織はマイクロサービスモデルを採用するように適応する必要があります。チームの作業方法と協力方法を変更する必要があります。企業文化の変化を推進して、チームがマイクロサービスに対応できるようにします。

マイクロサービスの例

Javaのマイクロサービス

さまざまな言語を使用してマイクロサービスを開発できます。ただし、 Java そのようなアーキテクチャでアプリケーションを構築するための最上位の選択肢の1つと今でも考えられています。

Javaでの開発に使用される複数のマイクロサービスフレームワークには、次のものがあります。

スプリングブート
Swagger
ジャージー
ドロップウィザード
JHipster
Vert.x
再生

さらに、マイクロサービスセットアップは、ワークフローで複数の機械学習フレームワークを使用できるため、機械学習（ML）環境をサポートするためによく使用されます。 TensorFlow、Apache Mahout、Apache Singaはすべて、Javaで使用されるMLフレームワークの例です。

フレームワークは、データフローを収集、集約、分析することで、結果を予測し、モデル間の比較を提供できます。

Dockerのマイクロサービス

Dockerは、マイクロサービスを構築するためのもう1つの優れたソフトウェアです。コンテナを使用して仮想環境を実行するため、プラットフォームではマイクロサービスを整理するいくつかの方法が可能です。

各コンテナは個別のサービス専用にすることができます。
単一のサービスを複数のコンテナに分割して、サービス内のプロセスを分離することができます。

コンテナーは、マイクロサービスを分離するための実用的な方法です。軽量で、展開可能で、さまざまなオペレーティングシステムやインフラストラクチャに拡張できます。

マルチコンテナーDockerアプリケーションを実行している場合、Docker Composeは、すべてのマイクロサービスの管理と構成に役立つツールです。これはすべて、単一の yamlで実行されます 単一の調整されたコマンドでコンテナの起動、実行、通信、およびクローズのタスクを実行します。

多数のDockerホストを備えたマルチコンテナーアプリケーションは、 Swarmなどのコンテナーオーケストレーションプラットフォームで管理するのが最適です。またはKubernetes。どちらのプラットフォームでも、それぞれに複数のサービスを備えたサーバーのクラスターを管理できます。それらの違いの詳細については、KubernetesとDockerSwarmの記事を参照してください。

以下は、統合システムでSwarmとComposeが連携してコンテナクラスターを管理する方法を示しています。