Микросервисы: настоящая проблема не в размере сервиса, а в контрактах
Когда компании переходят на микросервисную архитектуру, они обнаруживают, что главная сложность - это не разбивка монолита, а управление зависимостями через API.
Разговоры о микросервисах в последние два года сильно изменились. Раньше это была тема для крупных технологических компаний. Теперь это обсуждают команды в компаниях среднего размера, которые устали от монолита и хотят двигаться быстрее.
Я не против микросервисов. Но за два года наблюдений за тем, как это делается на практике, у меня сложилось устойчивое ощущение: большинство проблем, с которыми сталкиваются команды, приходят не от размера сервисов, а от того, как организованы зависимости между ними.
Что обычно происходит при переходе
Команда берётся за монолит и начинает его резать. Первые несколько сервисов выглядят чисто: каждый делает одно дело, у каждого свои данные. Это приятно.
Потом приходит реальность. Сервисы начинают вызывать друг друга. Форматы запросов меняются тихо - кто-то добавил поле, кто-то переименовал. Один сервис падает и тянет за собой три других, потому что зависимости нигде не описаны явно. Команда обнаруживает, что у них не один монолит, а распределённый монолит - с теми же проблемами, но теперь ещё и по сети.
Контракт - это не документация
Типичная реакция - написать документацию. Описать API в Wiki или в Confluence, добавить примеры запросов. Документация устаревает быстрее, чем её успевают читать.
Контракт - это не описание того, как работает API. Контракт - это соглашение, которое можно проверить автоматически. Если сервис A ожидает от сервиса B определённый формат ответа, это ожидание должно быть закреплено в тестах, которые запускаются при каждом изменении сервиса B. Без этого "контракт" - просто текст, который никто не читает в момент изменения.
Инструменты для contract testing существуют уже несколько лет. Вопрос не в инструментах - вопрос в том, стала ли дисциплина управления контрактами частью процесса разработки.
Что ломается у владельца продукта
Для руководителя проблема выглядит иначе, чем для разработчика. Симптомы такие:
- релизы замедляются, потому что изменение одного сервиса требует ручной проверки нескольких других;
- инциденты всё чаще объясняются тем, что "сервис X изменил формат, а сервис Y не знал";
- никто не может уверенно ответить на вопрос "что произойдёт, если мы изменим вот это поле в API";
- онбординг нового разработчика занимает недели, потому что картина зависимостей нигде не существует целиком.
Всё это - симптомы одной проблемы: контракты между сервисами не управляются, они просто существуют.
Версионирование как дисциплина
Отдельная тема - версионирование API. Многие команды избегают его, потому что это дополнительная работа. Избегание стоит дороже.
Без явного версионирования любое изменение потенциально ломает потребителей. Команды начинают бояться изменений, откладывать их, делать "обратно совместимые" патчи, которые постепенно превращают чистый интерфейс в запутанный набор необязательных полей.
Правило, которое работает: любое изменение, которое может сломать потребителя, - это новая версия. Старая версия поддерживается до тех пор, пока все потребители не перейдут. Это звучит тяжело, но на практике это дешевле, чем разбирать инциденты.
Вопросы для диагностики
Если вы думаете о микросервисной архитектуре или уже живёте в ней, несколько вопросов помогут оценить зрелость управления контрактами:
- Можете ли вы за десять минут получить актуальную карту того, какие сервисы вызывают какие?
- Есть ли автоматические тесты, которые проверяют совместимость API между сервисами?
- Когда в последний раз изменение API одного сервиса неожиданно сломало другой?
- Кто принимает решение о том, что изменение API является "критическим" и требует версионирования?
- Есть ли у разработчика, который меняет API, инструмент, чтобы узнать, кто этот API использует?
Если на большинство этих вопросов нет уверенного ответа - разговор о следующем сервисе стоит отложить и сначала навести порядок в существующих зависимостях.