В рамках личного исследовательского проекта я пытаюсь узнать больше об архитектуре Microservice и о том, как включить ее в отрасль, с которой я работаю.
Я читал много книг и статей, посвященных архитектуре Microservice, и исследовал и работал с несколькими различными программными компонентами, поддерживающими эту архитектуру, такими как RabbitMQ, однако я был не в восторге от запуска моделей данных.
Чтобы представить требование в его простейшей форме, допустим, у меня есть требование к двум микросервисам для следующего требования высокого уровня (обратите внимание, я исключаю микросервис WebAPI / Bridge и микросервисы пользовательского интерфейса как часть этого процесса, я просто сосредоточив внимание на базовых микросервисах, в которых хранятся основные данные):
Требования:
Предоставьте клиенту возможность войти в портал и добавить регистрацию для «схемы», которая позволяет ему добавлять деньги или кредит в свою запись. Это будет мультитенантное решение, в котором данные могут быть помещены в одну базу данных или в несколько баз данных (уже охваченных), и каждая микросервис будет отвечать за свои собственные таблицы.
В некоторых «арендаторах» может быть включен или не включен «Кредитный микросервис», как определено ниже, и могут иметь только «Микросервис клиента» и, возможно, другие микросервисы, такие как «Маркетинговый микросервис» (не определены ниже, но упоминаются в качестве примера). )
Заказчик Микросервис:
Отвечает за управление информацией о клиентах в системе, такой как имя, фамилия, адрес электронной почты и т. Д. Этот микросервис будет предоставлять различные функции, такие как создание нового клиента, обновление существующего клиента, удаление клиента и, наконец, поиск клиентов. (Основные операции CRUD).
Этот микросервис будет получать данные непосредственно из нашей внутренней системы CRM (Управление взаимоотношениями с клиентами) через интеграцию (эта часть рассматривается)
Схема данных:
- CustomerId
- FirstName
- LastName
- EmailAddress
После создания клиента в очереди сообщений публикуется событие, информирующее другие микросервисы о создании клиента.
Кредит Микросервис:
Отвечает за управление балансом клиентов и схемами, зачисленными в систему. По умолчанию клиент НЕ будет зарегистрирован в схеме и, следовательно, НЕ сможет внести кредит на свой счет.
Эта микросервис будет предоставлять функции для «Зачисления» участника в схему и «AddCredit» для его учетной записи, а также для получения информации о конкретном клиенте (его схеме и балансе). В реальной жизни это также позволило бы им изменить схему и иметь другие варианты, но я не делаю этого из этого простого примера.
Внутри системы этот микросервис, скорее всего, также будет отвечать за хранение «транзакций» для зачисления в отдельную таблицу в своей базе данных (или уникальную схему в одном экземпляре базы данных). Это не определено ниже, поскольку оно не имеет отношения к рассматриваемому вопросу.
Схема данных:
- CustomerId
- SchemeName
- Баланс
Этот микросервис будет отвечать за прослушивание событий от микросервиса клиента и создание новых клиентов в своей собственной уникальной таблице SQL, что позволит этому клиенту зарегистрироваться или добавить кредит в свою учетную запись.
Проблема:
В элементе пользовательского интерфейса приложения мне нужно показать пользователям-администраторам список клиентов, в том числе, зарегистрированы ли они в приложении или нет, а также сколько кредитов у клиента, но только если они включили Функциональность «Кредит» (идентификация этого уже рассмотрена, каждый арендатор может включить определенные микросервисы при установке)
Проблема заключается в том, что данные хранятся в двух таблицах и обрабатываются двумя разными микросервисами ...
Создаю ли я новый микросервис (например, CustomerCredit), который объединяет две таблицы(только чтение) для отображения результатов?Вызывает ли API клиентский микросервис «извлечение», а затем кредитный микросервис «извлечение» с соответствующими идентификаторами, а затем объединяет их вместе?
Первый приведенный выше пример не работает на практике, как я мог быНЕСКОЛЬКО микросервисов, расширяющих схему модели клиента, например, Marketing, где я мог бы хранить «Дата последней электронной почты» для идентификатора клиента.
РЕДАКТИРОВАТЬ:
Для подтверждения структура будет выглядеть аналогичнок следующему:
