実際のPHPおよびGolangプロジェクトでのJaeger OpentracingおよびMicroservices

みなさん、こんにちは。私の名前はユーリ・ブイユロフです。CarPriceの開発をリードしています。 PHPとGolangのマイクロサービスにどのように、なぜ来たのかを簡単に説明します。 使用するもの、実稼働環境でのアプリケーションの計測および監視方法。 次に、サービスの透明性を提供する分散取引について説明します。

マイクロサービスが選ばれる理由

最近、マイクロサービスは非常に流行のトピックになっており、多くの人は、それが不要な場合でもマイクロサービスを望んでいます。 これはかなり滑りやすいパスであり、先にあるものを理解する必要があります。 私たちは、トレンドのためではなく、必然的に、私たちが直面しなければならないすべての困難を認識して、マイクロサービスに来ました。

当初、CarPriceは、外部委託された開発者が関与し、開発速度に重点を置いて、Bitrix上のモノリシックアプリケーションとして構築されました。 一定の期間、これは市場でのプロジェクトの成功した立ち上げにおいて重要な役割の1つを果たしました。

時間が経つにつれて、モノリスの安定した動作を維持することが不可能になりました-各リリースは、テスター、開発者、および管理者向けのテストに変わりました。 異なるプロセスが相互の正常な動作を妨げました。 たとえば、ワークフローの女の子は、完了したオークションのドキュメントの生成を開始できますが、その時点で、バックエンドのブレーキが原因でディーラーは通常交渉できませんでした。

私たちは変わり始めました。 ビジネスロジックの大部分は、個別のサービスで実行されました：物流、自動車の法的な法的清浄化サービス、画像処理サービス、検査と発行のための記録ディーラーのサービス、請求、入札の受け入れサービス、認証サービス、推奨システム、モバイルアプリケーションおよびリアクションアプリケーションのAPI。

何を書いているの

現時点では、ネットワークを介して通信するさまざまなテクノロジーに関する数十のサービスがあります。

基本的に、これらは特定のビジネス上の問題を解決する小さなLaravel（php）アプリケーションです。 このようなサービスはHTTP APIを提供し、管理Web UI（Vue.js）を備えている場合があります
Composerが提供するライブラリに共通コンポーネントを配置しようとします。 さらに、サービスは一般的なphp-fpmドッカーイメージを継承します。 これにより、更新時の頭痛が解消されます。 たとえば、ほぼすべての場所にphp7.1があります。

Golangで速度重視のサービスを作成します。
たとえば、jwt認証サービスはトークンを書き出して検証し、罪の管理者がオークションプラットフォームから切断した悪徳ディーラーをログアウトする方法も知っています。
賭けサービスはディーラーの賭けを処理し、それらをデータベースに保存し、イベントをrabbitmqとRT通知サービスに延期して送信します。

Golangのサービスでは、go-kitとgin / chiを使用します。
go-kitは、その抽象化、さまざまなトランスポートとメトリック用のラッパーを使用する機能に魅了されましたが、機能性と冗長性への愛に少し疲れるので、豊富なビジネスロジックを備えた首都ビルで使用します。
ジンとチーでは、簡単なhttpサービスを構築すると便利です。 これは、本番環境で小さなサービスを開始するための最小限の労力で迅速に行うのに最適です。 複雑なエンティティがある場合は、サービスをgo-kitに転送しようとします。

監視の進化

モノリスの時点では、newrelicで十分でした。 マイクロサービスの段階にジャンプしたため、サーバーの数が増え、経済的な理由でそれを放棄し、最悪の状態に急ぎました：Zabbix-鉄、ELK、Grafana、Prometheus-APM。



まず、ELKのすべてのサービスからnginxログを追加し、Grafanaでグラフを作成し、99パーセンタイルを台無しにしたリクエストのためにKibanaに行きました。

そして、ここで探求が始まりました-リクエストで何が起こっていたかを理解するために。
モノリシックアプリケーションでは、すべてがシンプルでした。PHPの場合、xhprofが使用されていたため、そこで何が起こっているのかを理解できました。 リクエストが複数のサービスを通過し、さらには異なるテクノロジーを使用するマイクロサービスでは、このトリックは機能しません。 どこかでネットワーク、どこかで同期要求または不良キャッシュ。

APIの遅いリクエストを見つけたとします。 コードによると、要求が3つのサービスに変換され、結果を収集して返すことが確立されました。 ここで、間接サイン（タイムスタンプ、要求パラメーター）に基づいて従属要求を見つけ、どのサービスが要求の遅延の原因であるかを理解する必要があります。 そのサービスが見つかった場合でも、メトリックまたはサービスログに移動してその理由を調べる必要があります。多くの場合、下位のサービスが迅速に機能し、結果の要求が遅くなります。 Vobschemはとても楽しいです。

そして、私たちはその時だということに気付きました-分散トレースが必要でした。

イェーガー、ようこそ！

動機：

• 異常の検索-99パーセンタイルがフレークされている理由（ネットワークタイムアウト、サービスドロップ、データベースのブロックなど）。
• 展開、サービス構成の変更、またはインスタンスの数の後の質量の問題（50または75パーセンタイル）の診断
• 分散プロファイリング-遅いサービス、コンポーネント、または機能を見つけます。
  リクエストステージの視覚化（ガント）-内部で何が起こっているかを理解できます

