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

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

Microservices アプリケーションが様々な最小の独立したサービスユニットの集合として構築されるサービス指向アーキテクチャパターンです。 ソフトウェア工学 アプリケーションを、明確に定義されたインターフェースを持つ単一機能モジュールに分解することに重点を置いたアプローチです。これらのモジュールは、サービスのライフサイクル全体を所有する小規模なチームによって独立して展開および運用できます。

「マイクロ」という用語は、マイクロサービスの規模を指し、単一の開発チーム（5～10人の開発者）で管理できる規模である必要があります。この手法では、大規模なアプリケーションを最小の独立した単位に分割します。

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

分かりやすく言うと、モノリシックアーキテクチャとは、アプリケーションのすべてのソフトウェアコンポーネントを1つのパッケージにまとめた大きなコンテナのようなものです。ここでは、モノリシックアーキテクチャの例として、eコマースストアについて考えてみましょう。

一枚岩 Archieコマースアプリケーションの構造

どのeコマースアプリケーションにも、検索などの標準的な機能があります。 Rev検索、評価、支払いなどの機能。これらの機能は、ブラウザまたはアプリを使用して顧客がアクセスできます。eコマースサイトの開発者がアプリケーションをデプロイすると、それは単一のモノリシックユニットになります。検索、評価、支払いなどのさまざまな機能のコードは、 Revビューと評価、および支払いは同じサーバー上で動作します。アプリケーションの規模を拡大するには、これらのアプリケーションの複数のインスタンス（サーバー）を実行する必要があります。

マイクロサービスとは Archi構造？

マイクロサービス Archi構造 マイクロサービスは、ビジネスドメイン向けに開発された小さな自律的なサービスの集合としてアプリケーションを構築できるアーキテクチャ開発スタイルです。これは、疎結合のサービスコレクションとしてアプリケーションを配置するのに役立つ構造スタイルアーキテクチャのバリエーションです。 Archiアーキテクチャには、きめ細かいサービスと軽量のプロトコルが含まれています。

マイクロサービスアーキテクチャで開発されたeコマースアプリケーションの例を見てみましょう。このマイクロサービスアーキテクチャの例では、各マイクロサービスは単一のビジネス機能に焦点を当てています。検索、評価、 ReviewとPaymentはそれぞれ独自のインスタンス（サーバー）を持ち、互いに通信します。

Microservices Archi構造

モノリシックの中で Archi構造では、すべてのコンポーネントが単一のモジュールに統合されます。しかし、マイクロサービスでは Archi構造上、マイクロサービスは個々のモジュール（マイクロサービス）に分割され、それらが相互に通信します。これは上記のマイクロサービスの例に示されています。

マイクロサービス間の通信は、リクエストとレスポンスの各ペアが独立したステートレス通信です。したがって、マイクロサービスは簡単に通信できます。マイクロサービスでは Archi構造上、データは分散化されています。各マイクロサービスはそれぞれ独立したデータストアを持っています。

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

