Файл: Распределенная технология обработки информации (История развития распределенных вычислительных систем).pdf

Одной из важнейших технологий, применяемых на уровне представления, является кэширование. Вместо добавления новых сервисов для обработки нагрузки можно предотвратить появление этой нагрузки совсем, за счет сохранения предыдущих результатов вычислений [^[31]].

Уровень бизнес-логики обычно соответствует веб-сервисам. Основное требования для масштабирования – это отсутствие в них состояния. За счет этого можно получить следующие преимущества:

• Возможность балансировки нагрузки на уровне запроса. Любой экземпляр сервиса может обработать любой запрос.
• Устойчивость к отказам сервисов. При возникновении критической ошибки достаточно исключить сбойный экземпляр из пула балансировщика.
• Возможность выключения сервера для обслуживания в любое время. Достаточно запустить новые экземпляры на другом сервере и перенаправить туда трафик, далее можно выключить обслуживаемый сервер.
• Возможность обновления сервисов без простоя.
• Простое масштабирование путем добавления новых экземпляров сервиса.
• Возможность автоматического масштабирования без участия человека [^[32]].

При масштабировании веб-сервисов сложность вызывают распределенные транзакции при работе с бизнес-сущностями. Распределенная транзакция – это последовательность шагов различных сервисов, которые либо все завершаются успешно, либо все отклоняются. Существует два подхода к реализации распределенных транзакций [^[33]]:

• 2PC – двух стадийное подтверждение при выполнении запроса к СУБД
• Использование компенсирующих транзакций

На уровне доступа к данным существует несколько приемов для распределения нагрузки:

• Репликация данных. Хранение нескольких копий данных на разных машинах. Применительно к распространённой СУБД Mysql – репликация позволяет синхронизировать состояние между двумя узлами ведущим (master) и ведомым(slave). Существенное ограничение – это возможность записи только в master базу, необходимость полного копирования всех данных, задержка в появлении данных на slave базе [^[34]].
• Шардирование. Данные разделяются по какому-либо принципу на более мелкие наборы. Ключевым моментом является выбор принципы разбиения данных. При правильном выборе возможно масштабирование базы данных практически до любых размеров [^[35]].
• Использование NoSQL баз данных, которые изначально поддерживают масштабирование.

2. Проектная часть

2.1 Постановка задачи

В качестве прикладной задачи в данной работе выбрано создание модуля мгновенного обмена сообщениями для CRM-системы интернет-магазина. Важность задачи была обусловлена необходимостью оптимизации процесса приемки заказов. Пропускная способность системы приемки заказов (СПЗ) в CRM системе является производной от двух параметров – количество операторов и времени обработки звонка оператором. Поэтому существенный прирост пропускной способности СПЗ даст оптимизация пользовательского интерфейса CRM системы с целью сокращения времени, затрачиваемого оператором на оформление заказа. Одной из причин почему звонок может обрабатываться дольше регламентированного времени, это ситуация, которая требует консультации или вмешательства супервайзера колл-центра. В CRM системе отсутствовали какие-либо программные средства, позволяющие оператору и супервайзеру общаться и обмениваться оперативной информацией, не покидая рабочего места. Поэтому сотрудники колл-центра вынуждены покидать рабочее место и решать вопросы лицом к лицу. На тратится достаточно много времени.

Обязательные требования к функционалу нового модуля CRM-системы:

• Чат включается при входе в клиентское приложение колл-центра.
• Для каждого логина в CRM должна быть заведена своя учетная запись с распознаваемым логином или именем.
• Поддержка мгновенного обмена текстовыми сообщениями между двумя пользователями чата.
• Хранение истории сообщений (сообщения за как минимум последние сутки).
• Поддержка создания групп рассылок. Один пользователь может состоять в нескольких группах.
• Поддержка мгновенной отправки текстового сообщения всем пользователям определенной группы рассылки
• Поддержка не менее двух ролей пользователей: «руководитель» (администратор) с полными правами, в том числе и на блокировку/разблокировку пользователей и модерацию групп рассылок, «оператор» с правами на общение только с пользователями из определенной категории (супервайзерами)
• Желательно также наличие промежуточная роли "супервайзер", для которой открыты все права, кроме блокировки/разблокировки других пользователей в базе чата.
• Ограничение круга пользователей-адресатов сообщения. Для операторов перечень адресатов должен быть ограничен супервайзерами.
• В чате одновременно будут находится в среднем около 100-150 пользователей, однако в пиковые дни эта цифра может вырасти до 400-500. Необходимо обеспечить минимальную нагрузку на сервер.
• Модуль создаваемого чата должны быть максимально автономны и получать из CRM лишь информацию о пользователях (логин, ФИО, роль) и, возможно, сессиях.
• Требования к поддерживаемым сообщениям. Максимальная длина сообщения - 250 символов. Простой текст, с возможностью переноса на новую строку.

Требования к интерфейсу чата:

Расположение окна чата. Удобно было бы расположить его в правом нижнем углу экрана. Любое окно чата может быть свернуто или развернуто:

Рисунок 2.1 Расположение окна чата

Написание сообщений. В раскрытом окне основным управляющим элементом должна быть область с возможностью ввести логин того или иного пользователя для начала чата с ним или выбрать одну из существующих групп рассылок. Желательно в окне чата разместить историю сообщений за последние 5 календарных дней. 
Опционально (по усмотрению разработчика) можно указывать дату-время отправки сообщения и логин автора в теле сообщения.
При написании сообщений для участников группы рассылки окно чата у отправителя автоматически не открывается. Макет окна представлен на рисунке:

