Проект новой архитектуры
Предлагается следующее первое приближение микросервисной архитектуры проекта:
- Модуль Dashboard. Содержит главную страницу сайта, некоторые возможности по работе каталогом роботов.
- Модуль Editor. Содержит редактор диаграмм. Поддерживает конструирование и сохранение диаграмм.
- Модуль 2D-model. Содержит двумерную модель. Позволяет визуализировать исполнение алгоритма заданного диаграммой.
- Модуль Auth. Страницы аутентификации и регистрации.
- Сервис Mapping. Обеспечивает маршрутизацию запросов и постобработку запрошенных страниц.
- Сервис Dashboard. Обеспечивает подготовку страниц Dashboard. Работает с сервисами БД (Robots DB).
- Сервис Editor. Обеспечивает подготовку страниц Editor. Работает с сервисами БД (Diagram DB).
- Сервис 2D-model. Обеспечивает подготовку страниц 2D-model. Работает с сервисами БД (Diagram DB).
- Сервис Auth. Обеспечивает авторизацию с помощью стандарта OpenID Basic. Работает с сервисами БД (Clients DB).
Таким образом планируется разделить клиент на несколько независимых модулей. Для некоторых из модулей клиента может быть выделен собственный сервис на котором будут производиться ресурсоёмкие вычисления, недоступные на клиентской стороне. Для баз данных выделяются собственные сервисы.
Так как требуется некоторая гибкость в плане составления результирующих страниц внедряется сервис Mapping. Все запросы клиентов идут через него. Это позволяет не только гибко маршрутизировать запросы клиентов, но и производить постобработку запрошенных страниц. Например, он может строить единую страниц из компонентов, объединяя на одной странице модуль 2D-модели и редактора.
Когда клиент запрашивает одну из страниц он обращается к mapping сервису, тот запрашивает нужные страницы у других сервисов, после чего, если необходимо, проводит постобработку (на диаграмме он объединяет две страницы в одну) и отдаёт их пользователю. Важно отметить, что на результатирующей странице все URL, которые будут использоваться для RPC вызовов, идут уже в обход mapping сервиса напрямую к сервисам, предоставляющим данные методы.
Детальный проект архитектуры находится в папке UML репозитория. Открыть файл можно последней версией Visual Paradigm. О некоторых основных архитектурных решениях можно прочесть ниже.
###Слой доступа к данным
Слой доступа к данным на данный момент представлен тремя сервисами: Diagram Service, Robots Service, User Service. Основная задача данного слоя -- скрывать работу с базами данных. Каждый сервис отвечает за одну из сущностей, хранящихся в БД.
При проектировании слоя доступа к данным использовался подход "одна сущность -- один сервис". В случае, если появятся новые сущности для хранения, рекомендуется использовать данный подход при проектировании.
Интерфейс сервиса описывается с помощью файлов-описателей интерфейсов Thrift. Там перечисляются все доступные методы, возможные исключения и контракты на использование методов.
Используя сервисы слоя доступа к данным вы снимаете с себя ответственность за верное хранение данных. Все вопросы по сохранению согласованности состояния БД разрешаются в рамках слоя доступа к данным. Таким образом, создав нового пользователя, вы можете не волноваться о том, будет ли создана его корневая папка. Так как схема БД, представленная в UML, гарантирет, что для всякого пользователя существует корневая папка, то слой данных позаботится о сохранении согласованности и создаст папку, если она не была создана ранее.
Тем не менее, нужно отметить, что слой доступа к данным сейчас не реализует распределённые транзакции.
Внимательно изучите контракты на использование методов, указанные в Thrift файлах. Нарушение контрактов может привести к ошибкам при сохранении ваших данных и невозможности их восстановления
Не игнорируйте исключения, объявленные в Thrift файлах. Их верная обработка позволит избежать проблем в будущем.