Платформа для построения многопоточных, распределенных, сетевых приложений

1. SMARTACTORS
Библиотека для нагруженных и масштабируемых приложений

2. Процессоры уже не те!
 Рост производительности одного ядра
процессора остановился!
 Рост производительности приложений
теперь должен обеспечиваться за счет
активного использования
многоядерности.
Herb Sutter, 2005 The Free Lunch Is Over A
Fundamental Turn Toward Concurrency in Software
“The bad news is that, at least in the short term, the
growth will come mostly in directions that do not take
most current applications along for their customary free
ride.

3. Требуются сильные специалисты, заранее сложно
прогнозировать результат, трудно и, как следствие, дорого
масштабировать, развивать и сопровождать систему.
Многопоточные приложения слишком сложны

4. Акторы – альтернатива многопоточности
Carl Hewitt,
Peter Bishop,
Richard Steiger
A Universal Modular ACTOR
Formalism for Artificial Intelligence
1973
Carl Hewitt

5. Что такое актор?
Актор – вычислительная
сущность, которая может
за один шаг
 Отправить конечное число
сообщений другим акторам
 Создать конечное число акторов
 Выбрать поведение для приема
следующего сообщения

6. Многопоточность vs Акторы
Многопоточность больше всего похожа
на телефонию. Доступ к ресурсу –
телефонный звонок. Адресат может быть
занят или не брать трубку – живая и
мертвая блокировки. Чтобы
одновременно принимать много звонков,
в телефонии используют офисные АТС –
объекты синхронизации.
Акторы похожи на почтовую систему.
Чтобы выполнить какое-либо действие
актор посылает сообщение – письмо
адресату, и дальше занимается своими
делами. Не нужно никаких блокировок
вообще, можно послать много сообщений
за 1 раз, но нет гарантий, что каждое
сообщение будет доставлено адресату.

7. Почему своя реализация акторов на Java, а не,
например, Erlang, Scala и т.д.?
 У нас низкий порог вхождения – разработчики без опыта
работы – надо знать только чистый Java без Framework’ов.
 Erlang не подходит для длительных вычислений (типичная
ситуация, когда при решении многопоточных задач Erlang
проигрывает в скорости – см., например, рис. справа 18,19
место и проигрыш в ~20 раз!)
 Подход Scala (без инверсии зависимостей – Philipp Haler,
Martin Odersky, 2006 Event-Based Programming Without
Inversion Control) заставляет разработчика самого
задумываться о распараллеливании задач в коде, то есть
требуется наличие хорошего опыта
 Мы предлагаем решения в акторах, которых нет ни на
одной платформе (речь пойдет далее)
benchmarksgame.alioth.debian.org

8. Каждый актор запущен внутри некоторого процесса – Node. Каждый
актор подключен к одному или нескольким каналам шины сообщений –
MessageBus. Чтобы отправить сообщение актору, надо его опубликовать
в соответствующем канале.
Верхнеуровневое описание SmartActors

9. Маршруты сообщений
 Акторную модель можно представить в виде графа,
где каждая вершина – это актор, а стрелка
показывает, что один актор (основание стрелки)
посылает сообщение другому актору (конец
стрелки)
 Маршрут сообщения – это путь в графе, которое
проходит сообщение от момента создания до
завершения обработки.
 Обычно, информация о том, кому посылать
сообщение зафиксирована в исходном коде актора.
 Это требует модификации актора и,
соответственно, обновления сервера, каждый раз,
когда нам необходимо внести изменения в
соответствующий алгоритм (например, в
запрограммированный бизнес-процесс)

10. Управление маршрутами без программиста
 Наше решение предлагает вынести
информацию об адресатах сообщений за
пределы актора, так чтобы он ничего не
знал о следующих акторах маршрута.
 В таком случае акторы можно легко
компоновать в любых сочетаниях для
реализации сложных операций.
 Маршруты формируются динамически, так
что их можно менять без обновлений и
перезагрузки сервера.
 Изменение маршрута может проходить
без участия программиста. Программисты
нужны только для разработки новых
акторов.

11. Контрольные точки
 При поступлении запроса (сообщение) от
пользователя, при прохождении через
контрольную точку сообщение сохраняется
как есть в базе данных.
 Дальше сообщение отправляется по
маршруту
 Если в результате сбоя в работе какого-
либо актора, запрос в данный момент не
может быть выполнен, то благодаря тому,
что все данные сохранены в контрольной
точке, мы можем исправить ошибку и
повторить операцию без дополнительных
действий со стороны пользователя.
Контрольная точка
сохраняет в БД входящее
сообщение как есть
Конечная точка маршрута
сообщения

12. Преимущества контрольных точек
 Можно ответить пользователю раньше, чем
завершится обработка операции, что уменьшает
время отклика (ответ значит не то, что операция
завершена, а то, что успешно принята заявка на
выполнение операции – в большинстве случаев
этого достаточно, как например, в платежном
терминале)
 Пользователь не видит, что внутри нашей системы
могут проблемы – для него система всегда работает
правильно – ошибка выражается лишь в увеличении
времени обработки операции
 Можно использовать несколько контрольных точек
в одном маршруте, чтобы уменьшить объем работы
в случае сбоя
 Не теряется информация от внешних систем,
например, платежных, в случае сбоя в нашей
системе – данные от внешних систем сохранятся в
некоторой контрольной точкеКонечная точка маршрута
сообщения
Контрольная точка
сохраняет в БД входящее
сообщение как естьвходящий
запрос
ответ

13. Один формат для всех данных
 Все данные хранятся в виде JSON в реляционной БД (не NoSQL база). Почему
