Удивительно, сколько полезностей можно узнать за один хабрамитап Хабр ПРО. Например, какая судьба ждёт монолит при переходе на микросервисы и кто отвечает за общий код между двумя микросервисами.

Эти и другие вопросы обсуждались 25 ноября в выпуске «Хабрамитап про микросервисы: отвечаем на вопросы с Хабр Q&A». Вебкаст посетил наш сотрудник — руководитель направления автоматизации в Россельхозбанке (РСХБ) Денис Рылеев.

На протяжении эфира Денис отвечал на вопросы о микросервисах, которые задавал ведущий хабрамитапа Андрей Аврамчук, подобравший самые интересные топики от зрителей вебкаста и пользователей бывшего Тостера — нынешнего Хабр Q&A. Кроме Дениса выступал ещё один эксперт — системный инженер компании EPAM Михаил Чугунов.

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

Введение в микросервисы
Серебряная пуля Фредерика Брукса
Архитектура, разворачивание и API Gateway
Какую литературу советуют почитать профессионалы

Заранее обрадуем жаждущих именно услышать специалистов: каждый вопрос сопровождается ссылкой с вшитым тайм-кодом, так что долго искать ответы в записи вебкаста не придётся.

Хороший вопрос требует хорошего ответа. Приступим.

Введение в микросервисы

Что такое микросервисы и чем они отличаются от сервисов? [5:40]

Перед началом обсуждения комплексных вопросов нужно ознакомиться с самим понятием «микросервисы». Именно с этого и начинает ведущий Андрей.

Наш специалист Денис не стал приводить определения из «Википедии», а рассказал занятную историю из своей жизни:

«Самым первым сервисом, о котором я услышал примерно в 2005 году и подумал, что это КРУТО, был SOAP-сервис у Центробанка по курсу валют. Это просто сервис. Но если внедрить его в определённую инфраструктуру, которая будет использовать его для своих нужд, то это будет уже микросервис».

Михаил дополнил мысль своей сравнительной характеристикой:

«С моей стороны, если рассматривать разницу между сервисом и микросервисом — это как сравнивать DevOps и SRE. Потому что в одном случае сервис — это что-то большое, схожее с методологией, тогда как микросервис — что-то маленькое, зачастую товар, если обращаться к истокам. Но при этом, если рассматривать с точки зрения разработки, и то, и другое может быть одним и тем же. То есть микросервис — это какой-то элемент, который выполняет свою задачу».

«Но этот вопрос являлся не столько вводным, сколько разминочным. Пришло время перейти ко второму вопросу!» — замечает ведущий Андрей.

Как понять микросервисы? [7:05]

Легенда. Автор встал перед задачей переписать проект. У него имеется много различных сервисов и API, с которым должно общаться приложение. Он хочет проверить возможность перехода на микросервисы. С какими проблемами он столкнётся?

Такая задачка и подобные ей периодически проскальзывали на Хабр Q&A и в комментариях к вебкасту. Михаил не смог обойти стороной приведённую задачу и дал подробный ответ, расставив все точки над i:

«В первую очередь при разделении монолита стоит задуматься: не заэффектит ли выделение одного куска кода всё остальное?

По стандартным рекомендациям обычно говорят: возьмите ваш монолит, выделите крупные “куски”, разделите его и попробуйте, если всё заработало, “дробить” его дальше и дальше, пока каждый из ваших элементов не будет работать атомарно. В любом случае, чтобы это понять — нужно пробовать».

Когда вы пришли к выводу, что нужно переходить на микросервисы? [11:28]

Истории неудачного деплоя и рефакторинга, когда всё валится из рук, всегда представляются окружающим скорее комическими, нежели трагическими.

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

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

«Переходить к микросервисам следует в случае достижения проектом таких масштабов, когда ты начинаешь осознавать, что не понимаешь ничего из того, о чём говорят коллеги, вносящие коррективы в проект».
Каким бы смешным это ни казалось, практика показывает, что всё приходит через непонимание.

