マイクロサービスとは何ですか?次のソフトウェアアーキテクチャ

ほぼすべてのコンピューターシステムは、共有リソースを使用して複数のタスクを実行します。コンピュータープログラミングの問題の1つは、それらのタスクを実行するコードのビットを互いにどの程度密接に結び付ける必要があるかです。ますます人気答えはmicroserviceの概念である-他のmicroservicesとの相互作用は、大規模なシステムを作成するために、その機能の小型、個別のチャンク。

このような個別のコンポーネントを持つという基本的な考え方は新しいものではありませんが、マイクロサービスの実装方法により、マイクロサービスは両方の最新のクラウドベースのアプリケーションの自然な基盤になります。マイクロサービスは、新しい機能を迅速かつ継続的に展開することを奨励するdevops哲学とも一致します。

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

マイクロサービスの「マイクロ」は、これらが小さなアプリケーションであることを意味します。それは時々真実ですが、それらについて考えるより良い方法は、特定のことをしたり、特定の問題を解決したりするのに必要なだけの大きさでなければならないということです。その問題は、技術的なものではなく、概念的なものでなければなりません。 Microsoftが述べているように、「マイクロサービスは、データアクセスやメッセージングなどの水平層ではなく、ビジネス機能を中心に設計する必要があります。」これらは、比較的安定したAPIを介して他のマイクロサービスや外部ユーザーと通信し、より大きなアプリケーションを作成します。

したがって、個々のマイクロサービスの内部機能は、システムの他の部分に影響を与えることなく、微調整または根本的にアップグレードできます。これは、DevOpsショップが運用しようとする方法につながります。大規模なアプリケーションの特定の機能が個別の独立して運用されるコードに分割されている場合、CI / CDのDevOpsマントラ(継続的インテグレーションと継続的デリバリー)を実行する方が簡単です。 。また、明確に定義されたAPIにより、マイクロサービスを簡単に自動的にテストできます。

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

「マイクロサービスアーキテクチャ」の観点からマイクロサービスが話題になっているのをよく耳にしますこのフレーズには、マイクロサービス自体だけでなく、管理とサービスディスカバリのコンポーネント、およびマイクロサービスと外界との間の通信を処理するAPIゲートウェイも含まれます。

「モノリシックアプリケーション」は、マイクロサービスとは逆です。これは、すべてのコードが1つの大きなバイナリ実行可能ファイルに含まれているアプリケーションのレトロニムです。TechTargetが説明しているように、モノリシックアプリケーションは拡張が難しく、改善も困難です。ただし、単一のまとまりのあるアプリケーションとして構築されているため、マイクロサービスアーキテクチャほど多くの管理は必要ありません。

制限された概念:マイクロサービスを定義する方法

マイクロサービスが1つの特定のことを実行する必要があるという以前の戒めに少し戻ってみましょう。言うのは簡単ですが、実際には、機能が絡み合っていることが多く、分割を描画するのは見た目よりも難しいです。ドメイン分析とドメイン駆動設計は、マイクロサービスが解決できる個々の問題に全体像のタスクを分解するのに役立つ理論的なアプローチです。このプロセスでは、マイクロソフトからのブログ記事の照明シリーズで概説し、あなたのビジネスドメインの抽象モデルを作成し、その過程で有界コンテキストを発見しどのグループのまとめ機能の特定の方法で、世界と相互作用すること。

たとえば、出荷用とアカウント用の1つの制限付きコンテキストがあるとします。もちろん、実際の物理オブジェクトには、価格と移動する必要のある場所の両方がありますが、制限されたコンテキストは、アプリケーションがそれらのオブジェクトについて考え、相互作用する特定の方法を表します。一部の制限付きコンテキストには複数のマイクロサービスが含まれる場合がありますが、各マイクロサービスは完全に単一の制限付きコンテキスト内に存在する必要があります。

マイクロサービスvs.サービス指向アーキテクチャvs.Webサービス

この時点で、あなたがしばらくの間業界に携わってきたITプロフェッショナルであれば、これの多くはなじみ深いと思うかもしれません。一緒に働いて小さな個々のプログラムのアイデアは、両方のSOA(サービス指向アーキテクチャ)を思い出させるし、Webサービスのかもしれない 2000年代の酔わせるようなWeb 2.0の日から2つの流行語。ある意味では、太陽の下ではまったく新しいものはありませんが、これらの概念とマイクロサービスの間には重要な違いがあります。 Datamationには違いの良い内訳がありますが、ここに短いバージョンがあります:

  • サービス指向アーキテクチャでは、個々のコンポーネントは比較的緊密に結合されており、多くの場合、ストレージなどの資産を共有し、エンタープライズストレージバスと呼ばれる特殊なソフトウェアを介して通信します。マイクロサービスはより独立しており、共有するリソースが少なく、より軽量なプロトコルを介して通信します。マイクロサービスはSOA環境から生まれたものであり、SOAの一種、またはこの概念の後継と見なされることもあります。
  • Webサービスは、他のアプリケーションがWeb経由でアクセスできる公開されている一連の機能です。おそらく最も一般的な例はGoogleマップです。これは、レストランのWebサイトに埋め込んで顧客に道順を提供することができます。これは、マイクロサービスアーキテクチャで見られるよりもはるかに緩い接続です。

マイクロサービス通信

