少し前まで、私は会議に参加する機会がありました。この会議では、レポートの1つが、新しい形式のマイクロサービスアーキテクチャプラクティスを使用した自動化のテストに当てられました。
このレポートのスライドの1つで、マイクロサービスアーキテクチャのマイナス面から、テストの複雑さが示されました。 ほとんどのソースでは、マイクロサービスアプリケーションのテストは実質的に言及されていないため、可能な場合はいつでもマイクロサービスアーキテクチャ（MSA）のテストの可能性を理解し、そのようなアプリケーションの設計段階で考慮すべきことを理解し、自分と隣人の生活を楽にする方法を理解したいという要望がありました。
マイクロサービス。 スタート。
インターネットで大騒ぎして、MSA（MicroService Architecture）とその兄SOA（Service Oriented Architecture）について、Habréを含む多くの情報を見つけました。 MSAの基本原則を簡単に示します。
- モジュール性。 アプリケーションは、完全なアプリケーションであるいくつかのサービスで構成されています
- 実装の独立。 サービスは、さまざまなテクノロジーを使用して、さまざまなプログラミング言語で実装できます。
したがって、多くの利点があります。
- 高い安定性。 たとえば、ソフトウェアエラーが原因でサービスの1つが失敗した場合、アプリケーション全体を再起動せずに、動作していないサービスをロールバックしたり、より安定した新しいバージョンをインストールしたりできます。
- さまざまな技術。 サービスは、アプリケーション全体に採用された1つのテクノロジーだけに限定されません。
- 独立した展開。 シンプルなサービスはデプロイが簡単で、失敗する可能性が低くなります。
そして欠点：
- さまざまなテクノロジーの可用性による開発の複雑さ。
- 営業時間は、サービスが互いに通信する方法に直接依存します。
次に、効果的なテストのためにマイクロサービスアーキテクチャの機能を最適に使用する方法を考えてみましょう。
「何が必要ですか？」
マイクロサービスアプリケーションを設計するとき、マイクロサービス同士の相互作用の問題が最前線になります。 なぜなら 各サービスは独自のプログラミング言語で記述でき、さまざまなテクノロジーを使用できるため、サービス間の通信を担当する追加のモジュールを開発する必要があります。
アプリケーションが比較的小さい場合は、RESTサポートで対応できます。RESTサポートは、相互作用に関係するサービスから直接送信できます。 これにより、アプリケーション全体のアーキテクチャが大幅に簡素化されますが、多大な情報転送コストが発生します（MSAアプリケーションを十分高速に動作させたい場合は、同期リクエストを使用しないでください！）。 かなり複雑なアプリケーションでは、マネージャーを作成せずにはできません。
単純なアプリケーションでも安定性を高めるには、メッセージマネージャを実装することをお勧めします。 そのようなマネージャは、あるサービスからの非同期リクエストを受け入れ、別のサービスに転送する必要があります。 ソケット、Webソケット、またはその他の便利なテクノロジーに実装できます。 リクエストはキューに保管するのが最適です。 このアプローチでは、一見したところではこれが必要ない場合でも、サービス間の相互作用を監視する簡単なツールが表示されます。
メッセージマネージャを作成することは、そのインターフェイスが標準であり、すべての製品サービスでサポートされることを意味します。 一方、さまざまなサービスにさまざまなメッセージングインターフェイスを使用すると、コードが不必要に複雑になります。 単一のインターフェースは、コーディングを開始する前にその設計の準備ができている必要があることも意味します。
「オレンジを共有しました...」
次に、MSAの基本的な考え方、つまり相互に比較的独立したサービスの相互作用を見てみましょう。
さらに、アプリケーション全体を再インストールすることなく、あるサービスを別のサービスに置き換える可能性に注目する価値があります。 欠点のうち、サービスはa）十分に小さく、b）非常に自律的である必要があります。
ここでの解決策は、コードをサービスに正しく分割することです。 さらに、機能（UI、ネットワーク、バックエンドコンピューティング、DB）によると、部門はマクロアプリケーションのようなものであってはなりませんが、たとえば、システムに入る要求の処理、販売レポートのコンパイル、データベースのデータに基づいたグラフのプロットなどのビジネスロジックによるものである必要があります このような機能的に完全なモジュールは完全に独立し、そのアプリケーションが明らかになります。 さらに、アプリケーションの一般的な機能を簡単かつ簡単に拡張または変更できます。
それをテストするには？
テストに関してマクロアプリケーションですべてが明らかだった場合、ここで何をする必要がありますか？ 多数のサービス、それぞれが他の多くのサービスを「プル」でき、データがサービス間でランダムに送信されます...悪夢です！ しかし、そうですか？
すべてが正しければ、次のようなアプリケーションがあります。
- 機能的に完全なサービスのセットで構成されます
- サービス間の相互作用は、メッセージマネージャーを介して発生します
- メッセージインターフェイスは、すべてのサービスで標準です。
手動テストの観点から見ると、各サービスを個別に操作することは大きな頭痛の種です。 しかし、なんと自動化の範囲です！
まず、ロガーをメッセージマネージャーに接続して、各サービスの明確でわかりやすいログを取得し、サービス間の相互作用も透過的になります。 そのため、問題のあるサービスをすばやく特定し、必要に応じてロールバックできます。 WEBアプリケーションの場合、発生した問題をリアルタイムで通知する監視を実装することができます。
なぜなら 標準のメッセージ間隔があり、各サービスに個別に適応する必要はありません。たとえば、同じデータベースからの一連の既知の要求と応答を使用するだけで十分です。 そしてこれは非常に愛されているDDT（データドリブンテスト、ロックバンドや農薬と混同しないでください！）、これは驚くべきスケーラビリティとパフォーマンスにつながります。
タスクの条件では、私たちが持っている各サービスは機能的に完全な独立したユニットです。 マクロアプリケーションの関数またはメソッドのように。 サービスごとに「ユニット」テストのセットが記述されている場合は論理的です。 引用符で囲んでいるのは、メソッドや関数ではなく、やや複雑な機能を持つサービスをテストしているためです。 繰り返しますが、ユーザーアクションをエミュレートする必要はまったくありません。正しいRESTリクエストを作成するだけで十分です。 この段落を実装した後、各サービスに対して受け入れテストが開発されたと言えます。 さらに、DDTはここでも頼みます。1つのテストが異なるサービスに適用され、入力/出力データセットのみが変更されます。
試験台
したがって、どこかで実行する必要のある信じられないほどの数のテストを非常に迅速に獲得しました。 当然、1台のサーバーでテストを実行するにはかなり時間がかかりますが、これは私たちにはまったく適していません。
WEBアプリケーションの場合、ソリューションは明らかです。起動ごとに個別に事前構成されたサーバーを展開できます。 これによりサーバーの負荷は軽減されませんが、テストされたサービスをサーバー間で共有できます。 テストされたサービスのみが新しいバグのソースになる制御された環境で起動が実行される場合、実行中のテストのセットを大幅に削減できます。 これは開発段階で非常に重要です-開発者が他のサービスとのやり取りで機能をテストする機会を得るとき、マシンでテストの完全なセットを起動することによって本当に気が散ることはありません。
この場合、完全な統合テストは、たとえば1日に1回、またはサービスに十分な数の変更がある場合に実行できます。
ローカルアプリケーションのテストも同じ方法で実行しますが、異なる仮想マシンで実行します。 そのためには、クラウドサービスを使用すると非常に便利です。 同時に、システムの展開に必要な時間を短縮するために、事前に定義されたツールのセットを使用して、すでに構成されたOSを事前に準備することができます。
結論
MSAは、開発とテストの両方にとって非常に興味深い柔軟なアーキテクチャです。 シンプルさと汎用性の適切なバランス、アプリケーションの構造の明確な理解により、最小限の労力で優れたパフォーマンスを得ることができます。
ただし、何らかの方向にバイアスをかけると、MSAが提供するすべての利点を失いつつ、メンテナンスが困難なコードのジャングルを掘り下げながら、アプリケーションの全体的なパフォーマンスを低下させることができます。
MSAアプリケーションのテストを効果的かつ効果的に自動化するには、開発チームと自動化チーム間の明確で緊密な相互作用が必要であることを理解することが重要です。
読むべきもの：
マイクロサービス
マイクロサービスアーキテクチャの長所と短所
マイクロサービス。 それを行う方法と適用する時期は？