реляционная – есть транзакции.
 Структура базы очень проста – всего 6 (!) запросов к БД.
 Всегда известно среднее время выполнения любого запроса (в том числе
полнотекстовых поисковых запросов). Поскольку запросы фиксированы, то время
их выполнения не зависит от квалификации разработчика.
 Не нужно миграций вообще – одновременно можно хранить сразу несколько
версий одних данных (система будет корректно работать со всеми версиями)
 Базу легко масштабировать и поддерживать скорость выполнения запросов –
достаточно выделить нужные записи в отдельную коллекцию. Например, если у
Вас объявления о продаже автомобилей и из них половина – это Toyota, то их
можно выделить в отдельную коллекцию, или, наоборот, из-за ухода General
Motors количество продаваемых Chevrolet, Opel снизилось, то их можно собрать
в одну коллекцию. Это делается однажды написанными процедурами и хорошо
отлаженными слияния и разделения коллекций, то есть участие программиста для
этих операций не требуется.
{
‘фамилия’: ‘Иванов’,
‘заказы’: [
{
‘дата’: ’01.09.2015’,
‘стоимость’: 2000
},
{
‘дата’: ’01.10.2015’,
‘стоимость’: 2000
}
]
}

14. Актор имеет имя и версию. Чтобы система стала использовать актор, разработчик
обязан опубликовать его в библиотеке акторов. Ни один актор не потеряется, а
библиотека будет хранить информацию обо всех акторах, которые когда либо были в
нашей системе, а также о тех, кто их опубликовал! Исключается человеческий фактор
при деплое на сервера, обеспечивается безопасность.
Библиотека акторов

15. Библиотека конфигураций
 Структура каждого сервера описывается JSON
 Все конфигурации с версиями хранятся в библиотеке
конфигураций
 Чтобы обновить конфигурацию на сервере, ему
посылается сообщение с идентификатором
конфигурации
 Сервер обращается в библиотеку конфигураций и
получает требуемую конфигурацию
 При необходимости сервер сам выкачивает из
библиотеки акторов требуемые конфигурацией
акторы
{
‘actors’: [{
‘name’: ‘emailSender’,
‘smtp’: …,
},
{
‘name’: ‘dailyReport’,
…
}
‘messagePaths’: [{
‘name’: ‘newAd’,
…
}],
‘enpoints’: […]
}

16. Преимущества библиотеки конфигураций
 Быстро клонировать сервера – достаточно установить
нашу библиотеку (скопировать файлы) и послать
сообщение с необходимой конфигурацией
 Автоматический деплой – надо только написать
конфигурационный файл
 Можно выставлять время обновления
 Автоматический откат – если возникают ошибки при
инициализации сервера, то автоматически откатываемся
до старой конфигурации
 Ни одна конфигурация не теряется
 Можно иметь одновременно сервера, которые работают
с разными версиями данных, например, если часть
клиентов, которые работают с Вами по API еще не
перешла на новую версию
{
‘actors’: [{
‘name’: ‘emailSender’,
‘smtp’: …,
},
{
‘name’: ‘dailyReport’,
…
}
‘messagePaths’: [{
‘name’: ‘newAd’,
…
}],
‘enpoints’: […]
}

17. Методы обнаружения разладки
Используем мат.
статистику для
обнаружения и
исправления ошибок.
Акторы-датчики
измеряют поведение
системы, потом эта
передается на вход
специальных
алгоритмов,
позволяющих
обнаруживать ошибки
на работающей
системе без
программистов и
тестировщиков.

18. Преимущества нашего решения
 Масштабируемые приложения могут
строить разработчики с небольшим
опытом работы или вообще без опыта
 Нет проблем с миграциями данных
 Методы объективного контроля
работоспособности всей системы, не
зависящие от программистов и
тестировщиков
 Быстрое клонирование и развертывание
серверов по необходимости
 Возможность адаптации или правки
автоматизируемых бизнес-процессов без
участия программистов.

19. Существующие внедрения – портал
бесплатных объявлений и новостей
 Команда – 5 студентов без опыта работы и
филолог
 Среднее время открытия страницы
уменьшено с 4,5 с до 400 мс
 Количество ошибок по сравнению с
предыдущей версией уменьшилось в 1000
раз!
 Количество серверов уменьшено с 15 до 3!
 Объявление можно подавать простым
текстом вместо длинной формы: “Двушка в
Советском округе, проспект Мира, 64, в районе
ост. Политех, 50/34/8, 3/5п, не требует ремонта,
санузел раздельный, хрущевка.”

20. Существующие внедрения – платформа
для контекстной рекламы
 Требование – время отклика строго меньше 100 мс
 Попытки задействовать ElasticSearch, MongoDb и т.д. дают в некоторых
случаях 200 мс и больше
 Был написан актор, который хранит все критерии рекламных компаний сразу в
памяти.
 Получили время отклика 20-50 мс (сам поиск по структуре в памяти 5-20 мс)
 Для масштабирования система поддерживает работу с несколькими
экземплярами серверов

21. Существующие внедрения –
кроссплатформенное приложение
 Приложение считает время по каждой
задаче программиста, снимает
скриншоты, мониторит активность
клавиатуры и мыши
 Интерфейс написан на HTML5 и CSS3
 Бизнес-логика написана на нашей
библиотеке
 Приложение работает без изменений
под Mac, Window, Linux (кроме методов
снятия скриншота и логирования активности
– это малая часть – до 40 ч работы – по
сравнению со всем приложением)

22. Контакты
HWdTech, LLC
Тюменцев Евгений
Генеральный директор
hwdtech.ru
etyumentcev@hwdtech.ru
+7 913 150 22 04