Десятая серия Go gRPC: отслеживание распределенных ссылок gRPC+Zipkin

Go

Привет всем, я Jianyu.В практических приложениях вы сделали так много серверов и написали N методов RPC. Хотите увидеть метрики метода, но не с чего начать?

В этой статье мы создадим его с помощью gRPC + Opentracing + Zipkin.Система отслеживания распределенных ссылокдля просмотра связи, производительности и других показателей всей системы.

Opentracing

что

OpenTracing позволяет разработчикам легко добавлять (или заменять) реализации системы отслеживания, предоставляя независимые от платформы и поставщика API.

Но OpenTracing — это не стандарт. Потому что CNCF не является официальным органом по стандартизации, но его целью является создание большего количества стандартных API и инструментов для распределенной трассировки.

Глоссарий

Trace

Трассировка представляет выполнение транзакции или процесса в (распределенной) системе.

Span

Промежуток представляет собой единую единицу работы, выполняемую в распределенной системе. Также содержит «ссылки» на другие диапазоны, что позволяет объединить несколько диапазонов в полную трассировку.

Каждый интервал инкапсулирует следующее в соответствии со спецификацией OpenTracing:

  • Название действия
  • время начала и время окончания
  • key:value span Tags
  • key:value span Logs
  • SpanContext

Tags

Теги Span можно понимать как определяемые пользователем аннотации Span. Легко запрашивать, фильтровать и понимать данные трассировки

Logs

Журналы диапазона могут записывать информацию журнала для определенного времени или события в диапазоне. В основном используется для сбора информации журнала для определенного диапазона и других отладочных или информационных выходных данных из самого приложения.

SpanContext

SpanContext представляет состояние, которое передается через границы процесса дочерним промежуткам. Часто используется при создании контекста в диаграммах трассировки.

Baggage Items

Багажные единицы можно понимать как набор дополнительных данных, передаваемых в глобальной операции трассировки.

случай

image

На рисунке можно увидеть следующее:

  • контекст времени выполнения
  • Иерархические отношения между службами
  • Последовательное или параллельное связывание вызовов между службами

Комбинируя вышеуказанную информацию, в реальных сценариях мы можем узнать, где находятся болевые точки системы сразу через контекст, производительность и другую индикаторную информацию цепочки вызовов всей системы.

Zipkin

image

что

Zipkin — это распределенная система трассировки. Его роль заключается в сборе данных о времени, необходимых для устранения проблем с задержкой в ​​микросервисных архитектурах. Он управляет сбором и поиском этих данных.

Дизайн Зипкина основан наGoogle Dapperбумага.

бегать

docker run -d -p 9411:9411 openzipkin/zipkin

Другие способы установки см.GitHub.com/open zip kin/…

проверять

доступhttp://127.0.0.1:9411/zipkin/Проверьте, правильно ли работает Zipkin.

image

gRPC + Opentracing + Zipkin

В предыдущих разделах мы сделали следующие приготовления:

  • Узнайте, что такое Opentracing
  • Создание Zipkin для обеспечения функций распределенной системы трассировки

Затем внедрите gRPC для подключения к Zipkin через стандартный API Opentracing, а затем просмотрите данные через Zipkin.

Структура каталогов

Создайте новый каталог simple_zipkin_client и simple_zipkin_server.Структура каталогов выглядит следующим образом:

go-grpc-example
├── LICENSE
├── README.md
├── client
│   ├── ...
│   ├── simple_zipkin_client
├── conf
├── pkg
├── proto
├── server
│   ├── ...
│   ├── simple_zipkin_server
└── vendor

Установить

$ go get -u github.com/openzipkin/zipkin-go-opentracing
$ go get -u github.com/grpc-ecosystem/grpc-opentracing/go/otgrpc

gRPC

Server

package main

import (
	"context"
	"log"
	"net"

	"github.com/grpc-ecosystem/go-grpc-middleware"
	"github.com/grpc-ecosystem/grpc-opentracing/go/otgrpc"
	zipkin "github.com/openzipkin/zipkin-go-opentracing"
	"google.golang.org/grpc"

	"github.com/EDDYCJY/go-grpc-example/pkg/gtls"
	pb "github.com/EDDYCJY/go-grpc-example/proto"
)

type SearchService struct{}

func (s *SearchService) Search(ctx context.Context, r *pb.SearchRequest) (*pb.SearchResponse, error) {
	return &pb.SearchResponse{Response: r.GetRequest() + " Server"}, nil
}

