Я еще в отпуске: температура +30, вода +26. Неожиданно, но отель прям очень понравился. Но давайте всё же вернемся к техничке.
Я тут с вами обсуждала NGINX, канарейку и версионирование.
То, что можно отправлять запросы на разные endpoint'ы с версией 1 и 2, понятно. Но зачем?
Как-то мою знакомую даже просили на собеседовании рассказать, в каких случаях стоит поднимать версию. Я разбирала мажорную и минорную версии и не только это.
Самый простой пример с версионированием — это мобильные приложения.
Вы всегда скачиваете новую версию приложения или пользуетесь старой, потому что так привычнее и удобнее?
Так вот, есть пользователи, которые всегда скачивают новую версию и любят новинки, а есть те, кто не любит обновляться.
Получается, и для тех, и для других какое-то время нужно поддерживать работу разных версий приложения.
Например, раньше API принимал номер телефона одним полем, а в новой версии вы решили изменить контракт: добавить страну и по-другому передавать номер.
Старые приложения об этом не знают. Если просто изменить старый endpoint, можно сломать работу старых клиентов.
Поэтому появляется v2 — новый контракт, а старый v1 какое-то время продолжает работать.
И тут возникает интересный вопрос: а сколько вообще должна жить старая версия API?
Для мобильного приложения это может быть довольно долго, потому что пользователи не обязаны обновляться сразу.
А теперь самое интересное: как вообще понять, кому отправлять v1, а кому v2?
Самый простой вариант — указать версию прямо в URL:
/api/v1/payment
→ сервис версии 1
/api/v2/payment
→ сервис версии 2
В таком случае маршрутизация довольно очевидная: NGINX или API Gateway смотрит на URL и отправляет запрос в нужный backend.
Но версию можно передавать и иначе — например, через HTTP-заголовок:
API-Version: 2
Тогда Gateway смотрит на заголовок и в зависимости от его значения выбирает нужную версию сервиса.
Есть и еще один вариант — определять версию по клиенту. Например, мобильное приложение версии 5.10 работает с API v1, а приложение 6.0 — уже с API v2.
А дальше появляется канареечный релиз.
Допустим, v2 только что выпустили и мы не хотим сразу отправлять туда всех пользователей. Тогда можно сначала направить на v2, например, 5% трафика, а остальной на v1. Если всё хорошо, увеличиваем долю трафика: 10%, 25%, 50% и так далее.
То есть здесь уже две разные задачи:
Версионирование отвечает на вопрос:
«Какой контракт API должен использовать клиент?»
Маршрутизация отвечает на вопрос:
«Куда отправить конкретный запрос?»
А канареечный релиз позволяет постепенно переключать трафик на новую реализацию и контролировать, что происходит после переключения.
А еще есть даты релизов и обновлений мобильного приложения, в которые стоит успевать командам. Нужно всегда помнить, что в банковское приложение каждый день обновление не выкатишь.
Вот так, кратко и ясно, зачем нужно версионирование и почему после появления v2 вопросы к реализации не заканчиваются.
Сталкивались с версионированием?
Да - 👍
Нет - 🙈
Полезно - 🦅
Я тут с вами обсуждала NGINX, канарейку и версионирование.
То, что можно отправлять запросы на разные endpoint'ы с версией 1 и 2, понятно. Но зачем?
Как-то мою знакомую даже просили на собеседовании рассказать, в каких случаях стоит поднимать версию. Я разбирала мажорную и минорную версии и не только это.
Самый простой пример с версионированием — это мобильные приложения.
Вы всегда скачиваете новую версию приложения или пользуетесь старой, потому что так привычнее и удобнее?
Так вот, есть пользователи, которые всегда скачивают новую версию и любят новинки, а есть те, кто не любит обновляться.
Получается, и для тех, и для других какое-то время нужно поддерживать работу разных версий приложения.
Например, раньше API принимал номер телефона одним полем, а в новой версии вы решили изменить контракт: добавить страну и по-другому передавать номер.
Старые приложения об этом не знают. Если просто изменить старый endpoint, можно сломать работу старых клиентов.
Поэтому появляется v2 — новый контракт, а старый v1 какое-то время продолжает работать.
И тут возникает интересный вопрос: а сколько вообще должна жить старая версия API?
Для мобильного приложения это может быть довольно долго, потому что пользователи не обязаны обновляться сразу.
А теперь самое интересное: как вообще понять, кому отправлять v1, а кому v2?
Самый простой вариант — указать версию прямо в URL:
/api/v1/payment
→ сервис версии 1
/api/v2/payment
→ сервис версии 2
В таком случае маршрутизация довольно очевидная: NGINX или API Gateway смотрит на URL и отправляет запрос в нужный backend.
Но версию можно передавать и иначе — например, через HTTP-заголовок:
API-Version: 2
Тогда Gateway смотрит на заголовок и в зависимости от его значения выбирает нужную версию сервиса.
Есть и еще один вариант — определять версию по клиенту. Например, мобильное приложение версии 5.10 работает с API v1, а приложение 6.0 — уже с API v2.
А дальше появляется канареечный релиз.
Допустим, v2 только что выпустили и мы не хотим сразу отправлять туда всех пользователей. Тогда можно сначала направить на v2, например, 5% трафика, а остальной на v1. Если всё хорошо, увеличиваем долю трафика: 10%, 25%, 50% и так далее.
То есть здесь уже две разные задачи:
Версионирование отвечает на вопрос:
«Какой контракт API должен использовать клиент?»
Маршрутизация отвечает на вопрос:
«Куда отправить конкретный запрос?»
А канареечный релиз позволяет постепенно переключать трафик на новую реализацию и контролировать, что происходит после переключения.
А еще есть даты релизов и обновлений мобильного приложения, в которые стоит успевать командам. Нужно всегда помнить, что в банковское приложение каждый день обновление не выкатишь.
Вот так, кратко и ясно, зачем нужно версионирование и почему после появления v2 вопросы к реализации не заканчиваются.
Сталкивались с версионированием?
Да - 👍
Нет - 🙈
Полезно - 🦅