GoogleのDapperを思い出して、私たちはまず分散トレーディングの普遍的な標準であるOpentracingに行きました。 複数のトレーサーでサポートされています。 最も有名なのは、 Zipkin （Java）とAppdash （Golang）です。
しかし、最近、この標準をサポートする古いタイマーの中に、Uber Technologiesの新しい有望なJaegerが登場しました。 彼について話しましょう。

ベッケンド-ゴー
UI-React
ストレージ-Cassandra / Elasticsearch

もともとはOpenTracing標準の下で開発されました。
同じZipkinとは異なり、Jaegerモデルはキーと値のロギングをネイティブでサポートし、トレースはスパンツリーだけでなく、有向非循環グラフ（DAG）として提示されます。

さらに、最近ではLAのオープンソースサミットで、イェーガーは KubernetesやPrometheusなどの名誉あるプロジェクトと同等になりました。

建築

各サービスは、タイミングと追加情報をスパンに収集し、udpによって近くのjaeger-agentにスローします。 次に、それらをjaeger-collectorに送信します。 その後、トレースはjaeger-uiで利用可能になります。 of.sayteアーキテクチャは次のように表されます。

生産中のイェーガー

ほとんどのサービスはDockerコンテナーにデプロイされます。 ドローンはそれらを収集し、Ansibleを展開します。 残念ながら（いいえ）、k8、nomad、またはopenshiftのようなオーケストレーションシステムにまだ切り替えておらず、コンテナーはDocker Composeを実行しています。
jaegerと組み合わせた典型的なサービスは次のようになります。



実稼働環境でのJaegerのインストールは、いくつかのサービスとストレージのコレクションです。
→コレクター-サービスからスパンを受け取り、ストレージに書き込みます
→クエリ-ストレージからスパンを読み取るためのWeb UIとAPI
→ストレージ-すべてのスパンを保存します。 cassandraまたはelasticsearchを使用できます

ヴァージンおよびローカル開発の場合、 jaegertracing/all-in-one:latestメモリ内ストレージをjaegertracing/all-in-one:latestたJaeger jaegertracing/all-in-one:latestビルドを使用すると便利jaegertracing/all-in-one:latest

仕組み

このサービスは、タイミングに関する情報とメタリクエスト情報をスパンで収集します。 コンテキストを介してメソッド間でスパンが渡され、ヘッダーにコンテキストを挿入することでダウンストリームサービスが渡されます。



実証するために、uberチームはドライバー検索サービスでのトレースを示す良い例を用意しました： Hotrod

コードのように

まず、トレーサー自体を作成する必要があります

 import ( "github.com/uber/jaeger-client-go" "github.com/uber/jaeger-client-go/config" ... ) jcfg := config.Configuration{ Disabled: false, // Nop tracer if True Sampler: &config.SamplerConfig{ Type: "const", Param: 1, }, Reporter: &config.ReporterConfig{ LogSpans: true, BufferFlushInterval: 1 * time.Second, //    jaeger-agent,     LocalAgentHostPort: cfg.Jaeger.ReporterHostPort, }, } tracer, closer, err := jcfg.New( cfg.Jaeger.ServiceName, config.Logger(jaeger.StdLogger), ) 

ミドルウェアの追加（opentracing.TraceServer）-apiメソッドのルートスパンを作成します。 ネストされたスパンはすべてそれに関連付けられます。

 endpoint := CreateEndpoint(svc) // Middleware      api endpoint = opentracing.TraceServer(tracer, opName)(endpoint) 

さらに、着信要求のヘッダー（opentracing.FromHTTPRequest）からトレースの抽出コンテキストを抽出します。 したがって、私たちのサービスは、彼がリクエストのトレースのコンテキスト（Inject）を渡した場合、優れたサービスに関連付けられます。

 r.Handle(path, kithttp.NewServer( endpoint, decodeRequestFn, encodeResponseFn, //         context.Context append(opts, kithttp.ServerBefore(opentracing.FromHTTPRequest(tracer, opName, logger)))..., )).Methods("POST") 

次に、メソッドをインストルメントします。

 func (s Service) DoSmth() error { span := s.Tracing.StartSpan("DoSmth", ctx) defer span.Finish() // do smth return nil } 

さて、スパンの開始自体は次のようになります

 func (t AppTracing) StartSpan(name string, ctx context.Context) opentracing.Span { span := opentracing.SpanFromContext(ctx); if span != nil { span = t.Tracer.StartSpan(name, opentracing.ChildOf(span.Context())) } else { span = t.Tracer.StartSpan(name) } return span } 

以上です。 これで、サービスの動作をリアルタイムで監視できます。
（ 全体像 ）



たとえば、上の図では、ブレーキ要求が見つかり、半分の時間がサービス間のネットワークで消費され、残りの半分がデータベースの更新であることがわかりました。 すでにこれで作業できます。

ご清聴ありがとうございました。 このメモが役に立つことを願っています。Jaegerは、誰かがサービスの仕事に透明性をもたらすのを助けるでしょう。

便利なリンク

→ プロジェクトサイトの
→ リポジトリ
→ Opentracing Webサイト
→ 例