Выделенного соединения между клиентами и сервером в обычных сценариях общения нет. Между ними обычно стоят лоад-балансеры (как L3, так и L4). Они балансируют запрос в определенный датацентр, затем как-то выбирают между всеми инстансами бэкенда (типично - по round robin). Для проверки доступности инстансов мы используем как пассивные, так и активные проверки.
При общении между микросервисами каждый из них тоже закрыт балансировщиком, и запросы идут через него, но тут есть нюансы. Иногда мы не хотим делать кросс-ДЦ запросы на этом этапе, а хотим ходить только внутри одного датацентра для уменьшения latency. А иногда вообще балансировщик выглядит лишним, если есть хороший service-discovery, то можно прикрутить клиентскую балансировку и ходить напрямую.
При этом для узкого класса задач у нас всетаки устанавливается прямое TCP-соединение между бэкендом и каким-то объектом. Например, в этот класс попадают все задачи по телеметрии самокатов, которые мы запустили этим летом.
Спасибо за коммент! Вижу, что вам уже ответил Денис Исаев.
Я уточнил в своей статье, что decimal конечно нужен, только когда начинается арифметика, и мы можем потерять в точности чисел при операциях с ними.
Вы правы, в самом API можно передавать число как число. В таких случаях надо помнить, что в коде бэкенда не стоит делать промежуточную десериализацию этого числа в float из-за неточности представления, нужно создавать decimal сразу из полученной строки. Можно посмотреть, почему так, на примере метода from_float тут: https://docs.python.org/3/library/decimal.html
Он конечно не совсем про идемпотентность - по ее определению подразумевается, что функция была вызвана с теми же самыми аргументами. Но все равно интересный кейс
Не очень понял, как конкретно смена http-метода помогает избежать этой ситуации.
Тут скорее нужен просто правильный код под капотом - например, безусловно перезаписывать старые данные, если новые отличаются.
Ну и конечно интересно сразу подумать про гонки - что в каком порядке вызывается, если параллельно пришло несколько разных параллельных запросов, и что делать с согласованностью данных.
Чтобы не думать об этом, параллельные запросы можно запрещать на уровне UI (блокирующий UI, запрет кросс-девайс запросов - проще, но не защищает от curl из консольки), либо более умно - через глобальный лок или через разбор случаев, атомарные операции над ресурсами (типично в продуктовой разработке - ресурс это БД) и проверки, что никакой другой запрос не успел параллельно поменять те же самые данные (тоже типично - на уровне SQL). Второй способ более сложен в разработке и понимании людьми вне контекста задачи, и часто бизнес-требования не такие строгие, допускается просто не переспрашивать фидбек, если не вышло единожды.
Если сервис внутренний, то проблема безопасности может быть не так критична.
Если внешний, то нужно хорошо взвесить, какой профит вы получаете и какие меры безопасности надо предпринять. Сверять чексумму, что клиент и алгоритм не модифицировали, считать все важные данные в приложении, запретив их внешнее изменение на уровне ОС и так далее
На самом деле это очень редкий кейс, на мой взгляд - обычно в нём сразу понятно, что по-другому никак не сделать. В обычных задачах я бы рекомендовал делать более простые вещи
На все сервисы у нас есть риалтайм мониторинги и графики с кодами ответов, потребляемыми ресурсами и другими метриками. Время реакции у них не больше 1 минуты - по ним мы оперативно можем замечать текущие проблемы.
Если нам хочется более подробной информации по работе сервиса - сервисы пишут логи, логи уезжают в Elasticsearch для оперативного поиска и хранятся там 2 дня. Для долгосрочного хранения и анализа больших объёмов они также архивируются на Mapreduce (в Яндексе есть свой, называется YT)
По эластику можно искать логи и что-то считать через UI - через Kibana.
Но для каких-то частотных сценариев у нас написан свой “микросервис логов” - он, например, умеет разархивировать логи с YT и заливать из обратно в эластик, позволяет быстро накликать фильтры (например логи по сервису, городу или заказу), склеивает и показывает логи в рамках одного запроса (простая реализация opentracing) и тд.
В статье я намеренно привожу такие именования - так проще воспринимается текст. Не нужно лишний раз думать во время чтения, идёт ли речь о сохранении или получении данных.
В целом API сильно упрощён, о чем я упомянул вначале. В Такси у нас в основном RESTfull API у всех микросервисов, но бывают и исключения - при разработке мы стараемся исходить из здравой логики.
Скорее всего в продакшене endpoint был бы таким, как вы предположили - POST /feedback
Выделенного соединения между клиентами и сервером в обычных сценариях общения нет. Между ними обычно стоят лоад-балансеры (как L3, так и L4). Они балансируют запрос в определенный датацентр, затем как-то выбирают между всеми инстансами бэкенда (типично - по round robin). Для проверки доступности инстансов мы используем как пассивные, так и активные проверки.
При общении между микросервисами каждый из них тоже закрыт балансировщиком, и запросы идут через него, но тут есть нюансы. Иногда мы не хотим делать кросс-ДЦ запросы на этом этапе, а хотим ходить только внутри одного датацентра для уменьшения latency. А иногда вообще балансировщик выглядит лишним, если есть хороший service-discovery, то можно прикрутить клиентскую балансировку и ходить напрямую.
При этом для узкого класса задач у нас всетаки устанавливается прямое TCP-соединение между бэкендом и каким-то объектом. Например, в этот класс попадают все задачи по телеметрии самокатов, которые мы запустили этим летом.
В дополнение к своему комменту приведу ссылку на хорошую вводную статью про балансировку: https://habr.com/ru/company/mailru/blog/347026/
Спасибо за коммент!
Вижу, что вам уже ответил Денис Исаев.
Я уточнил в своей статье, что decimal конечно нужен, только когда начинается арифметика, и мы можем потерять в точности чисел при операциях с ними.
Вы правы, в самом API можно передавать число как число. В таких случаях надо помнить, что в коде бэкенда не стоит делать промежуточную десериализацию этого числа в float из-за неточности представления, нужно создавать decimal сразу из полученной строки. Можно посмотреть, почему так, на примере метода from_float тут: https://docs.python.org/3/library/decimal.html
Хороший пример, спасибо
Он конечно не совсем про идемпотентность - по ее определению подразумевается, что функция была вызвана с теми же самыми аргументами. Но все равно интересный кейс
Не очень понял, как конкретно смена http-метода помогает избежать этой ситуации.
Тут скорее нужен просто правильный код под капотом - например, безусловно перезаписывать старые данные, если новые отличаются.
Ну и конечно интересно сразу подумать про гонки - что в каком порядке вызывается, если параллельно пришло несколько разных параллельных запросов, и что делать с согласованностью данных.
Чтобы не думать об этом, параллельные запросы можно запрещать на уровне UI (блокирующий UI, запрет кросс-девайс запросов - проще, но не защищает от curl из консольки), либо более умно - через глобальный лок или через разбор случаев, атомарные операции над ресурсами (типично в продуктовой разработке - ресурс это БД) и проверки, что никакой другой запрос не успел параллельно поменять те же самые данные (тоже типично - на уровне SQL). Второй способ более сложен в разработке и понимании людьми вне контекста задачи, и часто бизнес-требования не такие строгие, допускается просто не переспрашивать фидбек, если не вышло единожды.
Да, вы правы
Если сервис внутренний, то проблема безопасности может быть не так критична.
Если внешний, то нужно хорошо взвесить, какой профит вы получаете и какие меры безопасности надо предпринять. Сверять чексумму, что клиент и алгоритм не модифицировали, считать все важные данные в приложении, запретив их внешнее изменение на уровне ОС и так далее
На самом деле это очень редкий кейс, на мой взгляд - обычно в нём сразу понятно, что по-другому никак не сделать. В обычных задачах я бы рекомендовал делать более простые вещи
Спасибо за вопрос!
На все сервисы у нас есть риалтайм мониторинги и графики с кодами ответов, потребляемыми ресурсами и другими метриками. Время реакции у них не больше 1 минуты - по ним мы оперативно можем замечать текущие проблемы.
Если нам хочется более подробной информации по работе сервиса - сервисы пишут логи, логи уезжают в Elasticsearch для оперативного поиска и хранятся там 2 дня. Для долгосрочного хранения и анализа больших объёмов они также архивируются на Mapreduce (в Яндексе есть свой, называется YT)
По эластику можно искать логи и что-то считать через UI - через Kibana.
Но для каких-то частотных сценариев у нас написан свой “микросервис логов” - он, например, умеет разархивировать логи с YT и заливать из обратно в эластик, позволяет быстро накликать фильтры (например логи по сервису, городу или заказу), склеивает и показывает логи в рамках одного запроса (простая реализация opentracing) и тд.
Спасибо за вопрос!
В статье я намеренно привожу такие именования - так проще воспринимается текст. Не нужно лишний раз думать во время чтения, идёт ли речь о сохранении или получении данных.
В целом API сильно упрощён, о чем я упомянул вначале. В Такси у нас в основном RESTfull API у всех микросервисов, но бывают и исключения - при разработке мы стараемся исходить из здравой логики.
Скорее всего в продакшене endpoint был бы таким, как вы предположили - POST /feedback