マイクロサービス スルース + zipkin --- リンク トラッキング + nacos 構成センター

目次

1. 分散リンク追跡

1.1. リンク追跡探偵の概要

1.2. 探偵を完了する方法

1.3. zipkin サーバー

2. 構成センター

2.1. 共通の設定センターコンポーネント

2.2. マイクロサービスクラスターは構成ファイルを共有します

2.2.1 リアルタイム更新 -- 構成センターのデータ

2.2.2. リアルタイム更新用の設定クラスを手動で作成する ---- 設定ファイルを更新する

2.3. 複数のマイクロサービスが構成を共有する


Microservice Gateway の記事に従って リンク トラッキングが拡張されました


1. 分散リンク追跡

大規模システムのマイクロサービス構築では、システムが多数のマイクロサービスに分割されます。これらのモジュールはさまざまな機能を担当し、システムに結合することで、最終的に豊富な機能を提供できます。このアーキテクチャでは、リクエストに複数のサービスが関与することがよくあります。インターネット アプリケーションは、さまざまなソフトウェア モジュールのセットに基づいて構築されています。これらのソフトウェア モジュールは、さまざまなチームによって開発され、さまざまなプログラミング言語を使用して実装され、複数の異なるデータにまたがる数千台のサーバーに展開される可能性があります。このアーキテクチャ形式にもいくつかの問題があることがわかります。

  • 問題を素早く見つけるにはどうすればよいでしょうか?
  • 故障の影響範囲はどのように判断するのでしょうか?
  • サービスの依存関係を整理するにはどうすればよいですか?
  • リンクのパフォーマンスの問題とリアルタイムの容量計画を分析するにはどうすればよいですか?

 

分散トレース (分散トレース) は、分散リクエストを呼び出しリンクに復元し、ログ記録を実行し、パフォーマンスを監視し、分散リクエストの呼び出しステータスを一元的に表示することです。たとえば、各サービス ノードの所要時間、リクエストがどのマシンに到着するか、各サービス ノード 200、500 のリクエスト ステータスなどです。

一般的なリンク追跡手法には次のようなものがあります。

  • catは Dianping によってオープンソース化されており、リアルタイム アプリケーション監視とビジネス監視を含む Java ベースで開発されたリアルタイム アプリケーション監視プラットフォームです。統合ソリューションは、インターセプター、フィルターなどのコード埋め込みによる監視を実装することです。これはコードに非常に侵入的であり、統合コストが高くなります。リスクはさらに大きくなります。
  • Zipkinは Twitter によってオープンソース化されており、オープンソースの分散追跡システムです。これは、データの収集、保存、検索、「グラフィック」の表示など、マイクロサービス アーキテクチャにおける遅延問題を解決するためにサービスのタイミング データを収集するために使用されます。この製品は、spring-cloud-sleuth と組み合わせて使用​​するのが比較的簡単で、統合が非常に便利ですが、機能は比較的シンプルです。
  • pinpoint Pinpoint は、韓国のオープンソースのバイトコード インジェクション ベースのコール チェーン分析およびアプリケーションの監視および分析ツールです。複数のプラグインをサポートし、UIが強力で、アクセス端末にコード侵入がないことが特徴です。
  • スカイウォーキング [将来的には企業での利用が増えるでしょう]
  • SkyWalking は、ネイティブのオープン ソースのバイトコード インジェクション ベースのコール チェーン分析およびアプリケーションの監視および分析ツールです。複数のプラグインのサポート、強力な UI 機能、アクセス端末でのコード侵入がないことが特徴です。現在、Apache Incubator に参加しています。 
  • Sleuth (ログには、各リンク上のすべてのノードと、これらのノードが配置されているマシンが記録されます。時間がかかります。)

SpringCloudが提供する分散システムにおけるリンクトラッキングソリューション。

注:探偵+ジップキン

 

1.1. リンク追跡探偵の概要

