Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 <ul><li><a>Цели использования</a></li>

2 <li><a>Проектирование</a></li>

3 <li><a>Итоги. Развитие проекта</a></li>

4 </ul>Предлагаем вашему вниманию проектную работу Наширвановой Кристины, выпускницы <a>курса по Highload Architect</a>. Она спроектировала микросервисную архитектуру для автоматизации приема заказов и организации инвентаризации в баре.

5 Цель моей проектной работы - создать архитектуру микросервисов для системы, позволяющей автоматизировать часть бизнес-процессов работы в домашних и коммерческих барах.

6 В качестве объекта исследования рассматривается понятие бара как системы, имеющей отражение в физическом мире с конкретным местонахождением и наличием хранилища ингредиентов (входящих в состав напитков), а также инвентаря.

7 Пользовательские роли подразделяются на владельцев бара, обладающих расширенными правами администратора, и гостей (клиентов) заведения.Основные элементы взаимодействия представлены на схеме.

8 <a></a><h2>Цели использования</h2>

9 <ol><li>Определимся с основными сценариями работы системы.В первую очередь, требуется спроектировать интерфейс заказов, который поможет организовать выбор конкретного инстанса бара в приложении, а далее оформить заказ.За рамки нашей архитектуры вынесем функционал по оплате заказов, предполагая возможность закрыть счет в самом заведении.</li>

10 <li>Для роли владельца бара потребуется возможность отслеживать и обновлять содержимое хранилища бара. А именно: уточнять количество остатков ингредиентов и инвентаря, алертинг для отслеживания, если запасы подходят к концу, чтобы вовремя их пополнить.</li>

11 <li>На основании имеющихся ингредиентов владелец бара составляется меню и указывает цены в заведении.</li>

12 </ol><a></a>Инструменты и технологии

13 <ol><li>Docker (<a>https://www.docker.com/</a>) - самая популярная платформа контейнеризации. Разработчики не покидали рынок РФ и не блокируют доступ к своему ПО. В качестве тестового взят образ Sonarqube Community версии 9.2.2 от 14.12.2021 года с известными уязвимостями безопасности.</li>

14 <li>Backend реализовать с помощьюSpring WebfluxиProject Reactor(https://projectreactor.io/) с возможностью использовать неблокирующие (асинхронные)<a>потоки</a>, работающие с вводом/выводом данных.</li>

15 <li>Kafka(https://kafka.apache.org/) даст возможность сохранить и не потерять заказы, например, за последний месяц при соответствующей конфигурации.</li>

16 <li>Для хранения заказов, ингредиентов и др. сущностей использовать реляционную базу данных, например,Postgresql(https://www.postgresql.org/).А также в систему добавить нереляционную базу данных для текстового поиска в меню (например,MongoDb).</li>

17 <li>Redis(https://redis.io/) - использовать в качестве кеша меню конкретного заведения с ценами. Кеш обновлять по расписанию отдельной задачей, либо автоматически при вызове API на изменение состава меню.</li>

18 </ol><h2>Проектирование</h2>

19 1. Выделим несколько микросервисов в системе. Во-первых, в качестве входной точки создадим сервис API Gateway с интеграцией с Keycloak для авторизации и получения токена с определенной ролью в системе.

20 Так как через этот сервис будут поступать все запросы в систему, в том числе запросы на получение сущности меню (состав которого меняется не реже 1 раза в месяц), то имеет смысл закешировать эти данные с помощью Redis.

21 <a></a>2. Модуль Object Storage предполагается как сервис хранения сущностей меню и цен, а также инвентаря, ингредиентов баров. Предусмотрена возмодность горизонтального масштабирования на каждый экземпляр бара.

22 Также предполагается интеграция с Kafka в качестве производителя сообщений в случае, когда запасы подходят к нижней границе установленного в конфигурации лимита (дла алертинга о завершении запасов).

23 <a></a>3. Модуль Order Service обеспечивает хранение и отслеживание статуса готовности каждого заказа. В негативных сценариях (когда заказ не был взят в работу) предполагается автоматический повтор обработки заказа. Также интегрирован с Kafka в качестве писателя, обновляя данные по статусу заказа.

24 <a></a>4. Notification Service является читателем топиков Kafka, готовит уведомления и отправляет по сконфигуренным каналам связи (статус заказа для гостя заведения, изменение состояния хранилища бара для владельца).

25 <a></a><h2>Итоги. Развитие проекта</h2>

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

27 Возможные варианты дальнейшей доработки проекта:

28 <ul><li>развитие маркетинга - активное ведение социальных сетей с указанием ссылок на систему, добавление Telegram-бота для привлечения пользователей;</li>

29 <li>добавить систему оплаты заказов в приложение. Для этого требуется поддержать стандарт PSI DSS (https://www.pcisecuritystandards.org/document_library/?category=pcidss&document=pci_dss) - это международный стандарт безопасности, созданный специально для защиты данных платежных карт, что подразумевает внедрение шифрования и хранения данных карт пользователей, а также фискализацию оплаты;</li>

30 <li>масштабирование проекта;</li>

31 <li>разработка мобильного приложения;</li>

32 <li>развитие программы лояльности, добавление карты лояльности в Wallet.</li>

33 </ul>Интересует архитектура нагруженных систем? <a>Добро пожаловать на курс</a>!