Spring Cloud はマイクロサービスアーキテクチャを構築します: 分散サービストラッキング (zipkin の統合)

前回の記事「分散サービストラッキング（Logstashの統合）」を通じて、ELKプラットフォームが提供する収集、保存、検索などの強力な機能を利用できるようになり、トラッキング情報の管理と利用が非常に便利になりました。ただし、ELK プラットフォームのデータ分析ディメンションでは、リクエストリンクの各段階での時間遅延が考慮されていません。多くの場合、リクエストリンクをトレースする理由の 1 つは、コールリンク全体の過度の遅延のボトルネックの原因を見つけること、または分散システムの遅延監視などの時間関連の要件を満たすことです。現時点では、ELK のようなログ分析システムはやや弱いようです。このような問題には、Zipkin を導入すると簡単に解決できます。

Zipkin の紹介

Zipkin は、Google Dapper をベースにした Twitter のオープンソースプロジェクトです。これを使用して、各サーバーのリクエストリンクの追跡データを収集し、提供される REST API インターフェイスを使用して追跡データを照会し、分散システムの監視プログラムを実装することで、システム内の遅延増加の問題を迅速に発見し、システムパフォーマンスのボトルネックの根本原因を見つけることができます。開発指向の API インターフェースに加えて、追跡情報を直感的に検索したり、リクエストリンクの詳細を分析したりするのに役立つ便利な UI コンポーネントも提供します。たとえば、一定期間内の各ユーザーリクエストの処理時間を照会できます。

上の図は、4 つのコアコンポーネントで構成される Zipkin の基本アーキテクチャを示しています。

コレクター: コレクターコンポーネント。主に外部システムから送信された追跡情報を処理し、この情報を Zipkin によって内部処理される Span 形式に変換して、その後の保存、分析、表示などの機能をサポートするために使用されます。
ストレージ: 主にコレクターが受信した追跡情報を処理するストレージコンポーネント。デフォルトでは、この情報はメモリに保存されます。このストレージ戦略を変更し、他のストレージコンポーネントを使用して追跡情報をデータベースに保存することもできます。
RESTful API: 主に外部アクセスインターフェイスを提供するために使用される API コンポーネント。たとえば、追跡情報をクライアントに表示したり、監視のために外部システムにアクセスしたりします。
Web UI: API コンポーネントに基づいて実装された UI コンポーネント、上位層アプリケーション。 UI コンポーネントを通じて、ユーザーは追跡情報を便利かつ直感的に照会および分析できます。

HTTP コレクション

Zipkin の統合は Spring Cloud Sleuth に自動構成でカプセル化されているため、簡単に導入して使用できます。 Sleuth と Zipkin の基本的な統合プロセスを詳しく見てみましょう。主に2つのステップに分かれています。

ステップ1: Zipkinサーバーを構築する

zipkin-server という名前の基本的な Spring Boot アプリケーションを作成し、次のように pom.xml に Zipkin Server の依存関係を導入します。

 <親>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <バージョン>1.5.10.RELEASE</バージョン>
  <相対パス/>
 </親>
 <依存関係>
  <依存関係>
    <groupId>io.zipkin.java</groupId>
    <artifactId>zipkin サーバー</artifactId>
  </依存関係>
  <依存関係>
    <groupId>io.zipkin.java</groupId>
    <artifactId>zipkin-autoconfigure-ui</artifactId>
  </依存関係>
 </依存関係>
 <依存関係管理>
  <依存関係>
    <依存関係>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-dependencies</artifactId>
        <version>ダルストン.SR5</version>
        <type>ポンポン</type>
        <scope>インポート</scope>
    </依存関係>
  </依存関係>
 </依存関係管理>

メインアプリケーションクラス ZipkinApplication を作成し、@EnableZipkinServer アノテーションを使用して次のように Zipkin Server を起動します。

 @EnableZipkinServer
 @SpringBootアプリケーション