Spring Cloud Sleuth の主な機能は、分散システムで追跡ソリューションを提供することです。これは Google Dapper の設計を大きく取り入れています。まず Sleuth の用語と関連概念を理解しましょう。

トレース(完全なリンク -- 多くのスパン (マイクロサービス インターフェイス) を含む)

同じトレース ID を持つ一連のスパン (リンク全体) が直列に接続されて、ツリー構造を形成します。リクエスト追跡を実装するには、リクエストが分散システムのエントリ ポイントに到着すると、サービス追跡フレームワークはリクエストの一意の識別子 (つまり TraceId) を作成するだけで済み、同時にフレームワークは常にリクエストを渡し続けます。リクエスト全体が返されるまで分散システム値内を流れるときの一意の ID。次に、この一意の識別子を使用してすべてのリクエストを連結し、完全なリクエスト リンクを形成できます。

スパン

一連の基本的な作業単位を表します。各処理ユニットの遅延をカウントするために、リクエストが各サービス コンポーネントに到達したときに、その開始、特定のプロセス、および終了をマークするために一意の識別子 (SpanId) も使用されます。SpanId の開始タイムスタンプと終了タイムスタンプによって、スパンの呼び出し時間をカウントすることができ、さらにイベントの名前も取得できます。リクエスト情報などのメタデータ。

注釈

これを使用して、時間の経過に伴うイベント、内部で使用される重要なメモを記録します。

  • cs (Client Send) クライアントは、要求されたコマンドを開始するための要求を送信します。
  • sr (Server Received) サーバーがリクエストを受信して​​処理を開始します。 sr-cs = ネットワーク遅延 (サービス呼び出しの時間)
  • ss (サーバー送信) サーバーは処理後にクライアントに送信する準備ができています。 ss - sr = サーバーでのリクエストの処理時間
  • cr (Client Reveived) クライアントがサーバーから応答を受信し、リクエストが終了します。cr - cs = リクエストの合計時間

1.2. 探偵を完了する方法

マイクロサービスのログを記録する

(1) マイクロサービスによる sleuth へのアクセス

親プロジェクトに依存関係が導入される

 <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-sleuth</artifactId>
        </dependency>
    </dependencies>

実行ログ:

 

これらは呼び出しリンクに同じtraceIdを持ち、各モジュールには独自のspanIdがあります。このようにして、sleuthは同じtraceIdのspanIdによって連結されて、完全な呼び出しリンクを形成します。各spanIdの実行時間をログの時間で減算できれば良いという考え方。こうやってみると非常に面倒ですね。---- sleuth によって生成されたログを収集し、グラフィカルに表示するために使用されるコンポーネントはありますか。---ジップキン

1.3. zipkin サーバー

ジップキン公式サイト

まず最初に: zipkin サーバーをインストールして起動します。

1.jar パッケージをダウンロードします: アップロードするリソース

2.走る

3. ブラウザが zipkin サーバーにアクセスします

http://localhost:9411/zipkin

 

2 番目のこと: マイクロサービスが使用する zipkin サーバー アドレスを指定します。

1. マイクロサービスに zipkin 依存関係を導入する必要がある

親プロジェクトには依存関係が導入されています。

     <dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-starter-zipkin</artifactId>
     </dependency>

2. 各マイクロサービスで zipkin サーバーのアドレスを指定します

構成ファイルに以下を追加します。

#指定zipkin服务器的地址
spring.zipkin.base-url=http://localhost:9411/

欠点: zipkin を再起動すると、リンクも失われます。デフォルトでメモリ内に存在します

解決策: データベースに保存する

mysql データベースでリモート接続が許可されていることを確認してください。

