Скоро Рождество 2022 года, и индустрия разработки программного обеспечения извлекла много уроков. Одно из них заключалось в том, что монолиты — это зло. Но что, если вместо этого мы впадем в другую крайность и создадим слишком много сервисов? Это то, над чем мы будем размышлять.

Недостатки монолитов

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

Таким образом, вместо монолитов святая серебряная пуля на данный момент — это микросервисы, которые устраняют недостатки монолитов. Но нам нужно понимать, что разработка программного обеспечения — это профессия компромиссов, так каковы же недостатки микросервисов?

  • Код разбит на несколько репозиториев. Отладка или понимание требует прыжков.
  • Вызовы API вместо вызовов модулей добавляют сетевую задержку и более сложную обработку ошибок.
  • Необходимо настроить несколько конвейеров, мониторинг и оповещения.

Так что, если мы получим эти недостатки и усугубим их в геометрической прогрессии, создав множество мини-сервисов? То, что мы будем называть NanoServices.

Что я имею в виду под наноуслугами?

Допустим, есть микросервис, который читает сообщения из очереди и отправляет электронные письма.

Оправдывает ли этот микросервис стоимость?

  • Мониторинг
  • Строительство трубопроводов
  • Ведение документации

Я бы решительно возразил, что нет, код для отправки электронного письма состоит из 5–10 строк. Почему мы вкладываем сотни линий пайплайнов в развертывание 5–10 линий?

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

Аналогия с весами

Давайте представим, что мы можем количественно определить наше программное обеспечение как вес. для нашего монолита для компании электронной коммерции есть 500 кг веса, представляющие сложность программного обеспечения, и 8-килограммовая планка поддержки, представляющая конвейеры, мониторинг и оповещение.

Если у нас будет все это в одном такте, это будет слишком тяжело. Для подъема требуется несколько человек, координация между командами и развертывание выполняются не часто, потому что это слишком тяжело для перемещения.

Вместо этого мы можем разделить 500 кг на меньшие веса в другую крайность. Разделим 500-килограммовый батончик на 2 кг в каждом батончике. Итак, теперь у нас будет 250 гирь, которые мы можем поднять, не так ли легче? Что ж, теперь у нас есть 500 кг веса плюс 250 8-килограммовых батончиков, всего 2000 кг только батончиков.

Баланс является ключевым

Как известно, 508 кг на одной штанге — это слишком много, а 250 гирь дадут нам слишком много дополнительных штанг. Цель состоит в том, чтобы найти правильный баланс. Возможно, эти 500 кг можно разделить на 10 стержней, что добавит 72 кг дополнительных стержней, но в целом это того стоит, учитывая, что теперь мы можем перемещать эти 500 кг быстрее и независимо.

Может быть, было бы лучше перейти на 20 баров. Без понятия. Меняется от случая к случаю. Я хочу, чтобы вы задумались о дополнительном весе, который вы платите за каждую услугу. Таким образом, вашей команде не нужно нести слишком много дополнительных 8-килограммовых батончиков, или они приняли взвешенное решение.

При разделении сервисов можно задать те вопросы, которые бы пахли микросервисами:

  • Нужна ли двум службам одна и та же база данных?
  • Чтобы протестировать службу, нужно ли ей проходить через другую службу?
  • Служба предназначена только для использования другой службой? Почти как частный класс?
  • Ответственность за обслуживание — тривиальная работа? Например, пример отправки электронной почты?

Если вы хотите стать более опытным в микросервисах и узнать больше об оптимальном размере сервиса, я рекомендую два ресурса:

Удачной инженерии.