マイクロサービスアーキテクチャについてよく耳にするキャッチフレーズは、「スマートエンドポイントとダムパイプ」を備えている必要があるということです。言い換えれば、マイクロサービスは、複雑で緊密な統合ではなく、基本的で確立された通信方法を使用することを目的とすべきです。前述のように、これはマイクロサービスとSOAを区別するもう1つのことです。

一般に、マイクロサービス間の通信は、コードスレッドが応答を待ってブロックされないという意味で、非同期である必要があります。(HTTPなどの同期通信プロトコルを使用することは問題ありませんが、AMQP(Advanced Message Queuing Protocol)などの非同期プロトコルもマイクロサービスアーキテクチャで一般的です。)この種の緩い結合により、マイクロサービスアーキテクチャは障害に直面してもより柔軟になります。個々のコンポーネントまたはネットワークの一部の、これは重要な利点です。

マイクロサービス、Java、SpringBootおよびSpringCloud

マイクロサービスの最初の作業のいくつかは、Javaコミュニティで発生しました。マーティンファウラーは初期の支持者でした。ポーランドで開催された2012年のJava会議では、「マイクロサービス-Java、Unix Way」というタイトルの、このテーマに関する最も重要な初期のプレゼンテーションの1つが取り上げられました。1970年代に最初のUnixアプリケーションの開発を導いた原則を適用することを推奨しました(「 1つのことを実行し、それをうまく実行するプログラム。Java開発に連携するプログラムを作成します。

この歴史の結果として、マイクロサービスの構築を可能にするJavaフレームワークがたくさんあります。最も人気のあるものの1つは、マイクロサービス用に特別に設計されたSpringBootです。ブートはSpringCloudによって拡張され、その名前が示すように、これらのサービスをクラウドにデプロイすることもできます。Springの開発者であるPivotalSoftwareには、これらのフレームワークを使用したマイクロサービス開発の開始に関する優れたチュートリアルがあります。

マイクロサービスとコンテナ:Docker、Kubernetesなど

マイクロサービスを主流にするために最も進んだ基盤となるテクノロジーはコンテナーです。 コンテナーはVMインスタンスに似ていますが、自己完結型のOS全体を含めるのではなく、コンテナーは、ホストオペレーティングシステムのカーネルを利用するが、それ以外の場合は自己完結型の内部でコードを実行し続ける、分離されたユーザースペースです。コンテナはVMインスタンスよりもはるかに小さく、ローカルまたはクラウドですばやくデプロイでき、需要と利用可能なリソースに合わせてスピンアップまたはスピンダウンできます。

マイクロサービスのコンテナーの魅力は明らかです。個々のマイクロサービスは独自のコンテナーで実行できるため、サービス管理のオーバーヘッドが大幅に削減されます。ほとんどのコンテナ実装には、コンテナベースのアプリケーションの展開、管理、スケーリング、ネットワーキング、および可用性を自動化する補完的なオーケストレーションツールがあります。 DevOpsの哲学を可能にするのは、小さくて構築しやすいマイクロサービスとデプロイしやすいコンテナーの組み合わせです。コンテナの概念にはいくつかの実装がありますが、最も人気のあるのはDockerで、これは通常、オーケストレーションプラットフォームとしてKubernetesとペアになっています。

Springは人気がありますが、Javaプラットフォームに関連付けられています。一方、コンテナベースのシステムは多言語です。OSがサポートするプログラミング言語はすべてコンテナ内で実行できるため、プログラマーの柔軟性が高まります。実際、マイクロサービスの大きな利点は、個々のサービスを最も意味のある言語で記述できること、または開発者が最も快適に記述できることです。実際、APIが安定している限り、システム全体に影響を与えることなく、サービスを新しい言語で完全に再構築できます。DZoneには、マイクロサービスにおけるSpringCloudとKubernetesの長所と短所について説明した記事があります。 

マイクロサービスのデザインパターン

マイクロサービスの開発に使用する言語に関係なく、他の開発者が以前に遭遇した問題に直面します。デザインパターンは、コンピュータサイエンスで繰り返し発生する問題に対する形式化された抽象的なソリューションであり、それらの多くは特にマイクロサービス向けです。Devopediaには、次のようなすばらしいリストがあります。

  • サービスレジストリ:クライアントをマイクロサービスの利用可能なインスタンスに接続するため
  • サーキットブレーカー:失敗したサービスが繰り返し呼び出されるのを防ぐため
  • フォールバック:失敗したサービスの代替手段を提供するため
  • サイドカー:ロギング、サービスの同期、監視など、メインコンテナに補助サービスを提供するため
  • アダプター:メインコンテナーと外部世界の間のインターフェースを標準化または正規化する
  • アンバサダー:ローカルホスト接続を外部接続にプロキシするなど、メインコンテナーを外部に接続します

マイクロサービスとクラウドAWSとAzure

上記のように、コンテナーを使用する利点の1つは、コンテナーをクラウドに簡単にデプロイできることです。クラウドでは、柔軟なコンピューティングリソースを利用できるため、アプリケーションの効率を最大化できます。ご想像のとおり、主要なパブリッククラウドベンダーはすべて、自社のプラットフォームを使用してマイクロサービスベースのアプリを実行することを熱望しています。詳細については、Amazon、Microsoft、およびGoogleのリソースを確認してください。