CREATE TABLE IF NOT EXISTS zipkin_spans (
 `trace_id_high` BIGINT NOT NULL DEFAULT 0 COMMENT 'If non zero, this means the trace uses 128 bit traceIds instead of 64 bit', 
`trace_id` BIGINT NOT NULL, 
`id` BIGINT NOT NULL, 
`name` VARCHAR(255) NOT NULL, 
`parent_id` BIGINT, 
`debug` BIT(1), 
`start_ts` BIGINT COMMENT 'Span.timestamp(): epoch micros used for endTs query and to implement TTL',
`duration` BIGINT COMMENT 'Span.duration(): micros used for minDuration and maxDuration query' )
 ENGINE=InnoDB ROW_FORMAT=COMPRESSED CHARACTER SET=utf8 COLLATE utf8_general_ci;

ALTER TABLE zipkin_spans ADD UNIQUE KEY(`trace_id_high`, `trace_id`, `id`) COMMENT 'ignore insert on duplicate'; 
ALTER TABLE zipkin_spans ADD INDEX(`trace_id_high`, `trace_id`, `id`) COMMENT 'for joining with zipkin_annotations'; 
ALTER TABLE zipkin_spans ADD INDEX(`trace_id_high`, `trace_id`) COMMENT 'for getTracesByIds';
 ALTER TABLE zipkin_spans ADD INDEX(`name`) COMMENT 'for getTraces and getSpanNames';
 ALTER TABLE zipkin_spans ADD INDEX(`start_ts`) COMMENT 'for getTraces ordering and range';
CREATE TABLE IF NOT EXISTS zipkin_annotations (
 `trace_id_high` BIGINT NOT NULL DEFAULT 0 COMMENT 'If non zero, this means the trace uses 128 bit traceIds instead of 64 bit', 
`trace_id` BIGINT NOT NULL COMMENT 'coincides with zipkin_spans.trace_id', 
`span_id` BIGINT NOT NULL COMMENT 'coincides with zipkin_spans.id',
 `a_key` VARCHAR(255) NOT NULL COMMENT 'BinaryAnnotation.key or Annotation.value if type == -1', 
`a_value` BLOB COMMENT 'BinaryAnnotation.value(), which must be smaller than 64KB', 
`a_type` INT NOT NULL COMMENT 'BinaryAnnotation.type() or -1 if Annotation', 
`a_timestamp` BIGINT COMMENT 'Used to implement TTL; Annotation.timestamp or zipkin_spans.timestamp',
 `endpoint_ipv4` INT COMMENT 'Null when Binary/Annotation.endpoint is null', 
`endpoint_ipv6` BINARY(16) COMMENT 'Null when Binary/Annotation.endpoint is null, or no IPv6 address', 
`endpoint_port` SMALLINT COMMENT 'Null when Binary/Annotation.endpoint is null',
`endpoint_service_name` VARCHAR(255) COMMENT 'Null when Binary/Annotation.endpoint is null' )
 ENGINE=InnoDB ROW_FORMAT=COMPRESSED CHARACTER SET=utf8 COLLATE utf8_general_ci;
ALTER TABLE zipkin_annotations ADD UNIQUE KEY(`trace_id_high`, `trace_id`, `span_id`, `a_key`, `a_timestamp`) COMMENT 'Ignore insert on duplicate'; 
ALTER TABLE zipkin_annotations ADD INDEX(`trace_id_high`, `trace_id`, `span_id`) COMMENT 'for joining with zipkin_spans'; 
ALTER TABLE zipkin_annotations ADD INDEX(`trace_id_high`, `trace_id`) COMMENT 'for getTraces/ByIds'; 
ALTER TABLE zipkin_annotations ADD INDEX(`endpoint_service_name`) COMMENT 'for getTraces and getServiceNames';

ALTER TABLE zipkin_annotations ADD INDEX(`a_type`) COMMENT 'for getTraces';
 ALTER TABLE zipkin_annotations ADD INDEX(`a_key`) COMMENT 'for getTraces'; 
