分散リンク トレーシング: Spring Cloud Sleuth に関する 9 つの致命的な質問

[[433789]]

この記事はWeChat公式アカウント「Mayuan Technology Column」から転載したもので、著者はChenです。この記事を転載する場合は、CodeApeテクノロジーコラム公式アカウントまでご連絡ください。

この記事では、Spring Cloud Sleuth と Zipkin という 2 つのコンポーネントに焦点を当てて、リンク トラッキングに関する知識をいくつか紹介します。次の記事でもう一つ紹介します。

記事のディレクトリは次のとおりです。

リンクトラッキングはなぜ必要なのでしょうか?

大規模な分散マイクロサービス システムでは、システムは N 個以上のモジュールに分割されます。これらのモジュールはさまざまな機能を担当し、最終的に豊富な機能を提供できるシステムに統合されます。この分散アーキテクチャでは、次の図に示すように、リクエストには複数のサービスが関係することがよくあります。

サービス間の呼び出しが複雑になり、メンテナンスコストが飛躍的に増加します。次のような問題が必ず発生します。

• サービス間の依存関係と依存関係を明確に把握するにはどうすればよいでしょうか?
• 異常が発生したときに、異常なサービスを迅速に特定するにはどうすればよいでしょうか?
• パフォーマンスのボトルネックが発生した場合、どのサービスが影響を与えているかを迅速に特定するにはどうすればよいでしょうか?

分散アーキテクチャにおける問題を迅速に特定するために、分散リンク トラッキングが誕生しました。分散要求をコールリンクに復元し、ログ記録、パフォーマンス監視を実行し、分散要求のコールステータスを集中的に表示します。たとえば、各サービス ノードで消費された時間、リクエストが到達したマシン、各サービス ノードのリクエスト ステータスなどです。

一般的なリンク追跡テクノロジーは何ですか?

市場には多くのリンク トラッキング プロジェクトがあり、次のような優れたプロジェクトもいくつかあります。

• cat: Dianping によってオープンソース化された、リアルタイム アプリケーション監視とビジネス監視を含む、Java ベースで開発されたリアルタイム アプリケーション監視プラットフォームです。統合ソリューションは、インターセプター、フィルターなどのコード追跡を通じて監視を実現することです。これはコードに非常に侵襲的であり、統合コストが高く、リスクも高くなります。
• Zipkin: Twitter によってオープンソース化されたオープンソースの分散トレース システムです。サービスのタイミング データを収集して、データの収集、保存、検索、表示など、マイクロサービス アーキテクチャのレイテンシの問題を解決するために使用されます。この製品は、spring-cloud-sleuth と組み合わせて使用​​するのが比較的簡単で、統合は非常に便利ですが、機能は比較的単純です。
• Pinpoint: バイトコード インジェクションに基づく韓国のオープン ソース コール チェーン分析およびアプリケーション監視および分析ツール。機能には、複数のプラグインのサポート、強力な UI、アクセス側でのコード侵入なしなどがあります。
• skywalking: SkyWalking は、バイトコード インジェクションに基づくローカル オープン ソースの呼び出しチェーン分析およびアプリケーション監視および分析ツールです。その機能には、複数のプラグインのサポート、強力な UI 機能、アクセス側でのコード侵入がない機能などがあります。現在はApacheインキュベータに参加しています。
• Sleuth: SpringCloud が提供する分散システム向けのリンク追跡ソリューション。残念ながら、Alibaba にはリンク トラッキングに関連するオープン ソース プロジェクトはありません。 Spring Cloud Sleuth+Zipkin を使用してリンク追跡ソリューションを提供できます。

Spring Cloud Sleuth とは何ですか?

Spring Cloud Sleuth は、分散サービス リンク追跡ソリューションを実装します。 Sleuth を使用すると、サービスの問題をすぐに見つけることができます。簡単に言えば、Sleuth は、各マイクロサービスに統合され、コール チェーン監視データを生成する役割を担うコール チェーン監視ツールのクライアントに相当します。

Spring Cloud Sleuth は、監視データを生成し、それをログの形式で表示する役割のみを果たし、視覚的な UI インターフェースは提供しません。

Sleuth を学習する前に、いくつかの概念を理解する必要があります。