Рисунок 2.2 Окно написания сообщения

Получение новых сообщений. При получении сообщений должно появляться соответствующее уведомление под заголовком свернутого окна с чатом. Заголовок при этом должен мигать или приобретать яркий заметный цветовой формат. Если при получении сообщений окно с чатом было открыто, появляется дополнительный управляющий элемент "Не прочитано". Сообщение считается новым, только если оно не было прочитано ранее и отправлено не ранее чем сутки назад. Опционально (по усмотрению разработчика) можно при выходе из системы (или не активности пользователя в течение часа или более) помечать все полученные до этого момента сообщения как прочитанные.

2.2 Обоснование проектных решений

Система мгновенного обмена сообщениями – чат – будет разрабатываться с нуля. По требованиям технического задания она должна быть программно обособлена от остальных систем и должна создавать минимальную нагрузку на сервер. Анализ функционала чата позволяет сделать вывод, что от выбираемого языка программирования/технологии требуется хорошая поддержка многозадачности. Многозадачность наиболее просто реализуется в Actor-модели, поэтому во внимание нужно принять наличие удобных библиотек реализующих эту модель программирования. Должны быть доступны бесплатные библиотеки для поддержки протоколов HTTP и Websocket. Также важно максимально уменьшить время разработки данной системы. Исходя из требования по производительности системы можно ограничить рассматриваемый набор распространенными современными компилируемыми языками для платформы Linux: C++, Java, Scala. Исходя из требований наличия библиотек поддержки Actor-модели и скорости разработки для реализации чата был выбран язык программирования Scala с библиотекой Akka.

При разработке системы будет применен подход Event Sourcing, так ка он хорошо сочетается с Actor-моделью. И это означает, что от хранилища данных не требуется поддержка таких возможностей реляционных СУБД, как транзакции и объединение таблиц. Поэтому для хранения данных чата идеально подходит СУБД Mongo, так как позволяет хранить документы без определенной схемы, то есть нет необходимости в этапе проектирования схемы базы данных, что ускоряет процесс разработки и упрощает последующие доработки.

В основе фреймворка Akka (названия взято от горы в Швеции) лежит реализация модели акторов, предназначенная для распараллеливания вычислений. Модель акторов изначально была предложена в статье «Universal Modular Actor Formalism for Artificial Intelligence» вышедшей в 1973 [^[36]]. В статье актор определен как активный агент, влияющий на сигнал в соответствии с заложенным алгоритмом. Изначально модель использовалась для узкого круга задач, но в последнее время интерес к данной модели значительно возрос.

Вплоть до середины 90-х годов большинство приложений использовали для работы один однопроцессорный компьютер. Если приложение требовало больше вычислительных ресурсов, то стандартным ответом была установка более мощного процессора или увеличение оперативной памяти без необходимости изменений в коде. В 2005 Херб Суттер в своей статье написал о необходимости изменений такого подхода, так как практически достигнут предел скорости процессора. Для дальнейшего увеличения производительности необходимо распараллеливание задач на несколько потоков [^[37]].

Масштабируемость характеризует способность системы подстраиваться к изменениям в нагрузке на систему без уменьшения производительности. Распараллеливание вычислений это один из способов достижения масштабируемости системы. К сожалению, в большинстве языков программирования поддержка параллельных вычислений с тех пор осталась на базовом уровне: программист по-прежнему должен работать с низкоуровневыми абстракциями типа потока или блокировки. Помимо распараллеливания вычислений на одном компьютере (подход Scale-Up –масштабирование вширь) возможно распараллеливание за счет добавления большего количества компьютеров (подход Scale-Out –масштабирование вверх). На этом направлении также по сути мало что изменилось: в большинстве технологий для выполнения вычислений на другом компьютере используется синхронный запрос по сети. С другой стороны, развитие многопроцессорных систем и облачных вычислений сделало легко доступными дополнительные вычислительные ресурсы. Но использование этих ресурсов проблематично, так как существенно повышает сложность программного обеспечения при разработке его прежними методами, не ориентированными на распределенные и параллельные вычисления [^[38]].

Этот пробел был заполнен фреймворком Akka, который используя модель акторов скрывает от программиста сложности организации параллельных и распределенных вычислений и позволяет масштабировать программу как вверх, так и вширь. Данный фреймворк разработан под влиянием идей из манифеста реактивного программирования (Reactive Manifesto) – набора принципов для разработки надежных, устойчивых и гибких систем, которые удовлетворяют современным требованиям:

Блокирующий ввод-вывод ограничивает возможности использования параллельных вычислений, поэтому предпочтителен неблокирующий

Синхронные взаимодействия ограничивают параллелизм, поэтому предпочтительны асинхронные

Использование подхода с опросом ресурса повышает использование вычислительных мощностей, поэтому предпочтителен событийный подход

Если один узел может привести к отказу всей системы, то необходимо его изолировать

Система должна быть гибкой в использовании ресурсов: при низкой нагрузке – меньше ресурсов, с увеличением ресурсов – больше ресурсов

Данные принципы приводят к следующим отличиям от традиционной модели:

Таблица 2.1

Отличия классического подхода от принципов Reactive Manifesto [^[39]]

Фреймворк Akka основан на акторах, рассмотрим работу актора.