Microservices	一枚岩 Archi構造
アプリケーション全体の各単位は最小である必要があり、XNUMX つの特定のビジネス目標を達成できる必要があります。	すべてのビジネス目標に対応する単一のコードベース。
サービスの起動は比較的速い。	サービスの起動には時間がかかります。
障害の特定は容易です。たとえ一つのサービスが停止しても、他のサービスは引き続き機能します。	障害の特定は困難です。特定の機能に不具合が生じると、システム全体が停止してしまいます。この問題に対処するには、アプリケーションを再構築し、再テストし、再デプロイする必要があります。
すべてのマイクロサービスは疎結合であるべきであり、そうすることで一方のサービスで行われた変更が他方のサービスに影響を与えないようにする。	モノリシックアーキテクチャは密結合である。あるコードモジュールの変更は、他のモジュールにも影響を与える。
企業は、より高い投資対効果（ROI）を生み出すサービスに、より多くのリソースを投入することができる。	サービスは独立していないため、個別のリソース割り当ては不可能です。
利用頻度の高いサービスには、より多くのハードウェアリソースを割り当てることができます。上記のeコマースの例では、決済よりも商品一覧の確認や検索を行うユーザーが多いため、検索および商品一覧のマイクロサービスにより多くのリソースを割り当てることが可能です。	アプリケーションのスケーリングは困難であると同時に無駄も伴います。
マイクロサービスは常に一貫性を保ち、継続的に利用可能です。	開発ツールは、プロセスを最初からやり直す必要があるため、過負荷状態になる。
データは統合されています。これにより、個々のマイクロサービスは、それぞれのニーズに最適なデータモデルを採用できます。	データは一元化されます。
少人数で専門性の高いチーム。並行開発による迅速な開発。	大規模なチームと、相当なチームマネジメントの努力が必要となる。
XNUMX つのマイクロサービスのデータ モデルを変更しても、他のマイクロサービスには影響しません。	データモデルの変更はデータベース全体に影響を与えます。
明確に定義されたインターフェースを使用して、他のマイクロサービスと連携します。	適用できません。
マイクロサービスは、プロジェクトではなく製品に焦点を当てるという原則に基づいて機能します。	プロジェクト全体を重視する。
コードベース間の相互依存関係はありません。 さまざまなマイクロサービスにさまざまなテクノロジーを使用できます。	ある機能またはプログラムは他の機能またはプログラムに依存します。

マイクロサービスの課題

• マイクロサービスは互いに依存し合っており、互いに通信する必要がある。
• モノリシック システムと比較すると、さまざまなシステムを使用して開発された監視対象のサービスが多くなります。 プログラミング言語.
• 分散システムであるため、本質的に複雑なモデルです。
• 各サービスにはそれぞれ独自のメカニズムがあるため、非構造化データ用に大量のメモリが使用されることになる。
• 連鎖的な問題の発生を防ぐためには、効果的な管理とチームワークが不可欠である。
• あるバージョンでは発生しなかった問題が最新バージョンで再発する場合、その問題を再現するのは困難な作業となる。
• マイクロサービスでは、独立したデプロイメントは複雑になります。
• マイクロサービス アーキテクチャでは、多くの操作オーバーヘッドが発生します。
• システムに新しいサービスが追加されると、アプリケーションの管理が難しくなる。
• 多様な構成で分散されたマイクロサービスをサポートするには、幅広い分野の熟練した専門家が必要となる。
• マイクロサービスは、さまざまなビジネス タスクに応じてさまざまなサーバー スペースを維持する必要があるため、コストがかかります。

SOA 対マイクロサービス

SOA サービスは、ディレクトリ一覧として機能するレジストリによって組織内で管理されます。アプリケーションはレジストリでサービスを検索し、サービスを呼び出す必要があります。言い換えれば、 SOA 音楽監督が全員に指示を与えながら、各アーティストが自分の楽器で演奏するオーケストラのようなものです。

一方、マイクロサービスはサービス指向アーキテクチャの一種で、アプリケーションを単一のソフトウェアやアプリケーションではなく、複数の小さなサービスの集合体として構築します。マイクロサービスは、各ダンサーが独立していて、それぞれが何をすべきかを知っている劇団のようなものです。そのため、ステップを間違えても、正しい順番に戻る方法を知っています。以下に、SOAとマイクロサービスの詳細な比較を示します。

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

マイクロサービスツール

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

WireMock は、Webサービスのスタブ化とモック化のための柔軟なライブラリです。特定の要求を受信した際にHTTP APIから返されるレスポンスを設定できます。マイクロサービスのテストにも使用されます。

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

2) ドッカー

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

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

3) ヒストリックス

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

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

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

• 各マイクロサービスごとに個別のデータストアを用意する。
• コードの成熟度を同程度に保つ。
• マイクロサービスごとに個別にビルドします。
• 各サーバーは常にステートレスとして扱うべきです。

よくあるご質問