Нужен ли микросервис?

Question

Нужен ли микросервис?

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

Примеры:

Компонент Symfony Security ACL (symfony/security-acl). Я мог бы обернуть его в микросервис, который добавил бы только уровень абстракции в виде REST API поверх API ACL Symfony Security. Кроме того, мне понадобится компонент сервисного агента, который устанавливается на зависимые микросервисы и обеспечивает доступ к микросервису ACL. В чем смысл? Не проще ли установить symfony/security-acl где это нужно и дать ему отдельное соединение с базой данных?
Система оплаты. В этом случае более понятно, что его нужно обернуть в микросервис. Он содержит огромный объем бизнес-логики, которая просто требует разделения.

В основном вопросы:

Какой критерий я должен учитывать при принятии решения о размещении части программного обеспечения в микросервисе, а не в модуле?
Это хорошая идея, чтобы обернуть symfony/security-acl в очень тонкий микросервис (разве это не хорошо для микросервиса быть тонким)?

-1

acl architecture microservices php symfony

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Неофициальные, ненаучные причины возникновения микросервисов, основанные на моем опыте:

Горизонтальная масштабируемость: Если ваши службы не масштабируются равномерно, вы можете иметь 10 серверов со службой A, но только 1 со службой B.
Ускоренное развертывание: Наличие отдельного процесса развертывания для каждой службы позволяет развертывать меньшие части по требованию, а не развертывать большие компоненты только из-за небольших изменений.
Независимый стиль разработки и жизненный цикл: Когда проект становится больше, вы можете захотеть, чтобы другие люди взяли его на себя. Это очевидно работает лучше с микросервисом, который имеет меньше зависимостей, чем модуль. Участники и команды могут развивать то, что они хотят, с тем, что они хотят. Каждая команда может использовать свой язык, разные конвейеры, инструменты тестирования, редакторы и т. Д. Единственным общим знаменателем являются форматы, протоколы и соглашения получающегося API.
Упрощенное управление зависимостямиОбновление или изменение библиотек, которые зависят от других библиотек, может привести к осложнениям, потому что, очевидно, не все ваши зависимости будут обновлены одновременно, и будут несовместимости.
Более понятный API: Документирование всех открытых классов и функций может быть кошмаром. С другой стороны, наличие API с неполной или устаревшей документацией — причина отказаться от проектов. Микросервисы не предлагают ничего готового в этом отношении, но интерфейсы четко определены, обычно как конечные точки URL и методы HTTP. Это станет проще, если вы будете следовать ОСТАЛЬНОЕ парадигма.

В вашем конкретном случае сложно сказать, что использовать, потому что вы не даете достаточно контекста. Некоторые из соответствующих вопросов:

Вы развиваетесь с командой?
Это часть каркаса?
Каковы зависимости модуля?
Он предназначен для параллельного доступа к БД?

2