Каков наилучший способ разбить логи приложения c на микросервисы?

Question

мы решили перенести применение монолита на микросервисы, мы находимся в стадии исследования, так как это наш первый опыт работы с микросервисами.

В настоящее время мы рассматриваем три типа микросервисов:

1. Api-шлюзы - использующие rp c для связи с доменными службами
2. Доменные службы - службы, инкапсулирующие разные часть logi c, связывающаяся со шлюзами через API, и asyn c события для связи друг с другом. У каждого есть своя база данных
3. Инфраструктурные сервисы - такие как электронная почта, смс и т. Д. c.

И пока у меня есть несколько вопросов о том, как правильно разделить логики домена c , некоторые лучшие практики и полезные ресурсы приветствуются. Также я приведу пример logi c и несколько разных способов его разделения.

Application logi c: У нас есть два шлюза api для интерфейса конечного пользователя admin api.

Приложение представляет собой вид социальной сети, где каждый пользователь имеет свой профиль, может искать других людей по разным критериям (географическое местоположение, хобби, общий процент совместимости), добавлять в друзья, общаться в чате в реальном времени, пересчитывать совместимость с другими. человек. Главной особенностью приложения являются алгоритмы расчета совместимости между людьми, учитывающие дату и место рождения, а также некоторые другие критерии, собранные при регистрации пользователя и изменении типа учетной записи пользователя. И в зависимости от типа учетной записи пользователя (который может быть куплен или установлен администратором) у него разный уровень совместимости вычислений.

Итак, у нас есть: пользователи, профили, поиск пользователей, гео, друзья, оплата, типы учетных записей и разрешения (вид acl), расчет совместимости, чат.

Я не уверен, что каждый из перечисленные в предыдущем абзаце следует рассматривать как независимый микросервис, или, например, я могу сгруппировать пользователей, профиль, тип учетной записи / разрешения и друзей в один микросервис, а поиск пользователей и гео в другой.

Answer 1

Общие цели при разработке архитектуры микросервисов:

• Вы должны иметь возможность предоставлять и развертывать службы независимо друг от друга.
• Команда разработчиков должна иметь возможность внедрять службу независимо от других служб.

Сейчас, конечно, не существует единственного «правильного» способа добиться этого, поэтому вот некоторые ресурсы и лучшие практики, которые я нашел полезными:

• Как разбить монолит на микросервисы и Ограниченный контекст
• Микросервисы, ограниченный контекст, сплоченность. Что у них общего?
• Использование анализа предметной области для моделирования микросервисов

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