Компания, в которой я работаю, изучает возможность перехода от нашего текущего монолитного API к микросервисам. Наш текущий API сильно зависит от Spring, и мы используем SQL-сервер для большей устойчивости. Наше исследование микросервисов склоняется к сохранению Spring-Cloud, Spring-cloud-stream, kafka и polyglot (изолированная база данных для каждого микросервиса).
У меня вопрос о том, как обмен сообщениями через кафку обычно осуществляется в микросервисной архитектуре. Мы планируем создать уровень координации между набором микросервисов и нашими клиентскими приложениями, который будет координировать действия различных микросервисов и изолировать клиентов от изменений в API микросервисов. Большая часть материала, который мы читали об использовании spring-cloud-stream и kafka, указывает на то, что мы должны использовать потоки на уровне координации (источник) для операций изменения ресурсов (вставки, обновления, удаления), при этом микросервис является одним из потребителей Сообщения.
Где у меня были проблемы с этим, так это вставки. Мы активно используем идентификаторы, назначенные базой данных (столбцы идентификаторов / столбцы с автоинкрементом / последовательности / суррогатные ключи), и они обычно назначаются как часть почтового запроса и возвращаются вызывающему. Уровень координации может сохранять несколько вещей, используя разные микросервисы, и часто нуждается в присвоенном идентификаторе из одной вставки, прежде чем он сможет перейти к следующей операции. Использование обмена сообщениями между координационным уровнем и микросервисами для вставок делает так, что координационный уровень не может получить ответ от операции вставки, поэтому он не может получить назначенный идентификатор, который ему нужен. Кроме того, другим потребителям в потоке (то есть потребителям, которые публикуют данные в хранилище данных) действительно нужно, чтобы сообщение содержало назначенный идентификатор.
Как люди справляются с этой проблемой? Являются ли идентификаторы, присвоенные базой данных, анти-шаблоном в микросервисах? Должны ли мы предоставлять отдельные конечные точки микросервисов, которые возвращают идентификаторы, назначенные базой данных, чтобы уровень координации мог выполнять синхронный вызов для получения идентификатора перед вызовом асинхронной вставки? Мы могли бы использовать UUID, но наши администраторы баз данных ненавидят их в качестве первичных ключей, и их нельзя использовать в качестве номера заказа или других сгенерированных идентификаторов для пользователя.
