Как реализовываются микросервисные проекты?

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

Дополнительно:

Ответы:

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

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

Как конкретно ведётся разработка - это уже на откуп команде. Подход легко может различаться исходя из языка/платформы.

Это неважно. Можно для удобства накидать папки с проектами в одну папку и открывать её в IDE, а проекты оформить как модули. Но проекты могут разрабатываться на разных языках, разными командами и в разных местах. Тогда вы просто договариваетесь о контракте - протоколах, форматах, порядке обмена информацией между модулями, а дальше каждый пилит так как ему удобно.

  • то есть, если я создам Maven проект и просто в нем по создаю модулей, это тоже будет считаться полноценным микросервисом ?
  • Микросервисы - это модули, а "внешний" проект - это проект на микросервисах. А что это - просто папка или пустой Мавен-проект неважно.
    Другое дело что проект может содержать (а может и не содержать) другие части кроме микросервисов. Пример как это делается на Spring.

Это полностью проекто зависимая штука. К микросервисам стоит выростать из монолита. Микросервис по хорошему должен покрывать полностью конкретный домен, но им же и огранививаться. Вот тут как раз и кроется сложность. Если вы никогда не реализовывали проекты конкретной области, вероятнее всего вы разделите микросервисы не правильно, что усложнит и удорожает поддержку. В худшем сценарии ваши микросервисы будут чем-то вроде REST вокруг таблички в БД.

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

Пример плохого разделения для задачи отправки писем по событиям (регистрация, новости, маркетинг...):
Сервис_А подготавливает данные и дергает Сервис_Б, что бы тот запихнул их в шаблон и отправил почту.
Подход плохой потому, что каждое новое сообщение требует изменений И Сервис_А И Сервис_Б, причем синхронизированных.

Та же задача, но с более лучшим решением:
Сервис_А отправляет события в стиле "юзер зарегался", "юзер сделал покупку",... Сервис_Б самостоятельно решает, что и когда отправлять ползователю.
В этом случае Сервис_А и Сервис_Б зависят друг от друга по минимуму.

У меня есть проект, небольшой сервис на js/php он же вебморда. А так же ещё два сервиса один это сервис питоне, он слушает реббит подхватывает данные из него обрабатывает, как только закончил отправляет запрос в реббит о готовности. Вебморда слушает запрос когда работа первого сервиса закончена он отправляет эти данные уже обычным пост запрос на ещё один на ноде, тот если есть данные отдаёт их, если нет создаётся таска по завершении которой вебморда через реббит узнаёт. У каждого сервиса своя зона отвественности и свои языки. А общаться они через реббит и апи. А из себя представляют полноценные приложения способные работать и отдельно. В теории они могут быть и модулями.

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

+ Заказать

 

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

 

    • Как реализовываются микросервисные проекты?Есть ответ
    • 07.04.2024
    Ответить

    Для реализации микросервисных проектов необходимо следовать определенным принципам и практикам, которые помогут обеспечить масштабируемость, гибкость и надежность системы. Вот несколько шагов, которые помогут вам успешно реализовать микросервисный проект:

    1. Разделение функциональности: разбейте ваше приложение на небольшие, автономные сервисы, каждый из которых отвечает за конкретную функциональность. Это позволит упростить разработку, тестирование и масштабирование каждого сервиса.

    2. Использование API: обеспечьте взаимодействие между сервисами через API. Это позволит сделать сервисы более независимыми и уменьшить связанность между ними.

    3. Контейнеризация: используйте контейнеры, такие как Docker, для упаковки и запуска каждого сервиса. Это обеспечит изоляцию и портативность сервисов.

    4. Оркестрация: используйте инструменты для оркестрации контейнеров, такие как Kubernetes или Docker Swarm, для управления и автоматизации развертывания и масштабирования сервисов.

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

    Пример использования PHP для создания микросервиса:

    get('/hello/{name}', function ($request, $response, $args) {
    $name = $args['name'];
    $response->getBody()->write("Hello, $name");
    return $response;
});
 
$app->run();

    Это лишь общий набор рекомендаций и пример использования PHP для создания микросервиса. Каждый проект уникален и требует индивидуального подхода к реализации микросервисной архитектуры.

Оставить комментарий