JavaRush /Java блог /Random /Микросервисная архитектура: плюсы и минусы
Roman Beekeeper
35 уровень

Микросервисная архитектура: плюсы и минусы

Статья из группы Random
Микросервисы - это путь разбиения большого приложения на слабо связанные модули, которые коммуницируют друг с другом посредством просто API.
Микросервисная архитектура: плюсы и минусы - 1
Последнее время о микросервисах не говорит разве что немой. Это становится все популярнее. Модульный архитектурный стиль кажется особенно хорошо подходит для облачных сред(cloud-based environment) и его популярность растет. Предже чем углубиться в детали, давайте посмотрим на все "с высоты птичьего помета полета". Поэтому: Микросервисы - это способ разбиения большого проекта на небольшие, независимые и слабо связные модули. Независимые модули отвечают за четко отпределенные и дискретные задачи и общаются друг с другом посредством простого и доступного API. Другими словами - микросервисы это просто другой архитектурный стиль для проектирования сложных, в основном, веб-приложений. Но что такого плохого существующих архитектрных решениях, таких как SOA( Service oriented architecture — сервисно огриентированная архитектура)? Большинство современных ентерпрайз-решений написаны с использованием SOA, похоже работают довольно хорошо. Пожалуй, это отличное время для того, чтоб поговорить о некоторых вызовах в индустрии, с которыми сталкиваются в наше время... Давайте начнем с простого примера. Допустим, мне нужно запустить классическое приложение написанное на Java. Первым я разработаю User Interface, потом слой с бизнес логикой, причем несколько компонентов, которые будут взаимодействовать с UI и, наконец, слой для базы данных, который будет доступен к устойчивой базе данных. Теперь в соотвествии с тем, что я хочу запустить приложение, я создам WAR/EAR/JAR и смонтирую его на сервер(таких как JBoss, Tomcat или WebLogic). Так как сделано это все в одном, я получаю монолитное приложение, что означает, что все компоненты в одной месте... Пример на картинке:
Микросервисная архитектура: плюсы и минусы - 2
Скорее всего, что вы уже знакомы с таким подходом и использовали его, но идея именно в том, что бы на этом примере показать с какими вызовами придется столкнуться разработчикам используя это архитектурное решение. Монолитное приложение: вызовы проблемы
  • Во время того, как растет приложение, растет и количество написанного кода, которое вполне может перегружать среду разработки каждый раз, когда нужно открыть его. Это определенно уменьшает КПД разработчика.
  • Так как приходится все монтировать в одном месте, это приводит к тому, что переход на другой язык программирования или переход на другие технологии является большой проблемой. Например, вы написали приложение на Java, а через время вышел Kotlin и вы загорелись желанием переписать на него, потому что он распиарен круче-лучше-быстрее. С моноличным приложением даже мысли о рефакторинге будут приничинять реальную боль, не говоря уже о самом процессе. В данный момент есть множество приложений, которые сделаны таким образом и количество строк кода просто невероятно.
  • Если какой-либо из компонентов по какой-либо причине накроется медным тазом перестанет работать, то все приложение также рухнет. Только представте, что есть веб-приложение, в котором есть модули, такие как, авторизация, оплата, история и тд. И по какой-то причине один из них ломается. Это просто шок для бизнеса и, в следствии, для разработчиков.
  • Масштабирование монолитного приложения может быть осуществлено только посредством поднятия еще одного такого же приложения. А что если требуется масштабтрование только одного компонента, а не всего приложения. Сколько ресурсов будет потрачено впустую?...
  • Это может оказать большое влияние на процесс разработки и на процесс монтирования приложения. Чем больше приложение, тем более важно, чтоб разработчики могли разделить приложение на более меклие рабочие части. Потому что все модули в монолитном приложении связаны друг с другом, разработчики не могут работать/монтировать независимо друг от друга эти модули. Так как разработчики зависят друг от друга, время разработчки увеличивается.
