Security vs Cloud blog | Как мы используем CQRS в Azure

Security vs Cloud blog

Здесь найдете заметки по безопасности, облакам и предпринимательству

Как мы используем CQRS в Azure

При построении высоконагруженных систем, есть одно простое требование к арзитектуре - горизонтальная масштабируемость. И под это требование есть довольно универсальное решение - использовать механизмы очередей, где это позволяет профиль проекта. И стараться минимизировать работу и коммуникации между компанентами системы, когда пользователь приходит за данными.
Именно эти две задачи весьма неплохо решает принцип CQRS - Command-Query Responsibility Segregation. Вернее принцип это заметно шире, но на базе очередей и разделения Worker/Web-Role его весьма неплохо можноздесь использовать.
Итак, давайте разберем, как работают наши Пряники (pryaniky.com), руководствуясь этим принципом:

Все начинается от запроса клиента. Допустим я пользователь, который решил отправить новое сообщение. Этот запрос через JSON прилетает на Web-роль Azure.
И вместо того чтобы сразу писать его в БД мы:
- делаем первичную валидацию запроса
- если данные не верны - отправляем ошибку клиенту
- если данные верны, то мы делаем две вещи. Во-первых назначаем уникальный GUID для пригедшего сообщения, а затем ставим его в очередь на обработку и отправляем обратно клиенту сформированный объект "Новость", как будто он уже записался в БД.
В результати такой махинации клиент сразу видит результат своих действий - отправленную новость или ошибку, а за счет наличия в ней уникального ID, который позже запишется в БД, он может начать делать какие-то манипуляции с этим объектом, еще до записи его в БД. 
Например, если он поставит Like для своей новости, то произойдет аналогичная ситуация:
- в очередь на обработку будет поставлена команда Like
- клиент сразу увидит результат своих действий

Что дальше. После того как сообщение взято на обработку Worker Role, оно инициирует изменнения в основной базе SQL, в которой хранятся все данные системы в удобном для запросов, поиска и хранения формате. 
Как только запись прошла, формируется объект из подготовленных для отображения данных (Новость, со вставленными ФИО автора, сокращенным и полным текстом, числом лайков и пр.) и она помещается в кеш-базу Redis. Более того, WorkerRole обновит в Redis персональные списки новостей, чтобы клиент не выбирал каждый раз новости, которые предназначены именно для него.
И теперь, если придет новый клиент и захочет посмотреть ленту сообщений он моментально получит списко причитающихся мне новостей и считает подготовленные для него объекты прямо из Redis, не мучая SQL.

Более того, если вдруг у нас случился день триумфа и тысячи пользователей решили начать писать новости, лайкать сообщения, то такая арзитектура весьма устойчива. В начале вырастет время появления новых сообщений тк будет расти длина очереди, затем мы можем автоматически запустить дополнительные экземпляры WorkerRole при достижении некого порога по длине очереди и система очень плавно, незаметно для пользователей, переживет этот момент. А так как у нас есть время на изменения алгоритмов работы, То мы можем дополнительно оптимизировать работу систему, обнавляя кеш пакетами, и притормо��ив выполнение низкоприоритетных операций в WorkerRole, Таких как рассылка почты, пересчет счетчиков и рейтингов и т.к.

Так что Microsoft Azure сейчас позволяет без глубоких полняний в устройстве сервисов, без лишнего ковыряния создавать высокопроизводительные веб-сервисы штатными средствами.

Добавить комментарий

Loading