Какая судьба ждёт монолит при переходе на микросервисы? [18:58]

Откроем секрет: практически ни один монолит не был «распилен» до конца, он всё равно в каком-то виде продолжает жить.

О том, что становится с монолитом после «распила», рассказал Михаил:

«Если мы рассматриваем идеальные условия, то от монолита остаётся условный core-сервис, который знает, куда перенаправлять запросы и как взаимодействовать с другими компонентами проекта».

Серебряная пуля Фредерика Брукса

Стоит ли использовать RabbitMQ для общения между микросервисами? [9:54]

Правильно будет сказать, что на этот вопрос (как и на все последующие) нет однозначного ответа. Дело в том, что выбор технологий, методологий и протоколов зависит от ряда условий, среди которых:

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

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

«Можно использовать любой MQ, который представляется удобным разработчику либо команде разработчиков», — уверенно отвечает Денис.

Михаил дополняет ответ:
«Выбор технологии зависит от уже используемого набора решений в проекте, а также от уровня экстремальности интеграции; неважно: Rabbit, Kafka или Redis Pub/Sub — выбор зависит от архитектора».

Как лучше джоинить таблицы с разных микросервисов? Kafka Streams или SQL Keys? [32:50]

«Необходимо сначала посмотреть, как вы ранее джоинили различные таблицы, относящиеся к отдельным сервисам в монолите.

Приоритетный вариант — реализация уже знакомых разработчику методов. Если же в новом проекте не получается использовать старые наработки, то надо понять, что будет проще интегрировать на данном этапе. Стоит отталкиваться прежде всего от этого», — отвечает Денис.

На какие показатели нужно смотреть, когда стоит вопрос о «распиливании» монолита?

Если вы взялись за переход на микросервисную архитектуру, на это были определённые причины: попытка сделать продукт независимым от конкретного набора технологий или стремление к качественному масштабированию. Но стоит ли игра свеч? Чтобы определиться и вынести вердикт, нужно выделить набор показателей, определить список вопросов, ответив на которые можно будет действовать дальше без лишних сожалений. Именно такой подход и рассматривает наш эксперт Денис:

«Прежде всего, этот вопрос относится непосредственно к команде разработчиков. Здесь необходимо оценить ситуацию: профит, который можно извлечь, и издержки, тормозящие разработку проекта. Если вы, основываясь на данных показателях, понимаете, что пользы от микросервисов больше, чем от монолита, — дерзайте!»

Архитектура, разворачивание и API Gateway

Нужно признать, что иногда серебряная пуля возможна, поскольку существует общий свод рекомендаций и технических условностей, относящихся к организации отдельных компонентов. Денис и Михаил постарались дать качественные ответы на многочисленные технические вопросы. Самые интересные из них мы собрали тут.

Зачем нужен API Gateway как единая точка входа? [8:30]

Если кратко, всегда удобнее, когда фронтенд «не задумывается» о том, где запросить определённый набор данных у бэкенда. То есть мы полагаем, что у нас есть точка входа, которая позволяет независимо от того, с какого устройства вы отправили запрос, получить ответ. Именно API Gateway обладает прерогативой определять, куда и что доставить в поставленной задаче.

Вот как это работает

Где развернуть микросервисное приложение?

Легенда. У автора вопроса был монолит, и он разбил его на сервисы, упакованные в Docker. Что выбрать: заказать виртуальную машину и на ней всё развернуть или пользоваться услугами облачного провайдера?

Данный вопрос тесно связан со специализацией Михаила. Потому он и дал исчерпывающий ответ с позиции DevOps-инженера:

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

Если мы будем использовать свою виртуалку, то нам нужно быть уверенными в том, что рядом с нашей “стоечкой” будет человек, который в штатном режиме сможет её поддерживать».

Кто владеет зоной ответственности за общий код между двумя микросервисами? [30:10]

Своим опытом со слушателями поделился Денис. Он сумел выделить два варианта развития событий:

