マイクロサービスのチュートリアル: とは何か Archi構造と例

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

モノリシックとは Archi構造？

簡単に言えば、モノリシック アーキテクチャは、アプリケーションのすべてのソフトウェア コンポーネントが 1 つのパッケージにまとめられた大きなコンテナのようなものです。

モノリシック アーキテクチャのコンテキストにおける電子商取引ストアの例について説明しましょう。

どのeコマースアプリケーションにも、検索などの標準的な機能があります。 Rev顧客はブラウザやアプリを使ってこれらの機能にアクセスできます。eコマースサイトの開発者がアプリケーションを展開すると、それは単一のモノリシックユニットになります。検索、 Rev表示、評価、支払いは同じサーバー上にあります。アプリケーションを拡張するには、これらのアプリケーションの複数のインスタンス (サーバー) を実行する必要があります。

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

マイクロサービス間の通信は、リクエストとレスポンスの各ペアが独立したステートレス通信です。したがって、マイクロサービスは簡単に通信できます。マイクロサービスでは Archi構造上、データは統合されています。各マイクロサービスには個別のデータストアがあります。 Java マイクロサービス チュートリアルでは、マイクロサービスとモノリシック アーキテクチャの違いについて学習します。

マイクロサービス vs. モノリシック Archi構造

Microservices	一枚岩 Archi構造
アプリケーション全体の各単位は最小である必要があり、XNUMX つの特定のビジネス目標を達成できる必要があります。	すべてのビジネス目標に単一のコードベースで対応
サービスの起動が比較的早い	サービスの起動に時間がかかる
障害の切り分けは簡単です。 XNUMX つのサービスがダウンしても、他のサービスは機能し続けることができます。	障害の分離は困難です。特定の機能が動作していない場合、システム全体がダウンします。この問題に対処するには、アプリケーションを再構築し、再テストし、再デプロイする必要があります。
一方のマイクロサービスで行われた変更が他方に影響を与えないように、すべてのマイクロサービスは疎結合である必要があります。	モノリシックアーキテクチャは密に結合されています。コードの1つのモジュールの変更は他のモジュールにも影響を及ぼします。
企業は、より高い ROI を生み出すサービスに、より多くのリソースを展開できます。	サービスが分離されていないため、個別のリソース割り当ては不可能
頻繁に使用されるサービスには、より多くのハードウェア リソースを割り当てることができます。 上記の電子商取引の例では、支払いと比較して、商品リストをチェックして検索するユーザーの数が多くなります。 そのため、より多くのリソースを検索および製品リストのマイクロサービスに割り当てることができます。	アプリケーションのスケーリングは困難であると同時に無駄も伴います。
マイクロサービスは常に一貫性があり、継続的に利用可能です。	プロセスを最初から開始する必要があるため、開発ツールに過度の負担がかかります。
データはフェデレーションされます。 これにより、個々のマイクロサービスは、そのニーズに最適なデータ モデルを採用できるようになります。	データは一元化されます。
集中力のある小規模チーム。 並行かつ迅速な開発	大規模なチームと多大なチーム管理努力が必要
XNUMX つのマイクロサービスのデータ モデルを変更しても、他のマイクロサービスには影響しません。	データモデルの変更はデータベース全体に影響します
明確に定義されたインターフェイスを使用して他のマイクロサービスと対話します。	適用されない
マイクロサービスはプロジェクトではなく製品に焦点を当てる原則に基づいて動作します	プロジェクト全体に重点を置く
コードベース間の相互依存関係はありません。 さまざまなマイクロサービスにさまざまなテクノロジーを使用できます。	ある機能またはプログラムは他の機能またはプログラムに依存します。

マイクロサービスの課題

• マイクロサービスは相互に依存しており、相互に通信する必要があります。
• モノリシック システムと比較すると、さまざまなシステムを使用して開発された監視対象のサービスが多くなります。 プログラミング言語.
• 分散システムであるため、本質的に複雑なモデルです。
• 異なるサービスには個別のメカニズムがあり、その結果、非構造化データ用に大量のメモリが必要になります。
• 連鎖的な問題を防ぐためには効果的な管理とチームワークが必要
• あるバージョンで問題が発生し、最新バージョンで問題が再発すると、問題を再現するのは困難になります。
• マイクロサービスを使用すると、独立したデプロイメントが複雑になります。
• マイクロサービス アーキテクチャでは、多くの操作オーバーヘッドが発生します。

• 新しいサービスがシステムに追加されるとアプリケーションの管理が困難になる
• 異種分散型マイクロサービスをサポートするには、幅広い熟練した専門家が必要です。
• マイクロサービスは、さまざまなビジネス タスクに応じてさまざまなサーバー スペースを維持する必要があるため、コストがかかります。

SOA 対マイクロサービス

SOA サービスは、ディレクトリ リストとして機能するレジストリによって組織内で維持されます。 アプリケーションは、レジストリ内のサービスを検索して、サービスを呼び出す必要があります。

別の世界で、 SOA 音楽監督が全員に指示を与えながら、各アーティストが自分の楽器で演奏するオーケストラのようなものです。