const (
	PORT = "9005"

	SERVICE_NAME              = "simple_zipkin_server"
	ZIPKIN_HTTP_ENDPOINT      = "http://127.0.0.1:9411/api/v1/spans"
	ZIPKIN_RECORDER_HOST_PORT = "127.0.0.1:9000"
)

func main() {
	collector, err := zipkin.NewHTTPCollector(ZIPKIN_HTTP_ENDPOINT)
	if err != nil {
		log.Fatalf("zipkin.NewHTTPCollector err: %v", err)
	}

	recorder := zipkin.NewRecorder(collector, true, ZIPKIN_RECORDER_HOST_PORT, SERVICE_NAME)

	tracer, err := zipkin.NewTracer(
		recorder, zipkin.ClientServerSameSpan(false),
	)
	if err != nil {
		log.Fatalf("zipkin.NewTracer err: %v", err)
	}

	tlsServer := gtls.Server{
		CaFile:   "../../conf/ca.pem",
		CertFile: "../../conf/server/server.pem",
		KeyFile:  "../../conf/server/server.key",
	}
	c, err := tlsServer.GetCredentialsByCA()
	if err != nil {
		log.Fatalf("GetTLSCredentialsByCA err: %v", err)
	}

	opts := []grpc.ServerOption{
		grpc.Creds(c),
		grpc_middleware.WithUnaryServerChain(
			otgrpc.OpenTracingServerInterceptor(tracer, otgrpc.LogPayloads()),
		),
	}
    ...
}
  • zipkin.NewHTTPCollector: создает серверный сборщик HTTP Zipkin.
  • zipkin.NewRecorder: создает рекордер на основе сборщика Zipkin.
  • zipkin.NewTracer: создает трассировщик OpenTracing (совместимый с Zipkin Tracer).
  • otgrpc.OpenTracingClientInterceptor: возвращает grpc.UnaryServerInterceptor, разница в том, что этот перехватчик ищет OpenTracing SpanContext в метаданных gRPC. Дочерний элемент Span Context службы, если он найден
  • otgrpc.LogPayloads: установить и вернуть параметр. Роль заключается в том, чтобы позволить OpenTracing записывать полезную нагрузку приложения в обоих направлениях.

В общем, это инициализация Zipkin, который в свою очередь содержит сборщики, логгеры и трекеры. Затем используйте перехватчик для реализации двустороннего чтения и управления SpanContext и Payload на стороне сервера.

Client

func main() {
	// the same as zipkin server
	// ...
	conn, err := grpc.Dial(":"+PORT, grpc.WithTransportCredentials(c),
		grpc.WithUnaryInterceptor(
			otgrpc.OpenTracingClientInterceptor(tracer, otgrpc.LogPayloads()),
		))
	...
}
  • otgrpc.OpenTracingClientInterceptor: возвращает grpc.UnaryClientInterceptor. Основные функции этого перехватчика:

(1) OpenTracing SpanContext внедряет метаданные gRPC

(2) Проверьте контекстную связь в context.Context, если есть родительский диапазон, создайте ссылку ChildOf, чтобы получить дочерний диапазон.

В остальном это согласуется с серверной частью: сначала инициализируйте Zipkin, а затем добавьте перехватчик, специально необходимый для клиентской стороны. Просто сделайте основную работу

проверять

Запустите Server.go и запустите Client.go. Проверятьhttp://127.0.0.1:9411/zipkin/Схема:

image

image

сложный

image

image

Приходите и потренируйтесь сами.

Суммировать

В мультисервисной архитектуре очень распространены последовательные, параллельные и сервисные наборы, и часто трудно найти проблему с помощью традиционных решений (стоимость слишком высока). И этот случайРаспределенная система трассировкиПришло время размять мышцы

Я надеюсь, что благодаря введению и изучению этой главы вы сможете понять ее концепцию, а также построить и применить систему отслеживания.

?

Если у вас есть какие-либо вопросы или ошибки, добро пожаловать вissuesЗадавайте вопросы или вносите исправления, если вам нравится или помогаете, добро пожаловатьStar, является своеобразным поощрением и продвижением автора.

мой блог

Изучите го с жареной рыбой:GitHub.com/Vicious Genetics/Нет...

мой публичный аккаунт

image

Ссылаться на

Пример кода для этой серии