Если это серьёзный Enterprise-проект, должен быть ответственный архитектор, который бы сам обозначил те или иные зоны ответственности.
В случае, когда речь идёт о более «стихийном» проекте, командам придётся научиться договариваться и добавлять во время тестирования дополнительный слой, отвечающий за проверку на совместимость версий интерфейсов.

Важно понимать масштабы проекта, чтобы верным образом выносить определённые обязанности на долю отдельного специалиста. В случае не сильно большого проекта, где по сложившемуся обычаю процессы разработки циркулируют так, что конфликтов на почве разделения ответственностей обычно не возникает, стоит воспользоваться способностью «договариваться».

Какие есть советы по устойчивой архитектуре микросервисов? [57:23]

Легенда. Предположим, есть цепочка независимых сервисов внутри системы, которая общается «между собой» по API. Как правильно сделать транзакцию на откат, если в цепочке запросов микросервисов произошёл сбой? Делать отдельные экшены на откат к предыдущему сервису?

«Из своего опыта могу сказать, что распределённые транзакции — это дорогой и, как правило, неудобный подход.

Логику “распиливать” лучше так, чтобы одна большая транзакция могла быть расписана на несколько маленьких, которые вполне нормально будут работать. Также следует научить свои микросервисы обрабатывать повторные запросы, если что-то пошло не так.

С точки зрения реализации есть множество паттернов, которые применяются в том же Netflix, а также позволяют сделать процесс написания кода гораздо проще», — считает Денис.

Если у нас несколько реплик микросервиса и мы используем distributed cache, то нужно ли сбрасывать кэш, если объект кэша поменялся в новой версии микросервиса? [1:01:07]

«Это проблема любой сериализации. Если отсутствует обратная совместимость, то, конечно, придётся.

Поэтому, когда мы говорим о любой сериализации (неважно, для кэша или нет), всегда очень важно использовать модель, позволяющую задействовать обратную совместимость. Это к вопросу о Java, а именно о том, почему нельзя использовать встроенную в язык сериализацию», — ответил Денис.

Какую литературу советуют почитать профессионалы

Разумеется, невозможно ответить исчерпывающе на абсолютно все вопросы зрителей хабрамитапа. Для более осознанного погружения в тему нужно изучать специализированные ресурсы: литературу или блоги.

На вебкасте отдельно спросили: как правильно разделять монолит на слои?

Денис ответил на вопрос следующим образом:

«Сервис — он как и любой монолит: когда ты его пишешь, то не знаешь всего наперёд. В будущем может смениться БД, например. Поэтому в любом случае под такие крупные модули (для работы с БД и т. д.) стоит писать некоторые адаптеры, которые позволят легко перейти на любую другую технологию. Под какие-то ключевые вещи всё равно нужно разрабатывать адаптеры, как и в монолите».

Ну а какие книги следует прочитать по теме? Эксперт не оставил и этот вопрос без ответа:

«Вообще, я рекомендую для начала прибегнуть к ресурсам британского программиста-писателя Мартина Фаулера, чтобы лучше разобраться в теме и, в частности, с архитектурными подходами в создании микросервисных продуктов».

Михаил же советует новичкам обратиться к литературе издательства O'Reilly, которая сейчас активно переводится на русский язык. При этом он отметил, что для начала в познании микросервисов хорошо подходит книга авторства Сэма Ньюмена «Создание микросервисов». У Сэма есть ещё несколько крутых работ по микросервисам, но они пока ждут своего перевода на русский.

Также стоит уделить время чтению блогов компаний: Atlassian, Nginx и др. Зачастую организации выкладывают инсайды, в которых описаны устройства тех или иных сервисов, что, несомненно, может пригодиться не только начинающим специалистам, но и опытным.

Заключение

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

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

Тем не менее возможные проблемы не должны пугать специалистов. Напротив, они бросают вызов современным гениям, чтобы те научились разделять и властвовать.

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

Открываешь окно, а в коридоре взрывается тумбочка: как микросервисы убили монолит