• スパン: 作業の基本単位。リンク リスト内のノードに相当し、開始、特定のプロセス、終了を示す一意の ID を持ちます。そこに保存されている開始タイムスタンプと終了タイムスタンプを使用して、サービス呼び出しにかかった時間をカウントできます。また、イベント名やリクエスト情報なども取得できます。
• トレース: 直列に接続された一連のスパンで形成されるツリー構造。リクエストがシステムの入り口に到達すると、リンクを一意に識別するための一意の ID (traceId) が作成されます。この traceId は、リクエストが返されるまで常にサービス間で渡されるため、traceId を使用してリクエスト全体を連結し、完全なリンクを形成できます。
• 注釈: いくつかのコア注釈は、マイクロサービス呼び出し間のイベントをマークするために使用されます。重要なものは次のとおりです。
  • cs (クライアント送信): クライアントがリクエストを送信し、リクエストのライフサイクルを開始します。
  • sr (サーバー受信): サーバーがリクエストを受信して​​処理します。 sr-cs = ネットワーク遅延 = サービス呼び出し時間
  • ss (サーバー送信): サーバーは処理を完了し、クライアントに送信する準備ができました。 ss - sr = サーバー上のリクエスト処理時間
  • cr (クライアント受信): クライアントはサーバーからの応答を受信し、リクエストが終了します。 cr - sr = リクエストの合計時間

Spring Cloud は Sleuth とどのように統合されますか?

Spring Cloud Sleuth の統合は実際には難しくありません。その前に、次の 3 つのサービスを準備する必要があります。

• gateway-sleuth9031: ゲートウェイサービスとして
• sleuth-product9032: コモディティマイクロサービス
• sleuth-order9033: 注文マイクロサービス

3 つのサービスの呼び出し関係は次のとおりです。

クライアントはゲートウェイに注文照会要求を開始するように要求し、ゲートウェイはそれを注文サービスにルーティングし、注文サービスは注文の詳細を取得し、製品サービスを呼び出して製品の詳細を取得します。

依存関係の追加

次のようにして、親モジュールに sleuth 依存関係を追加します。

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

上記は Spring Cloud Sleuth の依存関係のみです。 Nacos と openFeign の依存関係については、ここでは詳しく説明しません。質問がある場合は、Chen の以前の記事やケース ソース コードを参照して、不明な点を補うことができます。

ログレベルの調整

sleuth には UI インターフェースがないため、コンソールでより詳細なリンク情報を表示するには、ログ レベルを調整する必要があります。

3 つのサービスの構成ファイルに次の構成を追加します。

 ## ログ情報を表示しやすくするために、openFeign と sleuth のログレベルをデバッグに設定します。
ログ記録:
レベル：
    org.springframework.cloud.openfeign: デバッグ
    org.springframework.cloud.sleuth: デバッグ

デモインターフェースの改善

次のインターフェースは作成されたデータのデモンストレーションのみを目的としており、DB とは統合されていません。

sleuth-order9033 の注文詳細を照会するためのインターフェースは次のとおりです。

sleuth-product9032 の製品詳細を照会するためのインターフェースは次のとおりです。

gateway-sleuth9031 ゲートウェイのルーティング構成は次のとおりです。

テスト

上記の 3 つのサービスを起動し、ブラウザに直接アクセスします: http://localhost:9031/order/get/12

以下に示すように、コンソール ログ出力を確認します。

ログ形式には 4 つのパラメータがあり、それぞれの意味は次のとおりです。

• 1: サービス名
• 2番目: traceIdはリンクを一意に識別します
• 3番目: spanId、リンク内の基本的な作業単位ID
• 4 番目: データを他のサービスに出力するかどうかを示します。 true の場合、情報は観察のために他の視覚化サービスに出力されます。 Zipkin はここに統合されていないため、誤りです。

さて、これで統合は完了です。思わず深呼吸してしまいます。ログを直接読むと目がくらんでしまいます…

ZipKinとは何ですか?

Zipkin は Twitter のオープンソース プロジェクトです。これは Google Dapper に基づいており、サービスのタイミング データを収集することに専念しています。

データの収集、保存、検索、表示を含むマイクロサービス アーキテクチャにおけるレイテンシの問題を解決します。

ZipKin の基本的なアーキテクチャは次のとおりです。

Zipkin は次の 4 つのコア コンポーネントに分かれています。

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

Zipkin はサーバーとクライアントに分かれています。サーバーは主に追跡データを収集して表示するために使用されます。クライアントの主な機能は、それをサーバーに送信することです。マイクロサービスのアプリケーションもクライアントです。呼び出しが発生すると、リスナーがトリガーされ、sleuth ログ データがサーバーに送信されます。

Zipkin サーバーを構築するにはどうすればいいですか?

まず、サーバーの jar パッケージをダウンロードする必要があります。アドレス: https://search.maven.org/artifact/io.zipkin/zipkin-server/2.23.4/jar

ダウンロードが完了すると、以下に示すように jar パッケージが取得されます。

次のコマンドでこの jar を直接起動します。

 java -jar zipkin-server-2.23.4- exec .jar

起動が完了したことを示す次のインターフェイスが表示されます。

この時点で、http://localhost:9411 で zipkin UI にアクセスできます。インターフェースは次のとおりです。

上記はjarをダウンロードしてサーバーを構築する方法です。もちろん、docker など他のインストール方法もあります。自分で試してみてください。チェンは再びそれを実演しないだろう。

