[Анализ и проектирование систем, IT-инфраструктура, DevOps, Микросервисы] Микросервисы: почему это не панацея?
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В последние годы только ленивый не слышал о микросервисах. «Долой монолитную архитектуру, микросервисы — это будущее веб-разработки!» — об этом трубят буквально все компании, в технологическом стеке которых появились Kubernetes и начали внедряться практики DevOps.
Вот только стоит ли вам что-то менять в софте, если и так все работает? Давайте разбираться.
Микросервисная архитектура: что это?
Микросервисная архитектура — это подход к веб-разработке, при котором приложение разбивается на множество частей, каждая из которых выполняет какую-то единственную функцию. Каждый микросервис «привязан» к отдельному домену (используя при этом автономное хранилище с данными и не зависимые от внешних модулей средства для связи с этим хранилищем) и может быть развернут независимо.
Сегодня микросервисы выступают главным антагонистом монолитной архитектуры, где вся бизнес-логика взаимосвязана между собой.
Связь микросервисов друг с другом: меньше зависимостей, больше универсальности
С точки зрения конечного пользователя, разница между монолитной и микросервисной архитектурой будет заметна только тогда, когда он столкнется с неправильной работой системы, ведь в случае с монолитными приложениями, багов может быть намного больше. А все — из-за большого количества зависимостей.
Поэтому, чтобы сократить число ненужных связей, микросервисы взаимодействуют друг с другом через универсальные API. По мере необходимости, в дальнейшем, вы сможете подключать новые и отключать уже ненужные блоки, не теряя при этом жизнеспособности обновленного ПО.
Какие технологии используются для создания микросервисной архитектуры?
Чаще всего для создания микросервисов используются инструменты Docker (для контейнеризации) и Kubernetes (для оркестровки контейнеров), идеальные для развертывания в корпоративных средах.
Конечно же, вы всегда можете остановить свой выбор и на виртуальных машинах, однако в последнем случае вы будете вынуждены оплачивать даже минуты простоя вашего ПО.
Преимущества и недостатки микросервисов
Выясним плюсы и минусы микросервисов.
Плюсы:
- нет привязки к конкретным языкам и технологиям;
- простая интеграция со сторонними решениями и возможность повторного использования;
- практически бесконечная масштабируемость;
- простота обслуживания (управление серверной частью в монолитном ПО всегда было в ответственности владельца ПО, а в случае микросервисов все лежит в компетенции облачного провайдера);
- отказоустойчивость;
- упрощенная симметричная архитектура приложения вместо иерархической (что свойственно для монолитных продуктов) с одноранговыми зависимостями между компонентами;
- внесение правок без рисков “обрушить” всю систему.
Минусы:
- процесс тестирования собранного воедино ПО сложный, потому что микросервисы базируются на отдельных доменах;
- миграция монолитной архитектуры в микросервисную может обойтись очень дорого;
- управлять версиями ПО становится сложнее;
- могут возникать проблемы с отзывчивостью, так как количество кода, исполняемого не стороне бэкенда, увеличивается;
- для развертывания микросервисов вам потребуются опытные специалисты.
Долой монолит. Да здравствуют микросервисы
По сравнению с монолитной архитектурой ПО, микросервисы практически всегда оказываются в выигрыше. Ведь в случае с моноблоком все связи, данные и функции работают как единое целое. То есть, если вы решите модернизировать ваш софт, это потянет за собой и дополнительные правки и во многих других компонентах приложения. А это — ваше время и деньги.
Кроме того, в случае монолита, если у вас “сломается” какой-то из кодовых блоков, обрушится и вся система. Поэтому рассчитывать на стабильную работу такого приложения точно не стоит.
С другой стороны, далеко не весь, изначально монолитный софт можно разбить на микросервисы без радикального рефакторинга кода (что тоже есть ваше время и деньги). Дело в том, что у вас в любом случае обнаружатся компоненты, которые с логической точки зрения могут функционировать автономно друг от друга, но на практике они созависимы.
Нужны ли вам микросервисы, если «и так все нормально работает»?
В 2019 году независимый опрос показал, что около 92% респондентов активно наращивают количество микросервисов в своих решениях для бизнеса, а около трети респондентов способны оценить преимущества нововведений уже в первые месяцы их внедрения. Правда, вместе с этим, еще около 50% компаний оказываются и вовсе в неведении, какие плюсы могут принести им эти технические инновации.
Так стоит ли игра свеч? Или же микросервисы — это очередное технологическое «ноу-хау», которое скоро устареет?
С учетом всех вышеперечисленных преимуществ, микросервисная архитектура должна казаться поистине настоящей панацеей для любого бизнеса. И правда, с учетом достаточно сложной структуры большинства современных приложений, без разделения их на отдельные модули выходит путаница, нерациональный расход человеческих ресурсов и возникновение кучи багов.
Тем не менее, существуют случаи, когда такое слепое следование IT-трендам выливается в проблемы с производительностью. Ведь, как мы знаем, каждый из микросервисов/веб-сервисов “привязывается” к отдельному источнику данных (СУБД). А это значит, что при одновременном использовании многих функций приложения подобная его структура будет подразумевать синхронное выполнение не одного десятка пользовательских запросов. И чем больше будет микросервисов-компонентов приложения, тем будет больше рисков того, что сервер окажется перегруженным.
Поэтому разработчикам приходится оставлять более крупногабаритные модули, связи в которых выстраивались бы без участия сетевых протоколов. Они несут меньшую нагрузку на сервер и снижают риски DDoS-атак.
Еще одна проблема микросервисов заключается в отсутствии стандартизации. Изначально разработчики редко заморачиваются над согласованием форматов. При взаимодействии микросервисов друг с другом это упущение может повлечь за собой ошибки, здорово усложнить процедуру отладки и увеличить общее количество трудноустранимых багов.
И наконец, переход на микросервисы может оказаться слишком дорогим. Наверняка вы могли столкнуться с проблемой того, что некоторые компоненты, которые, по идее, можно было бы разделить между собой на отдельные микросервисы, в пределах существующего функционала работают неразрывно друг от друга. Полностью переписывать их — затея далеко не всегда рациональная.
В таких ситуациях имеет смысл задействовать веб-сервисы — частный вариант сервис-ориентированной архитектуры, который описывает механизмы взаимодействия API с основной кодовой базой, используя универсальные форматы представления данных XML, JSON и т.д., а также стандартный протокол HTTP. При этом, как и микросервисы, веб-сервисы не имеют привязки к языку разработки или программной платформе.
При таком компромиссном решении вы сможете сохранить производительность вашего приложения, а также снизить себестоимость его миграции на новую архитектуру.
Заключение
Как видим, микросервисы — это не лекарство от всех болезней, а всего лишь один из подходов к обеспечению масштабируемой и простой в управлении архитектуры ПО. Обычно их внедряют глобальные корпорации, такие, как Google, Netflix и Amazon, которые предлагают конечным пользователям тысячи отдельных услуг. С другой стороны, изначально выбранная микросервисная архитектура ПО станет хорошим фундаментом для построения гибкой и отказоустойчивой системы.
Поэтому — внимательно взвесьте все плюсы и минусы, оцените риски и только тогда уже ищите разработчиков.
На правах рекламы
Многие наши клиенты уже оценили преимущества эпичных серверов!
Это недорогие виртуальные серверы с процессорами AMD EPYC, частота ядра CPU до 3.4 GHz. Максимальная конфигурация позволит оторваться на полную — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe. Поспешите заказать!
оригинал
===========
Источник:
habr.com
===========
Похожие новости:
- [IT-инфраструктура, Компьютерное железо] Как мейнфреймы не вымерли
- [Высокая производительность, Тестирование IT-систем, Анализ и проектирование систем, Разработка на Raspberry Pi] История про Гену, Чебурашку и тестирование производительности реактивного приложения, работающего на Raspberry Pi
- [DevOps] Использование JSON в Kibana поиске (перевод)
- [Системное администрирование, IT-инфраструктура, *nix, Софт] FreeBSD. Путь сетевого пакета внутри ядра
- [Системное администрирование, DevOps, Kubernetes] Стримхата: ломаем яичницу и жарим Кубернетес
- [Программирование, Разработка игр, Игры и игровые приставки] Портируем DOOM на serverless-платформу (перевод)
- [Программирование, Управление проектами, Облачные сервисы, Микросервисы] О мифологии миграции монолита в облака
- [DevOps, Распределённые системы, Микросервисы, Kubernetes] Первый митап Почтатеха «DevOps на набережной»
- [DevOps] Создание вашего первого модуля Ansible (перевод)
- [Анализ и проектирование систем, Управление разработкой, Управление продуктом] Курсы PowerPoint за 2 года
Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_itinfrastruktura (IT-инфраструктура), #_devops, #_mikroservisy (Микросервисы), #_mikroservisy (микросервисы), #_vebservisy (веб-сервисы), #_blog_kompanii_vdsina.ru (
Блог компании VDSina.ru
), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_itinfrastruktura (
IT-инфраструктура
), #_devops, #_mikroservisy (
Микросервисы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 15:09
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 В последние годы только ленивый не слышал о микросервисах. «Долой монолитную архитектуру, микросервисы — это будущее веб-разработки!» — об этом трубят буквально все компании, в технологическом стеке которых появились Kubernetes и начали внедряться практики DevOps. Вот только стоит ли вам что-то менять в софте, если и так все работает? Давайте разбираться. Микросервисная архитектура: что это? Микросервисная архитектура — это подход к веб-разработке, при котором приложение разбивается на множество частей, каждая из которых выполняет какую-то единственную функцию. Каждый микросервис «привязан» к отдельному домену (используя при этом автономное хранилище с данными и не зависимые от внешних модулей средства для связи с этим хранилищем) и может быть развернут независимо. Сегодня микросервисы выступают главным антагонистом монолитной архитектуры, где вся бизнес-логика взаимосвязана между собой. Связь микросервисов друг с другом: меньше зависимостей, больше универсальности С точки зрения конечного пользователя, разница между монолитной и микросервисной архитектурой будет заметна только тогда, когда он столкнется с неправильной работой системы, ведь в случае с монолитными приложениями, багов может быть намного больше. А все — из-за большого количества зависимостей. Поэтому, чтобы сократить число ненужных связей, микросервисы взаимодействуют друг с другом через универсальные API. По мере необходимости, в дальнейшем, вы сможете подключать новые и отключать уже ненужные блоки, не теряя при этом жизнеспособности обновленного ПО. Какие технологии используются для создания микросервисной архитектуры? Чаще всего для создания микросервисов используются инструменты Docker (для контейнеризации) и Kubernetes (для оркестровки контейнеров), идеальные для развертывания в корпоративных средах. Конечно же, вы всегда можете остановить свой выбор и на виртуальных машинах, однако в последнем случае вы будете вынуждены оплачивать даже минуты простоя вашего ПО. Преимущества и недостатки микросервисов Выясним плюсы и минусы микросервисов. Плюсы:
Минусы:
Долой монолит. Да здравствуют микросервисы По сравнению с монолитной архитектурой ПО, микросервисы практически всегда оказываются в выигрыше. Ведь в случае с моноблоком все связи, данные и функции работают как единое целое. То есть, если вы решите модернизировать ваш софт, это потянет за собой и дополнительные правки и во многих других компонентах приложения. А это — ваше время и деньги. Кроме того, в случае монолита, если у вас “сломается” какой-то из кодовых блоков, обрушится и вся система. Поэтому рассчитывать на стабильную работу такого приложения точно не стоит. С другой стороны, далеко не весь, изначально монолитный софт можно разбить на микросервисы без радикального рефакторинга кода (что тоже есть ваше время и деньги). Дело в том, что у вас в любом случае обнаружатся компоненты, которые с логической точки зрения могут функционировать автономно друг от друга, но на практике они созависимы. Нужны ли вам микросервисы, если «и так все нормально работает»? В 2019 году независимый опрос показал, что около 92% респондентов активно наращивают количество микросервисов в своих решениях для бизнеса, а около трети респондентов способны оценить преимущества нововведений уже в первые месяцы их внедрения. Правда, вместе с этим, еще около 50% компаний оказываются и вовсе в неведении, какие плюсы могут принести им эти технические инновации. Так стоит ли игра свеч? Или же микросервисы — это очередное технологическое «ноу-хау», которое скоро устареет? С учетом всех вышеперечисленных преимуществ, микросервисная архитектура должна казаться поистине настоящей панацеей для любого бизнеса. И правда, с учетом достаточно сложной структуры большинства современных приложений, без разделения их на отдельные модули выходит путаница, нерациональный расход человеческих ресурсов и возникновение кучи багов. Тем не менее, существуют случаи, когда такое слепое следование IT-трендам выливается в проблемы с производительностью. Ведь, как мы знаем, каждый из микросервисов/веб-сервисов “привязывается” к отдельному источнику данных (СУБД). А это значит, что при одновременном использовании многих функций приложения подобная его структура будет подразумевать синхронное выполнение не одного десятка пользовательских запросов. И чем больше будет микросервисов-компонентов приложения, тем будет больше рисков того, что сервер окажется перегруженным. Поэтому разработчикам приходится оставлять более крупногабаритные модули, связи в которых выстраивались бы без участия сетевых протоколов. Они несут меньшую нагрузку на сервер и снижают риски DDoS-атак. Еще одна проблема микросервисов заключается в отсутствии стандартизации. Изначально разработчики редко заморачиваются над согласованием форматов. При взаимодействии микросервисов друг с другом это упущение может повлечь за собой ошибки, здорово усложнить процедуру отладки и увеличить общее количество трудноустранимых багов. И наконец, переход на микросервисы может оказаться слишком дорогим. Наверняка вы могли столкнуться с проблемой того, что некоторые компоненты, которые, по идее, можно было бы разделить между собой на отдельные микросервисы, в пределах существующего функционала работают неразрывно друг от друга. Полностью переписывать их — затея далеко не всегда рациональная. В таких ситуациях имеет смысл задействовать веб-сервисы — частный вариант сервис-ориентированной архитектуры, который описывает механизмы взаимодействия API с основной кодовой базой, используя универсальные форматы представления данных XML, JSON и т.д., а также стандартный протокол HTTP. При этом, как и микросервисы, веб-сервисы не имеют привязки к языку разработки или программной платформе. При таком компромиссном решении вы сможете сохранить производительность вашего приложения, а также снизить себестоимость его миграции на новую архитектуру. Заключение Как видим, микросервисы — это не лекарство от всех болезней, а всего лишь один из подходов к обеспечению масштабируемой и простой в управлении архитектуры ПО. Обычно их внедряют глобальные корпорации, такие, как Google, Netflix и Amazon, которые предлагают конечным пользователям тысячи отдельных услуг. С другой стороны, изначально выбранная микросервисная архитектура ПО станет хорошим фундаментом для построения гибкой и отказоустойчивой системы. Поэтому — внимательно взвесьте все плюсы и минусы, оцените риски и только тогда уже ищите разработчиков. На правах рекламы Многие наши клиенты уже оценили преимущества эпичных серверов! Это недорогие виртуальные серверы с процессорами AMD EPYC, частота ядра CPU до 3.4 GHz. Максимальная конфигурация позволит оторваться на полную — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe. Поспешите заказать!  оригинал =========== Источник: habr.com =========== Похожие новости:
Блог компании VDSina.ru ), #_analiz_i_proektirovanie_sistem ( Анализ и проектирование систем ), #_itinfrastruktura ( IT-инфраструктура ), #_devops, #_mikroservisy ( Микросервисы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 15:09
Часовой пояс: UTC + 5