Как мне создать границы для моих микросервисов?

Question

У нас есть монолитное c веб-приложение CRUD (назовите его A), которое выполняет определенную задачу. Теперь у нас есть новое требование, более или менее независимое от A функционально. Аудитория разная, время использования, функционал и др. c. все разные. Из-за этого мы решили встроить это в новый сервис B.

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

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

1. сохранить все поля в C, поскольку это служба аутентификации и место для хранения всей пользовательской информации.
2. Хранить ее в B поскольку это единственное место, где оно будет необходимо.

В общем, мой вопрос заключается в том, как решить, как разделить монолит на отдельные части, как разделить данные и что мне делать с вещами. например, userid s, которые являются "общими" для всех служб?

Answer 1

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

В общем, вероятно, не существует единственного «правильного» способа установить границы, но существуют некоторые общие понятия, такие как идея ограниченных контекстов . Кроме того, важная цель, которую следует учитывать при работе с архитектурой микросервисов, заключается в том, что службы должны разрабатываться и развертываться независимо друг от друга.

Еще несколько ресурсов и рекомендаций по топи c, которые я считаю полезными:

• Как разбить монолит на микросервисы
• Использование анализа предметной области для моделирования микросервисов

Answer 2

Вы можете разделить процесс обработки любым удобным для вас способом, но мой путь основан на науке, открытой для обзора.

Harvard Business Review также задал вопрос: «Как вы должны организовать производство?» Короткий ответ: вы централизуете требования и тем самым связываете свои руки. Вот почему я создал рисунки для краткого изложения эссе HBR, в котором эта сложность описывается как необратимая , - это происходит, когда вовлекаются многие потребители и их требования go не документируются при объединении. Это огонь, с которым ты играешь. AFAIK, ваш менеджер завтра скажет вам переключить одну из этих систем на Windows аутентификацию и разрушить вашу централизованную схему.

http://www.powersemantics.com/p.html

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