zipKin クライアントを構築するにはどうすればいいですか?

サーバーはデータの収集と表示のみを追跡し、データを生成して送信するのはクライアントです。以下にクライアントの構築方法について詳しく紹介します。

上記の例の 3 つのマイクロサービスを引き続き使用して、次のように zipkin 依存関係を直接追加します。

 <! --リンク追跡 zipkin 依存関係 (Sleuth 依存関係を含む)-->  
 <依存関係>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-zipkin</artifactId>
 </依存関係>

注: Spring Cloud Sleuth の依存関係は spring-cloud-starter-zipkin にすでに含まれているため、上記の依存関係をインポートするだけで済みます。

構成ファイルでは、次のように Zipkin サーバーのアドレスを構成する必要があります。

春：
  雲：
  探偵:
    サンプラー：
      # ログデータのサンプリング率、デフォルトは 0.1 (10%) ですが、ここではテスト用に 100% に設定されており、実稼働環境では 0.1 のみが必要です。
      確率: 1.0
  ジプキン:
      #zipkin サーバーリクエストアドレス
    ベース URL: http://127.0.0.1:9411
      #nacos がサービス名ではなく URL として扱うようにします
    検出クライアントが有効: false  

上記の設定が完了したら、サービスを起動して次のサイトにアクセスします: http://localhost:9031/order/get/12

インターフェイスを呼び出した後、以下に示すように、再度 zipkin UI にアクセスします。

呼び出されたインターフェースが監視されていることがわかります。以下に示すように、[表示] をクリックすると詳細が表示されます。

左側にサービス名と時間消費を含む完全なリンクが表示され、右側に開始時間と終了時間、リクエスト URL、リクエスト方法など、サービス呼び出しの関連情報が表示されていることがわかります。

呼び出しリンクの関連情報に加えて、以下に示すように各サービスの依存関係も明確に確認できます。

zipKin のデータ転送モードを切り替えるにはどうすればいいですか?

zipkin のデフォルトの送信方法は HTTP ですが、ここで問題があります。送信プロセス中にクライアントとサーバーが切断されると、追跡ログ情報は失われます。

もちろん、Zipkin は MQ 送信もサポートしており、次のメッセージ ミドルウェアをサポートしています。

• アクティブMQ
• ラビットMQ
• カフカ

MQ 伝送を使用すると、メッセージ損失の問題を回避できるだけでなく、伝送効率も向上します。生産時には MQ 伝送が推奨されます。

それで、問題は、どうやって切り替えるかということです。

実際、その方法は非常に簡単です。 RabbitMQを例に紹介します。

1. サーバーがRabbitMQに接続する

次のコマンドを使用してサーバーを実行し、RabbitMQ に接続します。

 java -jar zipkin-server-2.23.4- exec .jar --zipkin.collector.rabbitmq.addresses=localhost --zipkin.collector.rabbitmq.username=guest --zipkin.collector.rabbitmq.password=guest  

コマンド分析は次のとおりです。

• zipkin.collector.rabbitmq.addresses: MQ アドレス
• zipkin.collector.rabbitmq.username: ユーザー名
• zipkin.collector.rabbitmq.password: パスワード

2. クライアントにRabbitMQを追加する

MQ 送信が使用されるため、対応する依存関係と構成を追加する必要があります。次のように RabbitMQ 依存関係を追加します。

 <依存関係>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-amqp</artifactId>
 </依存関係>

MQ アドレス、ユーザー名、およびパスワードを次のように設定します。

春：
  ウサギさん:
    アドレス: 127.0.0.1
    ユーザー名: ゲスト
パスワード: ゲスト

3. 設定ファイルで送信モードを切り替える

spring.cloud.zipkin.sender.type 構成は、送信モードを切り替えるために使用されます。値がrabbitの場合、データ転送にrabbitMQを使用することを意味します。

構成は次のとおりです。

春：
  雲：
  ジプキン:
    送信者:
     ## データ転送にrabbitMQを使用する
      タイプ: ウサギ

注: MQ トランスポートを使用する場合は、spring.cloud.zipkin.sender.base-url を削除できます。

完全な構成は次のとおりです。

4. テスト

MQ送信を使用しているため、サーバーを起動せずに正常に送信できます。ブラウザアクセス: http://localhost:9031/order/get/12

現時点では、サービスが例外を報告していないことが判明しました。 RabbitMQ では、データが送信され、以下に示すように zipkin キューに保存されます。

一部のメッセージが消費されていないことがわかります。それらをクリックすると、メッセージの内容がトレースおよびスパンに関連する情報であることがわかります。