Вместе с тем, мы готовы рассмотреть и понять смысл микросервисов, а именно как их можно использовать для восстановления гибкости, которая была потеряна с SOA-стилем. Бог Микросервисы в помощь Одна из самых важных характеристик в любом архитектурном решение - это масштабируемость. Пока я первый раз изучал микросервисы, я видел, что все так похоже на цитаты из книги "Исскуство Машстабирования(The Art of Scalability)". Это отличное начало и место для обсуждения. В этой книге определяют так называемую модель "Куба Масштабируемости", который описывает трехмерную систему масштабируемости:
Микросервисная архитектура: плюсы и минусы - 3
Как вы видите, ось X описывает "горизонтальное масштабирование"(которое мы видели также доступно для монолитной архитектурой), ось Y предствляет собой машстабирование в смысле разделения разных компонентов серсисов. Идея Z оси понимается когда данные разделяются и приложение отправляет запросы именно на то место, где находятся данные. То есть они не в одном месте все. Идея оси Y - именно та, на которой мы остановимся подробнее. Эта ось представляет собой функциональную декомпозицию. В этой стратегии, различные функции можно рассматрировать как независимые сервисы. Поэтому, вместе монтирования цельного приложение только тогда, когда все сделано, разработчики могут монтировать отдельные сервисы независимо друг от друга и не ждать других, пока те закончат работу над своими модулями. Это не только улучшит время разработки, но также предлагает гибкость в изменении и перемонтировании без необходимости волноваться об остальных компонентах приложения. Сравним эту диаграмму с предыдущей монолитной:
Микросервисная архитектура: плюсы и минусы - 4
Микросервисы: преимущества Преимущества микросервисов выглядят вполне достаточными что убедили таких ентерпрайз-разработчиков, как Amazon, Netflix, Ebay - начать использовать этот подход. В отличии от монолитных архитектурных приложений, микросервисы:
  • Улучшает изоляцию сбоя компонентов: большие приложения можут продолжить эффективно работать, даже при неисправности какого-то отдельного модуля.
  • Устраняет приверженность приложения к одному технологическому стеку: если хочешь попробовать новый технологический стек на каком-то сервисе - пожалуйста. Зависимости будут гораздло легче, чем при монолитном, к тому же будет намного проще откатить все вспять. Чем меньше кода в одном приложении, тем легче работать.
  • Делает намного проще для новых сотрудников, чтобы понять функционаьность сервиса.
Микросервисы: особенности монтирования и виртуализации Теперь нам понятно, что такое микросервисы. И наибольшее преимущество, что монтируется не одним WAR/EAR/JAR архивом. Но как он монтируется? Самый лучший способ монтирования микросервисов внутри контейнеров. Контейнер - это полностью настроеная виртуальная операционная система с настроенным необходимым окружением, которое помогает изолировать доступ к ресурсам системы железа, на котором стоит контейнер. Самое известное решение на рынке - это конечно Docker. Виртуальные машины от IaaS(инфраструктура как сервис), такие как AWS могут также отлично работать для монтирования микросервисов, но относительно легковесные микросервисы могут использовать не все ресурсы, которые есть в виртуальной машине, могут уменьшить выгодность в использовании. Так же вы можете монтировать свои микросервисы используя OSGI(Open Service Gateway Initiative) пакет. В этом случае все микросервисы будут запущены в одной JVM, но это связано с проблемами компромиса между управлением и изоляцией. Микросервисы: недостатки Только из-за того, что "все это круто" и "как мы раньше этого не видели", не означает, что нет своих недостатков. Ниже приведен список возможных областей боли, которая приносит с собой микросервисная архитектура:
  • Разработка распределенных систем может быть трудной. Под этим я подразумеваю, что все компоненты теперь независимые сервисы - нужно очень аккуратно обрабатывать запросы проходящие между модулями. Может быть сценарий, когда один модуль не отвечает, заставляя писать дополнительный код, чтобы избежать сбоя системы. Это может быть сложнее, если удаленные вызовы чувствительны к latency.
  • Множество баз данных и управление транзакций может быть реальной болью.
  • тестирование микросервисных приложений может быть громоздко. Используя монолитное приложение, нам нужно только запустить WAR/EAR/JAR архив на сервер и убедиться в связи с базой данных. А в микросервисах, каждый отдельный сервис должен быть запущен перед тем, как начать тестирование.
  • Монтирование приложений может быть сложным. Они могут требовать координации вокруг множества сервисов, которые могут быть не так просто монтироваться, как WAR контейнер.
.... Конечно, с правильными инструментами и подходами можно избежать эти недостатки. Но они и сами требуют поддержки и не полностью решают все проблемы. Статья была переведена с сайта CloudAcademy. Перевод вольный. Все вольны излучать все свои мысли в комментариях. Они будут обязательно прочитаны. Оригинал статьи Мой Github aккаунт
Комментарии (4)
ЧТОБЫ ПОСМОТРЕТЬ ВСЕ КОММЕНТАРИИ ИЛИ ОСТАВИТЬ КОММЕНТАРИЙ,
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ
comrade_b Уровень 39
1 июля 2022
Roman Beekeeper Уровень 35
11 марта 2021
⚡️UPDATE⚡️ Друзья, создал телеграм-канал 🤓, в котором освещаю свою писательскую деятельность и свою open-source разработку в целом. Не хотите пропустить новые статьи? Присоединяйтесь ✌️
Сергеев Виктор Уровень 40 Master
18 октября 2018
"Только представте, что есть веб-приложение, в котором есть модули, такие как, авторизация, оплата, история и тд. И по какой-то причине один из них ломается. Это просто шок для бизнеса и, в следствии, для разработчиков." Как ни странно, если в микросервисной архитектуре отвалится модуль авторизации, оплаты, истории и т.д. шок для бизнеса будет не меньше и, в следствии, для разработчиков. )