ALTER TABLE zipkin_annotations ADD INDEX(`trace_id`, `span_id`, `a_key`) COMMENT 'for dependencies job';
CREATE TABLE IF NOT EXISTS zipkin_dependencies ( 
`day` DATE NOT NULL, 
`parent` VARCHAR(255) NOT NULL, 
`child` VARCHAR(255) NOT NULL,
 `call_count` BIGINT ) 
ENGINE=InnoDB ROW_FORMAT=COMPRESSED CHARACTER SET=utf8 COLLATE utf8_general_ci; 
ALTER TABLE zipkin_dependencies ADD UNIQUE KEY(`day`, `parent`, `child`);

走る

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

 

2. 構成センター

考える:

  • (1) 各マイクロサービスは n 個のクラスターを構築する必要がある場合があります。このクラスター内のマイクロサービス構成は同じです。サービスの構成を変更する必要がある場合は、それぞれを変更する必要があります。
  • (2) 各マイクロサービスは同じ構成であってもよい。

アイデア: これをコンポーネントに与えて統合管理します。----構成センター

2.1. 共通の設定センターコンポーネント

アポロ

Apollo は、Ctrip がオープンソース化した分散構成センターです。構成の更新をリアルタイムで反映できること、グレースケールリリース機能をサポートすること、すべての構成に対してバージョン管理や操作監査などの機能を実行できること、オープンプラットフォーム API を提供することなど、多くの機能があります。そして、その情報も非常に詳しいです。 - - 非常に便利。

不満

Disconf は、Baidu がオープンソース化した分散構成センターです。Zookeeper をベースにしてリアルタイム通知を実現し、設定変更後にも有効です。

SpringCloud 構成

これは、Spring Cloud の構成センター コンポーネントです。Spring とシームレスに統合されており、非常に使いやすく、構成ストレージは Git をサポートしています<git は学習しませんでした>。ただし、視覚的な操作インターフェイスがなく、構成はリアルタイムでは有効にならないため、再起動または更新する必要があります。

ナコス

これは SpingCloud Alibaba テクノロジー スタックのコンポーネントであり、以前はサービス レジストリとして使用していました。実際、サービス構成の機能も統合されており、サービス構成センターとして直接使用できます。

nacos を構成センターとして使用します。nacos サーバーのインストールについて話す必要はありません。

2.2. マイクロサービスクラスターは構成ファイルを共有します

クラスター実稼働環境では、異なるサーバーにデプロイする必要があります。

(1) nacos 設定センターで設定ファイルを作成する必要があります

名前は次のようにする必要があります: マイクロサービス名.suffix

 

 

 (2) マイクロサービスのnacos設定で設定ファイルを使用する

親プロジェクトには依存関係が導入されています。

 <!--引入nacos配置中心的依赖-->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
        </dependency>

(3) Bootstrap.properties を使用する必要があります --- 外部構成ファイルの内容をロードするために使用されます

#为微服务定义名称----必须和配置中心的id相同
spring.application.name=qy165-product
#指定配置中心的地址
spring.cloud.nacos.config.server-addr=localhost:8848
#指定配置文件所在的组  默认DEFAULT_GROUP
spring.cloud.nacos.config.group=aaa
#指定配置文件的后缀名  默认properties
#spring.cloud.nacos.config.file-extension=yml

ProductController を変更する

テスト

 

 

2.2.1 リアルタイム更新 -- 構成センターのデータ

 

2.2.2. リアルタイム更新用の設定クラスを手動で作成する ---- 設定ファイルを更新する

 

 

2.3. 複数のマイクロサービスが構成を共有する

(1) 上記 2 つの構成クラスのパブリック コンテンツをパブリック構成ファイルに抽出します。

 

(2) マイクロサービスにパブリックファイルを導入させる

 

#引用额外公共的配置文件
spring.cloud.nacos.config.extension-configs[0].data-id=gg.properties
spring.cloud.nacos.config.extension-configs[0].group=aaa
spring.cloud.nacos.config.extension-configs[0].refresh=true

おすすめ

転載: blog.csdn.net/WQGuang/article/details/131775014