Потому, что микро-сервисы часто оказываются не «микро», а «нано» сервисами.
Маленькими, изолированными сервисами под конкретную маленькую задачу. Они любят полакомиться чужими событиями. Но они не жадные: поймают одно событие, кинут три. Поодиночке они почти бесполезны. Про них можно слагать анекдоты: «Сколько надо сервисов, чтобы напечатать Hello World?». Поэтому нано-сервисов много, они плодятся как зайчики. Или как маленькие паучки, которые затягивают организацию своей паутинкой.
Систему нано-сервисов трудно спроектировать, легко уронить и невозможно поддерживать.
«Микро» — это не «нано», микро-сервисы устроены иначе. Не скажу, что знаю рецепт хорошего микро-сервиса. Но я постараюсь показать, каким он точно не должен быть.
Историческая потребность в микро-сервисах.
Разберемся, для чего появились микро-сервисы. Это поможет понять, где «что-то пошло не так», и как это исправить. Обрисуем широкими мазками, с чего все начиналось.
Вначале были монолиты.
Потребности бизнеса росли, монолиты становились всё сложнее. Как следствие — росли и команды.
Когда команда разрастается до десятков разработчиков, поставка ценности практически останавливается. Деление команды на группы помогает не сильно. Координация разработки, тестирования и выкладки монолита — сущий ад. Даже трудности масштабирования самого монолита отходят на второй план. Основная сложность — масштабирование разработки.
По кулинарной аналогии, если вас пятеро — вы еще сможете пообедать из одного котла. А вот когда вас пятьдесят... Для того, чтобы решить проблему «одного котла», была придумана cервис-ориентированная архитектура (SOA)
SOA как ответ на проблему монолита.
В теории SOA — это независимые специализированные сервисы, масштабируемые и управляемые.
На практике же это сервисы, ведущие беспорядочные связи либо напрямую друг с другом, либо через корпоративную шину (ESB). Либо и так и этак. Да ещё в довесок часть бизнес-логики размазана по ESB.
По кулинарной аналогии, SOA превращается в развал разных продуктов. Всё перемешано, где что лежит — не понятно. Чтобы добраться до некоторых продуктов, приходится переворошить всю кучу.
Владеть развалом — дорого. Поддерживать его работу — трудно. Если, к примеру, виноград скиснет, он испортит окружающие продукты. Тогда придется перебирать и перемывать все вокруг.
Пример связи сервисов (очень скучный)
Сервис вызывает хранимую процедуру в базе MS SQL.
Процедура выполняет некоторые действия и через linked server вызывает другую процедуру на другом сервере.
Другая процедура через SOAP (!) дергает ESB.
ESB обрабатывает данные, и отправляет сообщение другому сервису.
Другой сервис вызывает хранимую процедуру в первоначальной базе для выполнения бизнес-логики.
Только представьте себе удовольствие разбирать инциденты в такой системе.
SOA, которая казалась спасением от монолита, сама имеет ряд критических недостатков. У нее сложные связи: тронете один сервис — придется менять окружающие. Бизнес-логика размазана как по сервисам, так и по шине. Её трудно тестировать, и не менее трудно разворачивать. Все это привело к изобретению нового лекарства: микро-сервисной архитектуры (MSA).
Микро-сервисы — ответ на проблемы SOA.
Микро-сервис — это некий независимо разрабатываемый и развертываемый сервис. Он изолированный и масштабируемый. Он решает конкретную бизнес-задачу. Каждый микро-сервис имеет свой ограниченный контекст и общается через стандартизированный API.
Возможно, ваше определение микро-сервиса будет иным. Это весьма «холиварная» тема. К примеру, в этой статье приведен целый спектр определений от уважаемых людей.
Давайте дадим определение микро-сервису через аналогию: микро-сервис — как блюдо. Про него можно сказать следующее:
Блюдо изолировано: каждое находится в свой тарелке. Или, если хотите, в контейнере.
Блюда имеют ограниченный контекст. Плов — это плов, его не мешают с фруктами. Потребитель получает то, за что платит по меню.
Блюда слабо связаны между собой. После тарелки любого супа можно взять любой гарнир. А можно и не брать. Бывают, конечно, ограничения: не стоит запивать селедку молоком. Но это — исключение.
Блюда масштабируются. Мало одной котлеты — можно съесть две.
Блюда легко тестируются. Их можно дегустировать по-отдельности.
Блюда индивидуально конфигурируются. Можно взять борщ с пампушкой, можно — без.
По описанию получилось вполне съедобно, не так ли? Так почему же внедрение микро-сервисов так редко заканчивается успехом? Я не буду разглагольствовать про неверное разграничение контекста и другие пороки. Про них и так много сказано. Сфокусируюсь на одном.
Корень проблемы — неверная область использования микро-сервисов.
Микро-сервисы применяются не там и не так.
Микро-сервисы задумывались как альтернатива монолиту, который пилят десятки разработчиков. А сейчас все работают по Agile, команды маленькие. Работают или над своим небольшим продуктом, или над частью общего продукта компании.
Продукт (часть продукта) уже имеет изолированный контекст и слабые зависимости. С другими продуктами (частями) общается по API. Имеет свой технологический стек. Владеет отдельным хранилищем (базой). Независимо разворачивается. И даже имеет свою команду «на две пиццы».
По совокупности признаков, он уже микро-сервис! Продукт является готовым блюдом для потребителей. Так же, как этот салатик:
Но нет! Каждая команда считает свой салатик монолитом. И поэтому берет, и делит на микро-сервисы. Что же у нее получается в итоге? Правильно: нано-сервисы!
Вместо того чтобы смешать все ингредиенты и приготовить блюдо, команда любовно расфасовывает ингредиенты по контейнерам. Но все-таки салат — это не то же самое, что запчасти для салата.
Если вам вместо трех блюд подадут тридцать ингредиентов в отдельных тарелочках, думаю, вы вряд ли посчитаете это хорошим обслуживанием.
UP: Пример моей ошибки в приготовлении микро-сервисов
Задача: Реализовать печать электронных чеков для клиентов.
Вводные: Данные о чеках хранятся в Бэк Офисе. Сами мы печатать не умеем, да и железа нет. Будем печатать при помощи операторов (контрагентов), например, "Атол". Нам надо получать данные из Бэка, обработать нужным образом, отправить оператору. Главное — корректно обработать ошибки операторов, не допустить дубликатов, и ничего не потерять, иначе придёт очень злая бухгалтерия.
Изначальная архитектура:
Предлагалась классическая гексагональная архитектура. Адаптер из Бэка читает данные о чеках и записывает обновления. Адаптеры к Atol, Ferma и к другим операторам (не реклама) по HTTP отправляют чеки на печать и получают результаты. Бизнес-логика управляет куда и с какой скоростью слать чеки.
Алгоритм:
Сервис при помощи адаптера получает из Бэк Офиса данные о чеках. При получении в той же транзакции заносит информацию, какому оператору будет назначен тот или иной чек + ключ идемпотентности.
Сервис преобразует данные, формирует в памяти очереди для каждого оператора
Сервис отправляет чеки на печать в онлайн-кассы через адаптеры
Сервис получает callback от онлайн-касс и записывает в Бэк Офис данные о распечатанных чеках.
Если сервис падает - ничего страшного. Поднимется, повторно пошлет все "подвисшие" чеки нужным операторам. Операторы не допустят дубликатов чеков, ориентируюсь на ключ идемпотентности.
По факту, это и был бы настоящий микро-сервис между Бэк Офисом и операторами.
Изменение архитектуры.
Из-за очень настойчивого мнения руководителя (на прошлой работе) принято решение писать на "микро-сервисах" в его понимании. Поэтому, архитектура преобразовалась в такую:
То есть, стала уже не микро-сервисной, а нано-сервисной.
Почему нано? Потому, что они реально маленькие. На разработку я в одиночку потратил 5 недель. Каждый нано-сервис занимается своей нано-задачей. Бизнес-задачу нано-сервисы могут выполнить лишь сообща.
Заметка: GRPC между "микро-сервисов" выбран потому, что Кафку в компанию еще не завезли, а от старой шины уже решили отказываться. Не бейте меня, это вынужденная мера.
Полученные минусы:
Х2 трудозатрат на реализацию. Потому что оверхед на взаимодействие между сервисами. Просто нужно написать больше обслуживающего кода. Нужно выстраивать потоки данных, нужно думать о том, что делать, если данные потеряются, если не все сервисы будут доступны и т.д.
Х3 затрат на поддержку. Потому что вместо одного микро-сервиса получили ряд нано-сервисов. С алертингом, мониторингом, трейсингом, логами. Все это надо настраивать, хостить, поддерживать. И разбирать инциденты от бухгалтерии вида: "вы опять чек пролюбили"
Излишне заложенная гибкость и масштабирование. То есть излишние потраченные деньги.
Постоянно быть онлайн не нужно. Если покупатель получит чек на несколько часов позже - это вообще некритично по мнению бизнес-заказчика. Горизонтальное масштабирование совсем не нужно. В пике сервисы кушали пару сотен мб оперативки и 10% ядра процессора. Узкое место - скорость онлайн касс, а не сервисов.
Вывод: получились нано-сервисы с завышенной стоимостью владения.
Рассмотрим всю IT-иерархию в нашей ресторанной терминологии. Допустим, вы хозяин ресторана. Хорошее обслуживание может получиться, если
Каждое блюдо — это блюдо, а не набор ингредиентов в контейнерах. То есть — микро-сервис, а не куча нано-сервисов.
Есть еще общая солонка, перечница и салфетница. Это — инфраструктурные микро-сервисы. Солонка в тарелке — так себе решение. Не надо их тащить в свой продукт.
У каждого гостя есть свой стул, место за столом, приборы, и несколько блюд. Получаются железо плюс софт, составляющие информационную систему (ИС).
У компании гостей есть свой стол, за которым они сидят и едят. Все это образует домен.
Ну а все, что находится внутри ресторана, то есть совокупность всех этих доменов, формирует корпоративный IT-ландшафт.
Да простят меня корпоративные архитекторы за такую интерпретацию!
Готовьте микро-сервисы правильно.
Многие компании целиком поражены болезнью чрезмерной декомпозиции. То и дело говорят: «у нас 30 команд и 1500+ микро-сервисов». И ведь искренне еще гордятся этим! Забывая рассказать про свои затраты на инфраструктуру. Рассказать, что новый разработчик до полугода погружается в эти сервисы. Что локализация обычного бага занимает у него неделю.
После всего сказанного позволю себе один совет:
Не дробите ваш маленький продукт на нано-сервисы. Это его убьёт.
Он хороший. Дайте ему шанс повзрослеть.
