Предлагаем вашему вниманию проектную работу Наширвановой Кристины, выпускницы курса по Highload Architect. Она спроектировала микросервисную архитектуру для автоматизации приема заказов и организации инвентаризации в баре.
Цель моей проектной работы – создать архитектуру микросервисов для системы, позволяющей автоматизировать часть бизнес-процессов работы в домашних и коммерческих барах.
В качестве объекта исследования рассматривается понятие бара как системы, имеющей отражение в физическом мире с конкретным местонахождением и наличием хранилища ингредиентов (входящих в состав напитков), а также инвентаря.
Пользовательские роли подразделяются на владельцев бара, обладающих расширенными правами администратора, и гостей (клиентов) заведения.
Основные элементы взаимодействия представлены на схеме.
Цели использования
- Определимся с основными сценариями работы системы.
В первую очередь, требуется спроектировать интерфейс заказов, который поможет организовать выбор конкретного инстанса бара в приложении, а далее оформить заказ.
За рамки нашей архитектуры вынесем функционал по оплате заказов, предполагая возможность закрыть счет в самом заведении. - Для роли владельца бара потребуется возможность отслеживать и обновлять содержимое хранилища бара. А именно: уточнять количество остатков ингредиентов и инвентаря, алертинг для отслеживания, если запасы подходят к концу, чтобы вовремя их пополнить.
- На основании имеющихся ингредиентов владелец бара составляется меню и указывает цены в заведении.
Инструменты и технологии
- Docker (https://www.docker.com/) – самая популярная платформа контейнеризации. Разработчики не покидали рынок РФ и не блокируют доступ к своему ПО. В качестве тестового взят образ Sonarqube Community версии 9.2.2 от 14.12.2021 года с известными уязвимостями безопасности.
- Backend реализовать с помощью Spring Webflux и Project Reactor (https://projectreactor.io/) с возможностью использовать неблокирующие (асинхронные) потоки, работающие с вводом/выводом данных.
- Kafka (https://kafka.apache.org/) даст возможность сохранить и не потерять заказы, например, за последний месяц при соответствующей конфигурации.
- Для хранения заказов, ингредиентов и др. сущностей использовать реляционную базу данных, например, Postgresql (https://www.postgresql.org/).
А также в систему добавить нереляционную базу данных для текстового поиска в меню (например, MongoDb). - Redis (https://redis.io/) – использовать в качестве кеша меню конкретного заведения с ценами. Кеш обновлять по расписанию отдельной задачей, либо автоматически при вызове API на изменение состава меню.
Проектирование
1. Выделим несколько микросервисов в системе. Во-первых, в качестве входной точки создадим сервис API Gateway с интеграцией с Keycloak для авторизации и получения токена с определенной ролью в системе.
Так как через этот сервис будут поступать все запросы в систему, в том числе запросы на получение сущности меню (состав которого меняется не реже 1 раза в месяц), то имеет смысл закешировать эти данные с помощью Redis.
2. Модуль Object Storage предполагается как сервис хранения сущностей меню и цен, а также инвентаря, ингредиентов баров. Предусмотрена возмодность горизонтального масштабирования на каждый экземпляр бара.
Также предполагается интеграция с Kafka в качестве производителя сообщений в случае, когда запасы подходят к нижней границе установленного в конфигурации лимита (дла алертинга о завершении запасов).
3. Модуль Order Service обеспечивает хранение и отслеживание статуса готовности каждого заказа. В негативных сценариях (когда заказ не был взят в работу) предполагается автоматический повтор обработки заказа. Также интегрирован с Kafka в качестве писателя, обновляя данные по статусу заказа.
4. Notification Service является читателем топиков Kafka, готовит уведомления и отправляет по сконфигуренным каналам связи (статус заказа для гостя заведения, изменение состояния хранилища бара для владельца).
Итоги. Развитие проекта
В рамках проектной работы создана архитектура системы, позволяющей принимать и отслеживать заказы в баре, а также вести учет хранилища.
Возможные варианты дальнейшей доработки проекта:
- развитие маркетинга – активное ведение социальных сетей с указанием ссылок на систему, добавление Telegram-бота для привлечения пользователей;
- добавить систему оплаты заказов в приложение. Для этого требуется поддержать стандарт PSI DSS (https://www.pcisecuritystandards.org/document_library/?category=pcidss&document=pci_dss) – это международный стандарт безопасности, созданный специально для защиты данных платежных карт, что подразумевает внедрение шифрования и хранения данных карт пользователей, а также фискализацию оплаты;
- масштабирование проекта;
- разработка мобильного приложения;
- развитие программы лояльности, добавление карты лояльности в Wallet.
Интересует архитектура нагруженных систем? Добро пожаловать на курс!