Архитектура микросервисов от бизнес-подхода или технического? - PullRequest
Новая
       26

Архитектура микросервисов от бизнес-подхода или технического?

0 голосов
/ 02 мая 2018

Наша команда пытается отделить монолитное Spring MVC административное приложение (создать, обновить, удалить) , и мы хотим принять архитектуру, основанную на микросервисах,

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

Проблема возникает, когда мы читаем некоторые определения, например следующие из Википедия :

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

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

enter image description here

Итак, следует ли разрабатывать архитектуру микросервисов на основе бизнес-проблемы, которую она решает?

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

Спасибо.

Ответы [ 2 ]

0 голосов
/ 03 мая 2018

По моему опыту, наиболее очевидным преимуществом микросервиса является возможность горизонтального масштабирования. Анализ пользователя занимает много времени? Просто добавьте еще 10 рабочих. Готово. Убери потом. Не нужно добавлять больше ОЗУ / ЦП / что-либо еще на ваш дорогой сервер, на котором работает ваш монолит.

Не планируйте заранее попытку отделить микросервис ClientManager - это должен быть просто класс.

Вы думаете о миграции на микроуслуги по какой-то причине. Что-то использует слишком много ресурсов. Найдите наиболее проблемный процесс, который все замедляет, и создайте для него микросервис. Это может быть, например, создание отчетов, создание пользователей, агрегация данных. Начните с планирования API. В нем будет четко указано, какие обязанности он будет иметь и сколько ресурсов он будет использовать. Когда вы знаете, что он должен делать, назовите его правильно .

Методологии гибкого программного обеспечения - ваш лучший друг в этом процессе. Возьмите процессы один за другим. Экспериментируйте, повторяйте и оценивайте. Со временем станет очевидно, как должны действовать микросервисы.

Существует также горячая тема о том, как организовать код с помощью микросервисов - я склоняюсь к monorepo - единому хранилищу со всем кодом.

  • Плюсы: одноразовый запрос для многих сервисов, простое совместное использование утилит, общие зависимости, общая процедура развертывания и более простая автоматизация.
  • Минусы: вы можете легко разорвать контракт API и выполнять слишком много работы в одном микросервисе (т. Е. Это может привести к ответственности других сервисов.)
0 голосов
/ 02 мая 2018

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

  1. 60% вашего кода - это строительные леса, и его необходимо будет повторить для нескольких служб.

  2. Проще разделить вещи (и поддерживать их таким образом), если вы заранее установили правило «что происходит».

Наиболее распространенный подход - разделить приложение по областям функциональности. Поэтому, чтобы ответить на ваш вопрос, я бы больше согласился с изображением в правом верхнем углу, предполагая, что вы намеревались показать несколько контейнеров там.

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

...