Удивительно, сколько полезного можно узнать в одном хабрамитапе Хабр ПРО.
Например, какая судьба ждет монолит при переходе на микросервисы и кто отвечает за общий код между двумя микросервисами.
Эти и другие вопросы обсуждались 25 ноября в номере «Хабрамитап о микросервисах: отвечаем на вопросы Хабра Q&A» .
Трансляцию посетил наш сотрудник - начальник отдела автоматизации Россельхозбанка (РСХБ) Денис Рылеев .
В ходе эфира Денис ответил на вопросы о микросервисах ведущего хабрамитапа Андрея Аврамчука, который отобрал самые интересные темы от зрителей веб-трансляции и пользователей бывшего Тостера — нынешнего Хабр Вопросы и Ответы.
Помимо Дениса выступил еще один эксперт — системный инженер EPAM Михаил Чугунов.
Из этой статьи даже начинающий разработчик поймет, что такое микросервисы и в каких ситуациях они используются.
Денис и Михаил постарались ответить на все вопросы максимально доступным языком.
Мы выделили несколько категорий вопросов:
- Введение в микросервисы
- Серебряная пуля Фредерика Брукса
- Архитектура, развертывание и шлюз API
- Какую литературу рекомендуют прочитать профессионалы?
Хороший вопрос требует хорошего ответа.
Давайте начнем.
Введение в микросервисы
Что такое микросервисы и чем они отличаются от сервисов? [5:40]
Прежде чем приступить к обсуждению сложных вопросов, необходимо ознакомиться с понятием «микросервисы».Именно с этого и начинает ведущий Андрей.
Наш специалист Денис Я не стал приводить определения из Википедии, а рассказал забавную историю из своей жизни:
«Самый первый сервис, о котором я услышал где-то в 2005 году и подумал, что это КРУТО, — это SOAP-сервис Центрального банка для определения обменных курсов.
Это просто услуга.
Но если внедрить его в некую инфраструктуру, которая будет использовать его для своих нужд, то это уже будет микросервис».
Майкл дополнил мысль своими сравнительными характеристиками: «С моей стороны, если вы посмотрите на разницу между сервисом и микросервисом, это похоже на сравнение DevOps и SRE. Потому что в одном случае сервис — это что-то большое, похожее на методологию, а микросервис — это что-то маленькое, часто продукт, если вернуться к истокам.
Но в то же время, если посмотреть на это с точки зрения развития, то и другое может быть одним и тем же.
То есть микросервис — это некий элемент, выполняющий свою задачу».
«Но этот вопрос был не столько вводным, сколько разминочным.
Пришло время перейти ко второму вопросу!» - отмечает ведущий Андрей .
Как разобраться в микросервисах? [7:05]
Легенда.Перед автором стояла задача переписать проект. Он имеет множество различных сервисов и API, с которыми приложение должно взаимодействовать.
Он хочет проверить возможность перехода на микросервисы.
С какими проблемами он столкнется?
Эта проблема и ей подобные периодически появлялись на Хабре «Вопросы и ответы» и в комментариях к трансляции.Майкл Я не мог обойти вниманием вышеизложенную проблему и дал развернутый ответ, расставив все точки над i: «Первое, о чем нужно подумать при разделении монолита: не отнимет ли разделение одного фрагмента кода все остальное? По стандартным рекомендациям обычно говорят: возьмите свой монолит, выберите крупные «куски», разделите его и попробуйте, если все работает, «расщеплять» его дальше и дальше, пока каждый ваш элемент не заработает атомарно.
В любом случае, чтобы это понять, нужно постараться».
Когда вы пришли к выводу, что вам нужно переходить на микросервисы? [11:28]
Истории неудачного развертывания и рефакторинга, когда все идет не так, всегда кажутся окружающим скорее комичными, чем трагическими.Однако, как показывает опыт Дениса и Михаила, любой крупный проект доходит до того, что открываешь окно, и тумбочка в коридоре взрывается.
И это нормально.
Денис выделяет на первый взгляд забавный признак, по которому можно судить о перспективе перехода от монолита к микросервисам: «На микросервисы следует переходить, когда проект достигает такого масштаба, что начинаешь понимать, что ничего не понимаешь из того, о чем говорят твои коллеги, вносящие коррективы в проект».
Как бы смешно это ни казалось, практика показывает, что все происходит из-за непонимания .
Какая судьба ждет монолит при переходе на микросервисы? [18:58]
Раскроем секрет: Почти ни один монолит не «разрезан» до конца; оно все еще продолжает жить в той или иной форме.
Он рассказал о том, что происходит с монолитом после «разрезания» Майкл : «Если рассматривать идеальные условия, то от монолита остается условный основной сервис, который знает, куда перенаправлять запросы и как взаимодействовать с другими компонентами проекта».
Серебряная пуля Фредерика Брукса
Стоит ли использовать RabbitMQ для связи между микросервисами? [9:54]
Правильнее было бы сказать, что на этот вопрос (как и на все последующие) нет однозначного ответа.Дело в том, что выбор технологий, методологий и протоколов зависит от ряда условий, среди которых:
- порог входа;
- хронология развития проекта, т.е.
стек, который уже используется и не нуждается в глобальной реструктуризации;
- наличие альтернативных вариантов;
- простота интеграции и сроки;
- и так далее.
Однако серебряной пули не существует. «Вы можете использовать любой MQ, который покажется удобным разработчику или команде разработчиков» , - уверенно отвечает Денис .
Майкл дополняет ответ: «Выбор технологии зависит от набора уже используемых в проекте решений, а также от уровня предельной интеграции; неважно: Rabbit, Kafka или Redis Pub/Sub — выбор зависит от архитектора».
Как лучше всего объединить таблицы из разных микросервисов? Потоки Kafka или ключи SQL? [32:50]
«Нужно сначала посмотреть, как вы ранее объединяли в монолит различные таблицы, относящиеся к отдельным сервисам.Приоритетным вариантом является реализация уже знакомых разработчику методов.
Если нет возможности использовать старые разработки в новом проекте, то нужно понять, что будет проще интегрировать на этом этапе.
С этого стоит начать в первую очередь»,
- ответы Денис .На какие показатели следует смотреть, когда возникает вопрос о «распиливании» монолита? Если вы решили перейти на микросервисную архитектуру, на это были определенные причины: попытка сделать продукт независимым от определенного набора технологий или стремление к качественному масштабированию.
Но стоит ли игра свеч? Для принятия решения и вынесения вердикта необходимо выбрать набор показателей, определить список вопросов, ответив на которые, можно без лишних сожалений действовать дальше.
Именно такой подход считает наш эксперт Денис : «В первую очередь этот вопрос касается непосредственно команды разработчиков.
Здесь необходимо оценить ситуацию: прибыль, которую можно извлечь, и затраты, которые мешают развитию проекта.
Если по этим показателям вы понимаете, что от микросервисов больше пользы, чем от монолита, дерзайте!»
Архитектура, развертывание и шлюз API
Следует признать, что иногда серебряная пуля возможна, поскольку существует общий набор руководящих принципов и технических соглашений, касающихся организации отдельных компонентов.
Денис и Михаил постарались дать качественные ответы на многочисленные технические вопросы.
Мы собрали здесь самые интересные из них.
Зачем вам нужен API-шлюз в качестве единой точки входа? [8:30]
Короче говоря, всегда удобнее, когда фронтенд «не думает» о том, где запросить у бэкенда тот или иной набор данных.То есть мы считаем, что у нас есть точка входа, позволяющая независимо от того, с какого устройства вы отправили запрос, получить ответ. Именно шлюз API имеет прерогативу определять, куда и что доставлять в рамках конкретной задачи.
вот как это работает Где развернуть микросервисное приложение? Легенда.
У спрашивающего был монолит, и он разбил его на сервисы, упакованные в Docker. Что выбрать: заказать виртуальную машину и развернуть на ней все или воспользоваться услугами облачного провайдера? Этот вопрос тесно связан со специализацией Михаил .
Поэтому он дал исчерпывающий ответ с позиции DevOps-инженера: «В целом, некоторые микросервисы можно поднять в Docker-кластере, некоторые можно пересмотреть для запуска их в лямбдах, если они не нужны на постоянной основе.
В остальных случаях, если это какой-то небольшой микросервис, не генерирующий больших нагрузок, стоит воспользоваться услугами того же Amazon. Если мы используем собственную виртуальную машину, то нам нужно быть уверенными, что рядом с нашим «стендом» будет человек, который сможет поддерживать его в штатном режиме».
Кто несет ответственность за общий код двух микросервисов? [30:10]
Денис поделился своим опытом со зрителями.Он смог определить два сценария:
- Если это серьезный проект Enterprise, то должен быть ответственный архитектор, который сам будет определять определенные зоны ответственности.
- В случае, когда речь идет о более «спонтанном» проекте, командам придется учиться договариваться и при тестировании добавлять дополнительный слой, отвечающий за проверку совместимости версий интерфейса.
В случае не очень большого проекта, где по устоявшемуся обычаю процессы разработки протекают так, что конфликтов на основе разделения обязанностей обычно не возникает, стоит использовать умение «договариваться».
Какие советы по созданию устойчивой микросервисной архитектуры? [57:23]
Легенда.Предположим, внутри системы есть цепочка независимых сервисов, которые общаются «друг с другом» через API. Как правильно откатить транзакцию, если в цепочке запросов микросервисов произошел сбой? Отдельные действия делать по откату к предыдущему сервису? «По своему опыту могу сказать, что распределенные транзакции — это дорогой и, как правило, неудобный подход. Лучше «урезать» логику, чтобы одну большую транзакцию можно было разделить на несколько мелких, которые будут работать вполне нормально.
Вам также следует научить свои микросервисы обрабатывать повторяющиеся запросы, если что-то пойдет не так.
С точки зрения реализации существует множество паттернов, которые используются в том же Netflix, а также значительно упрощают процесс написания кода».
- думает Денис .
Если у нас несколько реплик микросервиса и мы используем распределенный кеш, то нужно ли сбрасывать кеш, если объект кеша изменился в новой версии микросервиса? [1:01:07]
«Это проблема любой сериализации.Если обратной совместимости нет, то, конечно, придется.
Поэтому, когда мы говорим о какой-либо сериализации (с кешем или без него), всегда очень важно использовать модель, обеспечивающую обратную совместимость.
Речь идет о вопросе про Java, а именно о том, почему нельзя использовать встроенную в язык сериализацию»,
- ответил Денис .
Какую литературу рекомендуют прочитать профессионалы?
Конечно, невозможно исчерпывающе ответить абсолютно на все вопросы зрителей Хабрамитапа.Для более осознанного погружения в тему необходимо изучить специализированные ресурсы: литературу или блоги.
На трансляции отдельно спросили: как правильно разделить монолит на слои? Денис ответил на вопрос следующим образом: «Сервис — как любой монолит: когда его пишешь, не знаешь всего заранее.
В будущем база данных может измениться, например.
Поэтому в любом случае для таких больших модулей (для работы с базами данных и т.п.
) стоит писать какие-то адаптеры, которые позволят легко перейти на любую другую технологию.
Для некоторых ключевых вещей еще нужно разработать адаптеры, как в монолите».
Итак, какие книги стоит прочитать по теме? Эксперт не оставил этот вопрос без ответа: «В целом, я рекомендую сначала обратиться к ресурсам британского программиста и писателя Мартина Фаулера, чтобы лучше понять тему и, в частности, архитектурные подходы к созданию микросервисных продуктов».
Майкл Однако новичкам он советует обратиться к литературе издательства «О’Рейли», которая сейчас активно переводится на русский язык.
При этом он отметил, что книга Сэма Ньюмана «Создание микросервисов» — хорошее место для начала изучения микросервисов.
У Сэма есть еще несколько крутых работ по микросервисам, но они еще ждут перевода на русский язык.
Также стоит уделить время чтению блогов компаний: Atlassian, Nginx и т. д. Часто организации размещают инсайдерскую информацию, описывающую устройства тех или иных сервисов, что, несомненно, может быть полезно не только новичкам, но и опытным.
.
Заключение
Отличительной чертой современного мира является разнообразие технологий.Без сомнения, вам необходимо создать продукт, устойчивый к мимолетным изменениям.
Именно микросервисы позволяют добиться такой «независимости».
Благодаря им можно не привязываться к конкретным технологиям, легко масштабировать проект, упрощать его обслуживание и строить более отказоустойчивые решения.
Наряду со всеми преимуществами важно отметить, что микросервисы — далеко не «философский камень».
Потому что есть набор условностей и недостатков.
Например, в некоторых случаях тестирование микросервисных архитектур сложнее, а отслеживание версий еще более проблематично.
Также микросервисы имеют высокий барьер входа для специалистов, а код на бэкенд-стороне может существенно увеличиться в объёме.
Тем не менее возможные проблемы не должны пугать специалистов.
Напротив, они призывают современных гениев научиться разделять и властвовать.
Благодарим Хабр за возможность выступить на веб-трансляции Хабр Про.
Надеемся, что в будущем профессиональные дороги снова сведут нас вместе и мы сможем проводить еще больше хабрамитапов для наших слушателей и читателей.
Будем рады услышать ваше мнение в комментариях.
Теги: #DevOps #Микросервисы #sre #микросервисная архитектура
-
Хевеши, Джордж Де (Диерд)
19 Oct, 24 -
Карты Google 4.1
19 Oct, 24 -
Delivery-Club - Единая Система Заказов
19 Oct, 24
