Отношения «многие ко многим» в микросервисной архитектуре и правильно ли идентифицированы сервисы.
Одним из ключевых аспектов микросервисов является их «автономность»
То есть у них нет внешних зависимостей. То, что вы описываете, я бы назвал «распределенным монолитом», у которого есть все проблемы монолита без каких-либо преимуществ.Существует распространенное заблуждение, что микросервисы означают независимое развертывание каждой конечной точки. На самом деле идея состоит в том, что у вас есть набор конечных точек или API и все зависимости от реализации (например, БД), объединенные в независимое и автономное решение.
Это заставляет службу разговоров знать о службе сообщений, которая сохраняет и извлекает все сообщения, сохраненные в базе данных.
Если вы внедряете шаблон микросервисов ⃰, обе эти возможности следует развертывать вместе. Вам может не понадобиться «служба сообщений», если у вас нет отдельной необходимости получать сообщения вне беседы, не выставляйте это как конечную точку. Это нормально, если хранение и извлечение сообщений является частью реализации микрослужбы диалога.
Я должен уточнить, что существует много литературы из (более или менее) авторитетных источников, в которой утверждается, что развертывание каждой конечной точки по отдельности является определяющей чертой архитектуры микросервисов. Я нахожу эту идею немного запутанной и запутанной. Хотя развертывание каждой конечной точки в виде отдельного контейнера (в качестве примера: контейнеры не требуются для микросервисов) имеет некоторые полезные преимущества, если две конечные точки имеют общую зависимость от базы данных, они не являются независимыми и не являются отдельными автономными службами. ИМО, эта идея объединяет архитектуру развертывания контейнеризации с логической архитектурой системы. Но это часть проблемы с микросервисами: все термины перегружены и могут означать разные вещи в разных контекстах. Когда люди читают «сервис», они думают о конечных точках, но это не совсем правильное понятие «сервиса», когда речь идет о микросервисах.
Я нашел соответствующее обсуждение в этой статье, которая, я думаю, подчеркивает то, что я пытаюсь донести:
... слишком часто я вижу гиперкоррекцию от большого монолита до очень маленьких сервисов, очень маленьких сервисов, дизайн которых вдохновлен и управляется существующим нормализованным представлением данных. Такой подход к определению границ сервисов почти всегда приводит к кембрийскому взрыву большого количества анемичных сервисов для ресурсов CRUD. Для многих новичков в архитектуре микросервисов это создает среду с высоким уровнем трения, которая в конечном итоге не проходит тест на независимый выпуск и выполнение сервисов. Это создает распределенную систему, которую трудно отлаживать, распределенную систему, которая нарушает границы транзакций и, следовательно, трудно поддерживать согласованность, систему, которая слишком сложна для операционной зрелости организации.
В этом разделе есть ссылка на это видео, которое тоже может быть полезным.
⃰ Я думаю, что микросервисы — это здорово, но вы должны понимать, зачем вы их реализуете. Они должны быть средством для достижения цели. Другими словами, ваша цель использования микросервисов должна отличаться от «использования микросервисов».
Прикрепляю к посту несколько видео по теме: