Comments 6
Можно еще добавить:
Добавьте трассировки чтобы отслеживать прохождение вашего запроса через набор микросервисов. Трассировки позволят найти узкое место или удивиться что вместо одного запроса вы шлете N.
Кроме retry еще посмотрите на circuit breaker, иначе, возможно, вы создадите ненужную нагрузку при сбое.
Сделайте включаемым сбор лога тела запросов/ответов, так как иногда нужны не только метрики времени и статусов, но и разбор причин ошибок. А постоянный лог не всегда нужен/возможен/добавляет тормоза.
Спасибо за дополнение.
По поводу трассировки да, хорошая идея изначально закладывать какой-то один идентификатор на протяжении всего запроса на уровне всего IT-ландшафта. Это тоже удобно можно внедрить в стандартизированный API-клиент
Да, хорошая практика, можно добавить доп.обработчики на специфичную ошибку для ответа о том что сервис временно недоступен из-за перегрузки.
Согласен. Это как раз можно решить передачей отдельного логгера в инициализацию API-клиента и передавать туда отдельный LOGLEVEL, который можно, при желании, переопределить через ENV-переменные.
Также на текущем месте работы мы используем "стандарт" JSONRPC что делает по сути очень удобным подключение новых микросервисов, путём настройки передаваемых параметров и названий "методов", и подключение к новым API можно почти прописывать в конфигурационный файл
В какой СУБД у вас хранятся логи запросов?
За какими графиками в графане вы следите в первую очередь?
Сами логи у нас хранятся в связке Elasticsearch/Kafka, вот в этой статье наши коллеги DevOPS подробно рассказали как реализовали мощный кластер логирования.
Касательно метрик запросов - их собирает Prometheus. За какими графиками следим - зависит от бизнес-задачи.
С точки зрения надёжности сервисов - в первую очередь смотрим на возрастающее количество ответов 4xx и 5xx, чтобы заблаговременно видеть возникающую деградацию и не допускать её развития в проблему клиентов.
Касательно энвов и именования - я б еще предложил всегда идти от общего к частному
т.е. SETTINGS_API_ENDPOINT_AUTH
вместоSETTINGS_AUTH_API_ENDPOINT
Дело, наверное, вкуса, но так при хранении разных энвов(кроме апи) в 1м месте по поиску найти все «нужные» проще будет
Best Practices по подключению к сторонним API в проекте