一方、マイクロサービスは、アプリケーションが 1 つのソフトウェアまたはアプリケーションではなく、さまざまな小規模なサービスの集合として構築されるサービス指向アーキテクチャ スタイルの一種です。

マイクロサービスは、それぞれのダンサーが独立していて、何をすべきかを知っている一座のようなものです。そのため、ステップを間違えても、正しいシーケンスに戻る方法を知っています。このマイクロサービス アーキテクチャ チュートリアルでは、SOA とマイクロサービスの違いについて学びましょう。

SOA とマイクロサービスの詳細な比較は次のとおりです。

	SOA	Microservices
デザインタイプ	SOA では、ソフトウェア コンポーネントはサービスの形式で使用するために外部の世界に公開されます。	マイクロ サービスは SOA の一部です。 SOAの実装です。
依存関係	ビジネスユニットは依存しています。	それらは互いに独立しています。
ソフトウェアのサイズ	従来のソフトウェアに比べてソフトウェアサイズが大きい	マイクロサービスではソフトウェアのサイズは常に小さい
テクノロジースタック	テクノロジー スタックはマイクロサービスに比べて低いです。	マイクロサービス テクノロジー スタックは非常に大規模になる可能性があります
アプリケーションの性質	本質的に一枚岩	自然の中でのフルスタック
独立性と集中力	SOA アプリケーションは、複数のビジネス タスクを実行するように構築されています。	これらは、単一のビジネス タスクを実行するように構築されています。
展開	導入プロセスには時間がかかります。	導入は簡単で、時間がかかりません。
費用対効果	よりコスト効率が高くなります。	Less 費用効果が高い。
拡張性	Less マイクロサービスと比較して。	高度にスケーラブル。
ビジネスの論理	ビジネス ロジック コンポーネントは単一のサービス ドメイン内に保存されます シンプルなワイヤ プロトコル (XML JSON を使用した HTTP) API は SDK/クライアントで駆動されます	ビジネス ロジックは、サービス間のレイヤーのようなエンタープライズ Service Bus のドメイン全体に存在できます。 ミドルウェア

マイクロサービスツール

1) Wiremock: マイクロサービスのテスト

WireMock Web サービスのスタブ化およびモック化を行うための柔軟なライブラリです。特定のリクエストを受信したときに HTTP API によって返されるレスポンスを構成できます。マイクロサービスのテストにも使用されます。

リンクをダウンロード：http://wiremock.org/

2) ドッカー

Docker は、コンテナーを使用してアプリケーションを作成、デプロイ、実行できるオープン ソース プロジェクトです。 これらのコンテナを使用すると、開発者はアプリケーションを単一のパッケージとして実行できます。 これにより、ライブラリとその他の依存関係を XNUMX つのパッケージで配布できます。

リンクをダウンロード：https://www.docker.com/

3) ヒストリックス

Hystrix はフォールト トレランス Java ライブラリです。 このツールは、マイクロサービスなどの分散環境でリモート サービス、システム、サードパーティ ライブラリへのアクセス ポイントを分離するように設計されています。 障害が発生したサービスを隔離し、障害の連鎖的な影響を防ぐことで、システム全体を改善します。

リンクをダウンロード：https://github.com/Netflix/Hystrix

マイクロサービスのベスト プラクティス Archi構造

• マイクロサービスごとに個別のデータ ストア
• 同様の成熟度レベルのコードを維持します。
• マイクロ サービスごとに個別のビルド。
• 常に、重度の場合は無国籍として扱います。

製品概要

• マイクロサービスは、アプリケーションがさまざまな最小の独立したサービス ユニットの集合として構築されるサービス指向アーキテクチャ パターンです。
• マイクロサービス Archiテクチャーは、ビジネス ドメイン向けに開発された小さな自律的なサービスのコレクションとしてアプリケーションを構築できるアーキテクチャ開発スタイルです。
• モノリシックアーキテクチャは、アプリケーションのすべてのソフトウェアコンポーネントが1つのパッケージにまとめられた大きなコンテナのようなものです。
• マイクロサービスでは、アプリケーション全体のすべてのユニットが最小である必要があり、XNUMX つの特定のビジネス目標を達成できる必要があります。
• モノリシックアーキテクチャでは、コードベースが大きいと開発プロセス全体が遅くなることがあります。新しいリリースには数か月かかることがあります。コードのメンテナンスは困難です。
• 1 種類のマイクロサービス: 2) ステートレス XNUMX) ステートフル
• マイクロサービス Java お互いに依存し、お互いにコミュニケーションを取る必要があります。特定の機能とビジネスニーズを強調するのに役立ちます
• SOAとして略されるサービス指向アーキテクチャは、同期および非同期アプリケーションのための要求または応答設計モデルに基づく分散コンピューティングの進化形です。
• SOA では、ソフトウェア コンポーネントはサービスの形式で使用するために外部に公開されますが、マイクロ サービスは SOA の一部です。 SOAの実装です
• Wiremock、Docker、Hystrixは人気のマイクロサービスツールです