В чем разница между микросервисами и монолитным подходом для предоставленного варианта использования

Question

Итак, я начал читать некоторые вещи о различных архитектурах программного обеспечения и неизбежно наткнулся на архитектуру Microservices.Тем не менее, мне интересно, как эти архитектуры отличаются друг от друга.При монолитическом подходе я бы, например, изменил POM.XML, чтобы взять разные слои и упаковать их в одно приложение для его развертывания.Я бы сказал, что это может быть даже самый распространенный способ настройки простого приложения.

Теперь, когда я понял, что такое Microservices, вы отделяете все службы друг от друга и позволяете им работать независимо.Для меня это означает, что каждый сервис развертывается самостоятельно (поэтому у вас есть tomcat, работающий с довольно большим количеством .war -файлов на нем. Но я думаю, что мне не хватает разницы с монолитным приложением.

Я собираюсь установить (довольно распространенный) пример:

У вас есть веб-интерфейс (например, Angular) с Spring-Boot Backend, взаимодействующим через REST -Услуги. Теперь явозьмите POM.XML и выполните следующие шаги:

• создайте Frontend-приложение
• включите необходимые JS-файлы в мое Spring-приложение
• create WAR -файл из проекта

В результате я получил один WAR -файл, который я могу развернуть, но получил два включенных сервиса: Backend и Frontend. Однако я бы назвал его монолитнымподход.

Теперь, когда я включу Angular -приложение в свой tomcat и разверну WAR -файл моей Spring-Boot части приложения (без интегрированного внешнего интерфейса).две развернутые службы, работающие на одном сервере• взаимодействуют друг с другом, и их можно заменить, не касаясь друг друга.По определению я бы не назвал это монолитным подходом (один и тот же код, другое развертывание), а микросервисной архитектурой, верно?Но это не может иметь место, так как буквально каждая статья, которую я прочитал, рассказывала мне об одних и тех же преимуществах и недостатках для архитектур, и я не вижу никакой разницы, кроме возможности обменивать интерфейс и бэкэнд (который у меня есть в обоих случаях, но в одной я бынеобходимо заново развернуть полное приложение в первом случае).

Answer 1

Spliting Frontend от Backend - не лучший / канонический пример развертывания микросервисов;это эквивалентно наличию слоев в монолите.Подумайте о том, как бы вы разбили свой монолит по (суб) домену на модули, каждый из которых имеет обязанности по внешнему интерфейсу и бэкэнду;тогда каждый модуль может стать микросервисом, если это необходимо.

Каноническая архитектура MS для веб-приложения - это шлюз, который собирает (в частности!) ответы HTML от разных MS.Таким образом, отдельные MS будут отвечать HTML, CSS и JS вместо JSON или другой неполной формы данных.Это принцип Tell Not Ask , применяемый к MS.Это дает вам настоящую MS, в которой вы очень легко можете заменить одну MS на другую.

Если шлюз не может собрать отдельные ответы параллельно, потому что они зависят друг от друга, тогда расщепление неверно, и вам нужно провести рефакторинг.

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

Если вы создаете свой монолит с использованием местоположения прозрачность , то вы можете развертывать компоненты как микроуслуги, не затрагивая код компонентов других.Например, если вы используете CQRS, вы можете развернуть Readmodel как микросервис, просто используя вырезание / вставку в коде, от монолита до микросервиса.

Answer 2

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

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

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

Далее при развертывании, особенно сегодня, важен масштаб, и вам необходимо адаптироваться к трафику.Все ваши модули не будут ожидать высокого трафика 24/7.Но если у вас есть монолит, даже если 100 пользователей используют один модуль, ваше приложение должно масштабироваться для 100 пользователей.

Микросервисы просто извлекают из этого информацию и определяют некоторые рекомендации

1. Вы должны разбить свое приложение на основе бизнес-доменов.Каждый сервис отвечает только за один аспект.Они общаются друг с другом через контракт (API или события), и пока контракт остается в силе, вы можете делать то, что вы хотите в рамках своего сервиса.Новому разработчику необходимо освоить только один сервис.

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

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

Для вашего случая, просто разверните его так, как вы хотите.Вы думаете, что лучше.Но если вы начнете расти, у вас будет около 50 странных услуг (или проект такого масштаба), вы увидите преимущества «разделяй и властвуй».