Привет, меня зовут Владимир Кустиков, я — архитектор решений в e-Legion. И сегодня я хотел бы рассказать вам про микросервисы.
Наверное, я где-то неправ. А возможно, что у меня просто подгорело. Но в какой-то момент после запроса рассказать о том, в каких проектах я успешно применял микросервисы, мое терпение лопнуло. Ни в каких, понятно?! И это мой персональный повод для гордости. Если вам вдруг стало интересно, что еще может рассказать этот странный безумец с пылающим взором, то у меня есть хорошая новость — ниже о микросервисах будет адаптированный под хаброформат рассказ с картинками. А если нет — смело закрывайте эту статью.
Для начала давайте синхронизируемся насчёт понятий, которые будут обсуждаться, а потом можно приступить и к самому обсуждению. Итак, микросервисы — что в имени тебе моем?
У меня есть две книги от Сэма Ньюмена: «Проектирование микросервисов» и «От монолита к микросервисам». Они слегка нелогичны, так как вторая книга является по сути предтечей первой, хотя и выпущена сильно позже. Но особый интерес во второй книге для меня вызвали комментарии переводчика. Он ВНЕЗАПНО взял и перевел наши родненькие «микросервисы» как «микрослужбы», и по всему тексту книги ни одного упоминания о микросервисах не оставил. И наверное, моему возмущению такой отсебятиной не было бы предела, если бы он там же не объяснил свою позицию. А она крайне логична — слово «служба» несет в себе мощный семантический посыл, который оказывается утраченным при другом переводе. Так что, поразмыслив, я пришел к выводу, что этот вариант мне даже нравится больше. Действительно, легко представить себе некого служивого, который умеет нести свою службу, от и до, и ни шага в сторону (привет, контракты!). И тогда микрослужбы — это мальчики-с-пальчики, которые вроде и ростом невелики, и помощи от них немного, но при необходимости могут и Гулливера нитками к земле привязать.
Казалось бы, после такого перевода необходимость в определении микросервиса отпадает сама собой. Но есть ещё один вариант от Avery Pennarun, которым невозможно не поделиться:
Внимание, вопрос на засыпку. Знаете ли вы, чем отличается монолит от микросервисов?
А если вот так?
Правда, монолит красивее?
Хотя о вкусах не спорят, но как минимум, на этой картинке он выглядит проще. Да, собственно, так оно и есть. Монолит в разы проще, но при этом предоставляет массу возможностей, от которых приходится отказываться, переходя на микросервисную архитектуру. Ну вот, навскидку:
И даже нарисовать монолит бывает проще. Вот как симпатично он может выглядеть в гексагональной архитектуре.
Не подумайте, я не настолько люблю монолиты, чтобы эта любовь розовой пеленой застилала мне глаза. Вовсе нет, у монолитов есть свои недостатки, которые могут быть в определенных условиях настолько весомыми, что на них потребуется самая экстремально возможная реакция.
Вот эти «граждане»:
Посмотрите на рисунок ниже. Видите суслика? А его там и нет, так как не умеют суслики рыть норы в форме правильного куба, тем более, что это не простой куб, а самый настоящий куб масштабирования.
Чтобы разобраться во всем этом многобукофии и многоцифрии, предлагаю сразу обратить свое внимание на левый нижний угол куба с гордой цифрой «ноль». Этот угол — стандартное представление о монолитах — такие решения «сами в себе», запускаемые в единственном экземпляре и обрабатывающие весь поток поступающих данных. Но к счастью, жизнь монолита не обрывается в этом углу, у него есть еще целых три оси масштабирования:
Прежде, чем все-таки перейти на микросервисы, ответьте на следующие вопросы:
Что здесь интересного?
Смотрите, монолит практически полностью остался в первозданном виде. Но это только на первый взгляд. Предвидя новые вызовы или отвечая на уже существующие, монолит выделил из себя форпост — сервис, который должен решить те задачи, с которыми по объективным причинам цельному неповоротливому решению справиться значительно сложнее. Это могут быть проблемы неравномерности нагрузки, особенностей развертывания, особенностей технологического стека, организационных проблем — по сути тех проблем, ради решения которых и призывают «нас наш, нас новый мир построить», предварительно разрушив все до основанья.
При таком подходе в цитадели остается цельно и связно функционирующая предметная логика приложения, прикрытая от внешнего окружения форпостами, имеющими своё независимое внутреннее самоуправление. По собственному опыту могу сказать, что часто подобная архитектура решает все те проблемы, ради которых пытаются перейти на микросервисы, причем делает это наиболее естественным, простым и безопасным для разработки и бизнеса способом.
Но я подозреваю, что может возникнуть резонный вопрос — почему я всеми силами пытаюсь склонить читателей к неиспользованию микросервисов? Почему настолько категоричен в отношении виновников нашего торжества (читай, статьи)?
При всей простоте идеи микросервисы — крайне сложная вещь, которая несет с собой другие сложные вещи. Самое важное, что необходимо держать в голове следующее: микросервисные системы — это распределенные системы со всеми вытекающими последствиями. Если при прочтении предыдущего предложения ваши волосы не встали дыбом, то могу вас только поздравить. Либо с тем, что вы настолько умны (и я вам очень сильно завидую), либо с тем, что у вас впереди множество открытий чудных.
Вообще, существует несколько преимуществ перехода на микросервисы:
Ну а теперь о болях:
o Канареечные и сине-зеленые выпуски
o DevOps-инженеры
Ну ок, вы все-таки решились. Я сдаюсь. Микросервисы — ваше всё, и возражений не принимается. Как сделать хороший микросервис? Да практически так же, как и хороший модульный монолит. Но есть еще несколько пунктиков:
habr.com
Наверное, я где-то неправ. А возможно, что у меня просто подгорело. Но в какой-то момент после запроса рассказать о том, в каких проектах я успешно применял микросервисы, мое терпение лопнуло. Ни в каких, понятно?! И это мой персональный повод для гордости. Если вам вдруг стало интересно, что еще может рассказать этот странный безумец с пылающим взором, то у меня есть хорошая новость — ниже о микросервисах будет адаптированный под хаброформат рассказ с картинками. А если нет — смело закрывайте эту статью.
Для начала давайте синхронизируемся насчёт понятий, которые будут обсуждаться, а потом можно приступить и к самому обсуждению. Итак, микросервисы — что в имени тебе моем?
У меня есть две книги от Сэма Ньюмена: «Проектирование микросервисов» и «От монолита к микросервисам». Они слегка нелогичны, так как вторая книга является по сути предтечей первой, хотя и выпущена сильно позже. Но особый интерес во второй книге для меня вызвали комментарии переводчика. Он ВНЕЗАПНО взял и перевел наши родненькие «микросервисы» как «микрослужбы», и по всему тексту книги ни одного упоминания о микросервисах не оставил. И наверное, моему возмущению такой отсебятиной не было бы предела, если бы он там же не объяснил свою позицию. А она крайне логична — слово «служба» несет в себе мощный семантический посыл, который оказывается утраченным при другом переводе. Так что, поразмыслив, я пришел к выводу, что этот вариант мне даже нравится больше. Действительно, легко представить себе некого служивого, который умеет нести свою службу, от и до, и ни шага в сторону (привет, контракты!). И тогда микрослужбы — это мальчики-с-пальчики, которые вроде и ростом невелики, и помощи от них немного, но при необходимости могут и Гулливера нитками к земле привязать.
Казалось бы, после такого перевода необходимость в определении микросервиса отпадает сама собой. Но есть ещё один вариант от Avery Pennarun, которым невозможно не поделиться:
Но так ли плох монолит, чтобы на него требовалось реагировать, да еще и экстремально? Давайте разбираться, что там у него с порохом и пороховницами.
Внимание, вопрос на засыпку. Знаете ли вы, чем отличается монолит от микросервисов?
А если вот так?
Правда, монолит красивее?
Хотя о вкусах не спорят, но как минимум, на этой картинке он выглядит проще. Да, собственно, так оно и есть. Монолит в разы проще, но при этом предоставляет массу возможностей, от которых приходится отказываться, переходя на микросервисную архитектуру. Ну вот, навскидку:- Просто разрабатывать.
- Легко вносить сквозные изменения.
- Просто тестировать.
- Просто развертывать.
И даже нарисовать монолит бывает проще. Вот как симпатично он может выглядеть в гексагональной архитектуре.
Не подумайте, я не настолько люблю монолиты, чтобы эта любовь розовой пеленой застилала мне глаза. Вовсе нет, у монолитов есть свои недостатки, которые могут быть в определенных условиях настолько весомыми, что на них потребуется самая экстремально возможная реакция.
Вот эти «граждане»:
- Сложно разрабатывать разнородную функциональность.
- Сложно организовать работу разных команд.
- Каждое изменение требует полного переразвёртывания.
- Зависимость от постепенно устаревающего стека.
- Зависимость от единственного физического узла.
- Невозможно масштабировать функциональность отдельно.
Посмотрите на рисунок ниже. Видите суслика? А его там и нет, так как не умеют суслики рыть норы в форме правильного куба, тем более, что это не простой куб, а самый настоящий куб масштабирования.
Чтобы разобраться во всем этом многобукофии и многоцифрии, предлагаю сразу обратить свое внимание на левый нижний угол куба с гордой цифрой «ноль». Этот угол — стандартное представление о монолитах — такие решения «сами в себе», запускаемые в единственном экземпляре и обрабатывающие весь поток поступающих данных. Но к счастью, жизнь монолита не обрывается в этом углу, у него есть еще целых три оси масштабирования:
- Ось X — распределение нагрузки между несколькими идентичными экземплярами.
- Ось Y — разделение приложения на функциональные сервисы.
- Ось Z — выполнение запросов в зависимости от их атрибутов.
Прежде, чем все-таки перейти на микросервисы, ответьте на следующие вопросы:
- Ваш монолит разбит на связные модули с минимальным количеством внешних взаимодействий?
- Вы рассмотрели все потенциальные варианты масштабирования монолита?
- Не подойдет ли для ваших задач компромиссное решение, например, модульный и/или распределенный монолит или цитадель?
Что здесь интересного?
Смотрите, монолит практически полностью остался в первозданном виде. Но это только на первый взгляд. Предвидя новые вызовы или отвечая на уже существующие, монолит выделил из себя форпост — сервис, который должен решить те задачи, с которыми по объективным причинам цельному неповоротливому решению справиться значительно сложнее. Это могут быть проблемы неравномерности нагрузки, особенностей развертывания, особенностей технологического стека, организационных проблем — по сути тех проблем, ради решения которых и призывают «нас наш, нас новый мир построить», предварительно разрушив все до основанья.
При таком подходе в цитадели остается цельно и связно функционирующая предметная логика приложения, прикрытая от внешнего окружения форпостами, имеющими своё независимое внутреннее самоуправление. По собственному опыту могу сказать, что часто подобная архитектура решает все те проблемы, ради которых пытаются перейти на микросервисы, причем делает это наиболее естественным, простым и безопасным для разработки и бизнеса способом.
Но я подозреваю, что может возникнуть резонный вопрос — почему я всеми силами пытаюсь склонить читателей к неиспользованию микросервисов? Почему настолько категоричен в отношении виновников нашего торжества (читай, статьи)?
При всей простоте идеи микросервисы — крайне сложная вещь, которая несет с собой другие сложные вещи. Самое важное, что необходимо держать в голове следующее: микросервисные системы — это распределенные системы со всеми вытекающими последствиями. Если при прочтении предыдущего предложения ваши волосы не встали дыбом, то могу вас только поздравить. Либо с тем, что вы настолько умны (и я вам очень сильно завидую), либо с тем, что у вас впереди множество открытий чудных.
Вообще, существует несколько преимуществ перехода на микросервисы:
- Делает возможными непрерывную доставку и развертывание крупных, сложных систем.
- Код небольшой и простой в обслуживании.
- Независимое развертывание.
- Независимое масштабирование.
- Автономность команд разработки.
- Позволяет экспериментировать с технологиями.
- Лучшая изоляция неполадок.
Ну а теперь о болях:
- Сложно подобрать подходящее разбиение на сервисы.
- Сложность распределенных систем затрудняет разработку, тестирование и развертывание.
- Развертывание функциональности, охватывающей несколько сервисов, требует тщательной координации.
- Сложно определить момент, когда переход на микросервисы станет обоснованным.
- Автономное развертывание
- Сетевые вызовы
- Координация множества сервисов
- Пользовательский интерфейс
- Безопасность
- Распределенные транзакции
- Генерация отчетов
- Разные рабочие окружения
o Канареечные и сине-зеленые выпуски
o DevOps-инженеры
- Тестирование
- Журналирование
Ну ок, вы все-таки решились. Я сдаюсь. Микросервисы — ваше всё, и возражений не принимается. Как сделать хороший микросервис? Да практически так же, как и хороший модульный монолит. Но есть еще несколько пунктиков:
- Его выделение обосновано (есть спец-команда, спец-требования, спец-ограничения, спец-циалисты).
- У него сильное внутреннее сцепление и слабая внешняя связанность.
- Он выполняет четко определенную функциональность.
- Есть настроенное внешнее окружение и шаблон сервиса, который умеет в этом окружении жить и взаимодействовать.
- Интеграции — обычно хороший вариант для микросервиса.
Микросервисы. Не всё то золото, что хайп
Привет, меня зовут Владимир Кустиков, я — архитектор решений в e-Legion . И сегодня я хотел бы рассказать вам про микросервисы. Наверное, я где-то неправ. А возможно, что у меня просто...
habr.com