DarkSideF Apr 2 at 11:05

Best Practices по подключению к сторонним API в проекте

Medium

6 min

15K

Домклик corporate blogWebsite development*Designing and refactoring*API*Microservices*

Tutorial

+25

Comments 6

PaulIsh Apr 2 at 11:56

Можно еще добавить:

Добавьте трассировки чтобы отслеживать прохождение вашего запроса через набор микросервисов. Трассировки позволят найти узкое место или удивиться что вместо одного запроса вы шлете N.
Кроме retry еще посмотрите на circuit breaker, иначе, возможно, вы создадите ненужную нагрузку при сбое.
Сделайте включаемым сбор лога тела запросов/ответов, так как иногда нужны не только метрики времени и статусов, но и разбор причин ошибок. А постоянный лог не всегда нужен/возможен/добавляет тормоза.

DarkSideF Apr 2 at 14:37

Спасибо за дополнение.

По поводу трассировки да, хорошая идея изначально закладывать какой-то один идентификатор на протяжении всего запроса на уровне всего IT-ландшафта. Это тоже удобно можно внедрить в стандартизированный API-клиент
Да, хорошая практика, можно добавить доп.обработчики на специфичную ошибку для ответа о том что сервис временно недоступен из-за перегрузки.
Согласен. Это как раз можно решить передачей отдельного логгера в инициализацию API-клиента и передавать туда отдельный LOGLEVEL, который можно, при желании, переопределить через ENV-переменные.

Saidkomil Apr 4 at 12:23

Также на текущем месте работы мы используем "стандарт" JSONRPC что делает по сути очень удобным подключение новых микросервисов, путём настройки передаваемых параметров и названий "методов", и подключение к новым API можно почти прописывать в конфигурационный файл

dbashinsky Apr 4 at 18:40

В какой СУБД у вас хранятся логи запросов?

За какими графиками в графане вы следите в первую очередь?

DarkSideF Apr 4 at 18:47

Сами логи у нас хранятся в связке Elasticsearch/Kafka, вот в этой статье наши коллеги DevOPS подробно рассказали как реализовали мощный кластер логирования.

Касательно метрик запросов - их собирает Prometheus. За какими графиками следим - зависит от бизнес-задачи.

С точки зрения надёжности сервисов - в первую очередь смотрим на возрастающее количество ответов 4xx и 5xx, чтобы заблаговременно видеть возникающую деградацию и не допускать её развития в проблему клиентов.

joeberetta Apr 14 at 15:44

Касательно энвов и именования - я б еще предложил всегда идти от общего к частному

т.е. SETTINGS_API_ENDPOINT_AUTH вместоSETTINGS_AUTH_API_ENDPOINT

Дело, наверное, вкуса, но так при хранении разных энвов(кроме апи) в 1м месте по поиску найти все «нужные» проще будет