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

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

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

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

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

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

1. У микросервисов есть чётко очерченные интерфейсы. Твой IAccountService можно прикастовать к AccountService и через reflection поменять ему какие-нибудь приватные переменные, хе-хе. Да, это плохо, но если есть возможность, такое будет. Причём снаружи этого видно вообще не будет, это можно увидеть только читая код пользователей класса. Микросервис это, скажем, HTTP-интерфейс и все входы-выходы обычно документированы так или иначе.

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

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