Скоро Рождество 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-килограммовых батончиков, или они приняли взвешенное решение.
При разделении сервисов можно задать те вопросы, которые бы пахли микросервисами:
- Нужна ли двум службам одна и та же база данных?
- Чтобы протестировать службу, нужно ли ей проходить через другую службу?
- Служба предназначена только для использования другой службой? Почти как частный класс?
- Ответственность за обслуживание — тривиальная работа? Например, пример отправки электронной почты?
Если вы хотите стать более опытным в микросервисах и узнать больше об оптимальном размере сервиса, я рекомендую два ресурса:
- Микросервисы • Мартин Фаулер • GOTO 2014
- Создание микросервисов, Сэм Ньюман
Удачной инженерии.