では、次のコマンドでサーバーを起動しましょう。

 java -jar zipkin-server-2.23.4- exec .jar --zipkin.collector.rabbitmq.addresses=localhost --zipkin.collector.rabbitmq.username=guest --zipkin.collector.rabbitmq.password=guest  

サーバーの起動後、zipkin キュー内のメッセージが即座に消費されることがわかります。 Zipkin UI インターフェースを確認すると、次の図に示すように、リンク情報が生成されていることがわかります。

Zipkin はどのようにして存続するのでしょうか?

Zipkin の情報はデフォルトでメモリに保存されます。サーバーを再起動すると情報は失われますが、Zipkin はプラグ可能なストレージを提供します。

Zipkin は次の 4 つのストレージ方法をサポートしています。

• メモリ: サービスの再起動は失敗します。推奨されません
• MySQL: データ量が増えるとパフォーマンスが低下する
• Elasticsearch: 主流のソリューション、推奨
• カサンドラ：この技術は強力すぎるので、使う人はほとんどいません。自分で選んでください。でも公式に推奨されています。

今日、Chen は MySQL を例に使用して、Zipkin がどのように永続化されるかを紹介します。 Elasticsearchについては、少し長くなりますが、次の記事に掲載します。

1. データベースを作成する

Zipkin サーバーの MySQL テーブル作成 SQL は、ソース コードの Zipkin-storage/mysql-v1/src/main/resources/mysql.sql にあります。この SQL ファイルをケースのソース コードに配置します。

GitHub アドレス: https://github.com/openzipkin/zipkin/blob/master/zipkin-storage/mysql-v1/src/main/resources/mysql.sql

データベースを作成します: zipkin (任意の名前)、テーブル作成 SQL をインポートすると、新しく作成されたデータベース テーブルは次のようになります。

2. サーバー上でMySQLを設定する

サーバーの構成は非常に簡単です。次のコマンドを実行します。

 java -jar zipkin-server-2.23.4- exec .jar --STORAGE_TYPE=mysql --MYSQL_HOST=127.0.0.1 --MYSQL_TCP_PORT=3306 --MYSQL_DB=zipkin --MYSQL_USER=root --MYSQL_PASS=Nov2014  

上記のコマンドパラメータは次のように分析されます。

• STORAGE_TYPE: 保存方法、デフォルトのメモリ形式を指定します
• MYSQL_HOST: MySQL IP アドレス、デフォルトは localhost
• MYSQL_TCP_PORT: MySQL ポート番号、デフォルト ポート 3306
• MYSQL_DB: MySQLのデータベース名。デフォルトはzipkinです。
• MYSQL_USER: ユーザー名
• MYSQL_PASS: パスワード

チェンはこれらのパラメータをどうやって覚えたのでしょうか?もちろん彼はそれらを思い出せなかった。いつでもソースコードをチェックすることができました。これらの設定は、ソース コードの設定ファイル /zipkin-server/src/main/resources/zipkin-server-shared.yml にあります。たとえば、上記の MySQL 構成は次のようになります。

Zipkin サーバーのすべての設定項目はここにありますので、時間があれば確認してください。

GitHub アドレス: https://github.com/openzipkin/zipkin/blob/master/zipkin-server/src/main/resources/zipkin-server-shared.yml

次に、rabbitMQ 送信モードと MySQL 永続モードを使用します。完全なコマンドは次のとおりです。

 java -jar zipkin-server-2.23.4- exec .jar --STORAGE_TYPE=mysql --MYSQL_HOST=127.0.0.1 --MYSQL_TCP_PORT=3306 --MYSQL_DB=zipkin --MYSQL_USER=root --MYSQL_PASS=Nov2014 --zipkin.collector.rabbitmq.addresses=localhost --zipkin.collector.rabbitmq.username=guest --zipkin.collector.rabbitmq.password=guest  

永続化はサーバーが行うもので、クライアントとは関係がないので、私たちが行う必要があるのはそれだけです。これ以上テストはしないので、自分で試してください。

要約する

これまでもたくさん紹介してきました。注意深く読んだかどうかは分かりません。要約すると次のようになります。

• リンク トラッキング コンポーネントとして、Spring Cloud Sleuth はログ収集とログ印刷機能のみを提供し、視覚的な UI インターフェースはありません。
• Zipkinは、強力なログ追跡分析、視覚化、サービス依存性分析、その他の関連機能を提供し、Spring Cloud Sleuthと組み合わせて主流のソリューションとして機能します。
• Zipkinの実稼働環境では、MQ伝送モードに切り替えることを推奨しています。これには2つの利点があります。
  • データ損失の防止
  • MQ非同期分離によりパフォーマンスが大幅に向上

• Zipkin はデフォルトでデータをメモリに保存します。 MySQL もストレージ方式ですが、データ量が増えるとパフォーマンスが低下します。そのため、本番環境ではElasticsearchが推奨されており、次の記事で紹介します。