Service Template

Даже среди сильных инженеров часто можно услышать такое мнение:

Ну, микросервисы, это когда каждый сам ковыряется как хочет, выбирает что хочет и как-то там решает проблемы.

К большому сожалению, это частое заблуждение. Давайте обсудим, какие преимущества даёт применение паттерна Service Template¹ на уровне всей компании.

Service Template предоставляет унифицированную структуру и общий шаблон проекта. Это сильно снижает когнитивную нагрузку на разработчиков: все механизмы, начиная от обработки входящих запросов до публикации и чтения сообщений из общей шины будут одинаковыми во всех сервисах.

Организация распределенного трейсинга, логирование ошибок и сбор метрик тоже являются частью шаблона сервиса. Используя общие отлаженные механизмы, разработчикам не потребуется решать эти вопросы в каждом сервисе с нуля.

Хороший шаблон сервиса, даже если у него есть вариации на разных языках программирования, упрощает работу команды эксплуатации. Предоставляя унифицированный артефакт сборки, всегда слушающий на одном и том же порту, конфигурирующийся одним и тем же набором переменных окружения, сервисы, созданные по шаблону, используют единый пайплайн деплоя. Не требуется поддерживать разные наборы пайплайнов для разных сервисов, количество которых может измеряться сотнями или даже тысячами.

Не только сами пайплайны, но и манифесты развёртывания, будь-то helm-чарты, ресурсы kustomize или плейбуки ansible, тоже будут едиными для всех сервисов.

Помимо технических вопросов, есть ещё один не самый очевидный плюс: при таком единообразном подходе становится проще перекидывать членов одной команды в другую. Причины для этого могут быть разные. Кому-то надоело работать над своим проектом и он хочет получить новый опыт. Где-то нужно временно усилить команду одним-двумя разработчиками. Или же потребуется сформировать новую команду для работы над новой задачей.

При этом подходе производительность может просесть только в контексте знакомства с новой предметной областью, все инструменты и подходы останутся теми же что и раньше.

Наконец, давайте попробуем формализовать требования к шаблону сервиса:

• Соответствует 12 факторам.
• Использует единый набор имен переменных окружения для конфигурации.
• Поддерживает один язык программирования.
• Артефакт сборки слушает на одном и том же порту.
• В шаблоне уже содержатся и предварительно настроены:
  • механизмы обработки и сбора ошибок;
  • логирование;
  • распределенный трейсинг.
• Определены и переиспользуются:
  • механизмы обработки входящих и исходящих запросов;
  • механизмы публикации и приёма сообщений из общей шины данных.

Если вы используете несколько языков программирования, то на каждый язык должен быть собран свой шаблон сервиса. Однако важно помнить, что слишком широкий круг используемых языков технологий вредит качеству и производительности.

Таким образом мы подходим к ещё одной важной теме — Technology Radar или TechRadar — о нём в следующем посте.