Здравствуйте, Shmj, Вы писали:

S>В чем смысл микросервисов?

S>Ты для каждого компонента ваяешь HTTP-API (как правило), для каждого компонента делаешь свою DB (часто). Зачем?

S>Что мешает тебе просто создать класс AccountService и определить для него интерфейс IAccountService стандартными средствами? Ведь в таком случае тебе не нужно будет трафик гнать для внутреннего взаимодействия.

S>Далее. Как ты решаешь вопрос с транзакциями? Это ж тебе жуткие костыли придется ваять.

S>Зачем все это? Ради чего?

— Повторное использование. микросервисы проще использовать повторно, чем библиотеки, т.к. библиотеке нужна конфигурация, конкретные зависимости, иногда конкретная платформа или ОС.
— Версионирование. Можно развернуть несколько версий микросервиса и использовать их совместно из множества приложений. С библиотекой это сложнее.
— Изоляция по данным. Это очень важно, т.к. маленькую БД намного легче поддерживать, оптимизировать и кешировать.
— Изоляция по коду. При рефакторинге можно не затрагивать другие микросервисы по принципу "работает — не трогай". При наличии хорошей документации можно использовать микросервис без необходимости смотреть исходный код.

Еще побочные плюсы, вытекающие из микросервисной архитектуры:
— Масштабирование. В целом, монолитные приложения масштабируются хорошо, в отличие от огромной БД монолитного приложения. И наличия внутреннего состояния, которым грешат монолиты.
— Жесткие границы отдельных микросервисов, препятствующие превращению системы в лапшу.
— Устойчивость к отказам. Отказ от транзакций и необходимость тщательной обработки ошибки позволяет строить системы, адекватно реагирующие на перегрузку и отказ отдельных компонентов.

И минусы:
— Сложность. Микросервисная архитектура требует огромных вложений в единую архитектуру системы, девопс, мониторинг, логгирование и аналитику.
— Еще раз сложность. Правильно разбить еще не написанное приложение на микросервисы — задача нетривиальная и при ошибке реализация каждой фичи затрагивает множество микросервисов, что серьезно стопорит разработку
— И еще раз сложность. Отказ от распределенных транзакций и сетевое взаимодействие требуют очень вдумчивого подхода к обработке ошибок.