Комментарии 7
Отличная статья, спасибо. Хочется только дополнить — по умолчанию связи между микросервисами Jaeger не умеет строить (DAG — directed acyclic graph) — для этого на базу (elastic или cassandra) надо натравливать отдельную spark job (может быть запущена как standalone).

Спасибо за статью. Пригодится, чтобы начать этим заниматься

Как решаете проблему асинхронного взаимодействия между сервисами?
Т.е., например один сервис пишет в очередь MQ/базу данных, а другой читает. Как в этом случае пробрасываете контекст?

Почему взяли Jaeger а не OpenZipkin? Проводили ли какие-то сравнения?

Есть общий стандарт Opentrace

Стандарт называется OpenTracing
Как решаете проблему асинхронного взаимодействия между сервисами?

Пока в этом не было необходимости. Но сделать это можно в худшем варианте просто вручную положив spanID в само сообщение или в заголовки или метаданные сообщения, если есть возможность, а потом при чтении восстановить из него контекст.
В лучшем случае если какие-то готовые библиотеки, например для kafka, для rabbitmq вроде есть из коробки в спринговой обвязке.


Почему взяли Jaeger а не OpenZipkin?

Изначально услышали про jaeger и он вроде как делался смотря на zipkin и dapper и наверно в теории должен был решить какие-то их недостатки. Но на сколько я понимаю большой разницы между ними нет, и нам бы одинаково подошло и то и то. Jaeger написан на go, zipkin на java, мне ближе go (хотя в компании пишем на java).
Плюс сменить одно на другое при необходимости не очень сложно, так как весь код завязывается на opentracing-api а не на конкретную реализацию.

Скажите, а есть ли стандартное решение для продвинутого кеширования в микросервисах? Проблема такая: в один момент времени может поступить множество одинаковых запросов от разных других микросервисов. Принимающий микросервис понимает, что они одинаковые, выполняет только один запрос и возвращает его результат (через REST) всем тем, кто его запросил. Плюс хранит его некоторое время.

Сервис может отвечать заголовками, сколько можно кэшировать один или другой запрос. И если поставить между сервисом и вызывающей стороной nginx, то он может держать у себя кэш на основе этих заголовков. Для более продвинутого кэширования можно вместо nginx взять varnish

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

1 января 1999

Сайт

srgroup.ru

Численность

201–500 человек

Дата регистрации

7 февраля 2019

Блог на Хабре