パブリッククラス ZipkinApplication { 
 
公共 静的void main(String[] args) {
    SpringApplication.run(ZipkinApplication.class、引数);
  } 
 
 }

application.properties で、サービスポート番号を 9411 に設定するなどの簡単な構成を行います (クライアントが統合されている場合、自動構成によってポート 9411 に接続されるため、サーバーでポートが 9411 に設定されている場合、クライアントはこの構成を省略できます)。

 spring.application.name = zipkin-server
サーバーポート=9411

上記のプロジェクトを作成したら、それを起動して http://localhost:9411/ にアクセスします。 Zipkin 管理ページは次のように表示されます。

ステップ2: アプリケーション用のZipkinサービスを導入して構成する

Zipkin サーバーの構築が完了したら、追跡情報を Zipkin サーバーに出力するようにアプリケーションを構成する必要があります。以前実装した trace-1 と trace-2 を例として、次の変更を加えてみましょう。

以下に示すように、spring-cloud-sleuth-zipkin 依存関係を trace-1 と trace-2 の pom.xml に導入します。

 <依存関係>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-sleuth-zipkin</artifactId>
 </依存関係>

以下に示すように、trace-1 と trace-2 の application.properties に Zipkin Server の構成情報を追加します (zip-server アプリケーションでポートを 9411 に設定し、ローカルでデバッグする場合は、デフォルト値が http://localhost:9411 であるため、このパラメータは未構成のままにしておくこともできます)。

 spring.zipkin.base-url=http://localhost:9411

テストと分析

この時点で、Zipkin サーバーに接続するための基本的な作業はすべて完了しました。引き続き eureka-server、trace-1、trace-2 を起動し、いくつかのテスト実験を行って、その動作メカニズムを予備的に理解することができます。

まず、trace-1 インターフェース (http://localhost:9101/trace-1) にいくつかのリクエストを送信します。ログ内のトレース情報の最後の値が true の場合、トレース情報が Zipkin サーバーに出力されることを意味します。したがって、この時点で、Zipkin Server 管理ページに移動し、適切なクエリ条件を選択し、[トレースの検索] をクリックして、ログに表示されたトレース情報をクエリできます (ページの右上隅にある入力ボックスで、ログ内のトレース ID に従って検索することもできます)。次のページを参照してください。

以下の trace-1 エンドポイントをクリックすると、懸念されるリクエスト時間の消費など、Sleuth によって収集された詳細情報も取得できます。

ナビゲーションバーの [依存関係] メニューをクリックすると、追跡情報分析に基づいて Zipkin Server によって生成されたシステム要求リンク依存関係グラフも表示できます。

メッセージミドルウェアコレクション

Zipkin を統合する場合、Spring Cloud Sleuth は HTTP 経由でトレース情報を収集するだけでなく、メッセージミドルウェアを通じてトレース情報の非同期収集もカプセル化します。 Spring Cloud Stream を組み合わせることで、アプリケーションクライアントがトレース情報をメッセージミドルウェアに簡単に出力できるようになり、Zipkin サーバーはメッセージミドルウェアからこのトレース情報を非同期的に使用できるようになります。

次に、以前に実装した trace-1 および trace-2 アプリケーションと zipkin-server サーバーに基づいていくつかの変更を加え、メッセージミドルウェアを通じてトレース情報を収集します。変換は非常に簡単です。すぐに実装するには、プロジェクトの依存関係と構成ファイルにいくつかの調整を加えるだけです。以下では、クライアントとサーバーの変換について詳しく説明します。

ステップ1: クライアントのトレース1とトレース2を変更する

トレース情報を生成した後、trace-1 と trace-2 がサンプルレコードをメッセージミドルウェアに出力できるようにするには、以前に導入した spring-cloud-starter-sleuth 依存関係に加えて、Spring Cloud Stream に対する zipkin の拡張依存関係である spring-cloud-sleuth-stream と、Spring Cloud Stream に基づくメッセージミドルウェアバインダー依存関係も導入する必要があります。 RabbitMQ を例にとると、次の依存関係を追加できます。

 <依存関係>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-sleuth-stream</artifactId>
 </依存関係> 
 
 <依存関係>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-stream-rabbit</artifactId>
 </依存関係>

application.properties 構成の HTTP 実装で使用される spring.zipkin.base-url パラメータを削除し、実際の展開状況に応じて、メッセージミドルウェアの関連構成を追加します。たとえば、RabbitMQ に関する次の構成情報などです。

 spring.rabbitmq.host=ローカルホスト
spring.rabbitmq.port=5672
 spring.rabbitmq.ユーザー名=springcloud
 spring.rabbitmq.パスワード= 123456

ステップ2: zipkin-serverサーバーを変更する

zipkin-server サーバーがメッセージミドルウェアから追跡情報を取得できるようにするには、pom.xml でメッセージミドルウェアの収集とカプセル化のためのサーバー側依存関係 spring-cloud-sleuth-zipkin-stream を導入するだけで済みます。同時に、使用される特定のメッセージミドルウェアをサポートするために、メッセージミドルウェアのバインダー実装も導入する必要があります。たとえば、RabbitMQ を例にとると、依存関係に次のコンテンツを追加できます。

 <依存関係>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-sleuth-zipkin-stream</artifactId>
 </依存関係> 
 
 <依存関係>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-stream-rabbit</artifactId>
 </依存関係> 
 
 <依存関係>
    <groupId>io.zipkin.java</groupId>
    <artifactId>zipkin-autoconfigure-ui</artifactId>
 </依存関係>

spring-cloud-sleuth-zipkin-stream 依存関係は、メッセージミドルウェアからトレース情報を収集するためのコアカプセル化であり、メッセージミドルウェアを統合するためのコア依存関係、zipkin サーバーのコア依存関係、およびその他のよく使用される依存関係 (たとえば、データストレージを拡張するための依存関係、テストをサポートするための依存関係など) が含まれます。ただし、このパッケージは zipkin のフロントエンド依存関係 zipkin-autoconfigure-ui を導入しないことに注意してください。使いやすさのために、ここでも参照します。

テストと分析

上記の変換が完了したら、eureka-server、trace-1 および trace-2、zipkin-server の起動を継続し、RabbitMQ も実行状態であることを確認します。この時点で、RabbitMQ コントロールページに sleuth という名前のスイッチが表示されます。これは、zipkin メッセージミドルウェアコレクター実装で使用されるデフォルトのトピックです。

***、以前の検証方法を使用し、trace-1 インターフェースにいくつかのリクエストを送信します: http://localhost:9101/trace-1。サンプリングされたトレース情報がある場合 (デバッグ時に、各トレース情報を収集するために AlwaysSampler サンプリングメカニズムを設定できます)、RabbitMQ コントロールページでメッセージが sleuth exchanger に送信されたことを確認できます。同時に、zipkin サーバーの Web ページで対応するトレース情報を検索することもできます。これで、メッセージミドルウェアを使用してトレース情報を収集するタスクは完了です。

完全な例:

読者は、自分の好みに応じて、次の 2 つのリポジトリで trace-1 プロジェクトと trace-2 プロジェクトを表示することを選択できます。

Github: https://github.com/dyc87112/SpringCloud-Learning/

gitee: https://gitee.com/didispace/SpringCloud-Learning/

【この記事は51CTOコラムニスト「Zhai Yongchao」によるオリジナル記事です。転載の許可を得るには、51CTO を通じて著者に連絡してください。

この著者の他の記事を読むにはここをクリックしてください

<<: VMware が新たなエコシステムの構築に向けて Cloud Harbor を立ち上げ

>>: Aruba、モバイルファーストアーキテクチャを推進し、未来のインテリジェントデジタルワークプレイスを実現