cocaine: сценарии использования (Дмитрий Унковский,...
TRANSCRIPT
Дмитрий УнковскийРазработчик инфраструктурных компонент
Cocaine: сценарии использования
Запчасти
Запчасти
Cocaine
Запчасти
Cocaine
Elliptics
Народная мудрость http://en.wikipedia.org/wiki/Actor_model
The Actor model adopts the philosophy that everything is an actor.
Cocaine
7
The Actor model adopts the philosophy that everything is an actor. This is similar to the everything is an object philosophy used by some object-oriented programming languages, but differs in that object-oriented software is typically executed sequentially, while the Actor model is inherently concurrent.
An actor is a computational entity that, in response to a message it receives, can concurrently:
● send a finite number of messages to other actors;● create a finite number of new actors;● designate the behavior to be used for the next message it receives.
There is no assumed sequence to the above actions and they could be carried out in parallel.
Decoupling the sender from communications sent was a fundamental advance of the Actor model enabling asynchronous communication and control structures as patterns of passing messages.[7]
Recipients of messages are identified by address, sometimes called "mailing address". Thus an actor can only communicate with actors whose addresses it has. It can obtain those from a message it receives, or if the address is for an actor it has itself created.
The Actor model is characterized by inherent concurrency of computation within and among actors, dynamic creation of actors, inclusion of actor addresses in messages, and interaction only through direct asynchronous message passing with no restriction on message arrival order.
8
У каждого Actor'а в наших терминах есть endpoint, то есть адрес, по которому этому Actor'у можно отправлять сообщения, вот в таком формате:
[method, session_id, [arguments...]]
Actors
9
У каждого Actor'а в наших терминах есть endpoint, то есть адрес, по которому этому Actor'у можно отправлять сообщения, вот в таком формате:
[method, session_id, [arguments...]]
Actors
… и получать ответ вот в таком формате:
[method, session_id, [arguments...]]
10
У каждого Actor'а в наших терминах есть endpoint, то есть адрес, по которому этому Actor'у можно отправлять сообщения, вот в таком формате:
[method, session_id, [arguments...]]
Actors
… а гораздо чаще в таком:
[chunk, session_id, [<binary-data>]] // один или больше[choke, session_id, []] // ответ окончен[error, session_id, [code, message]] // , ошибка ответ окончен
11
Actors
• Сервисы– Плагины, взаимодействующие с cocaine-core
– Выполняются в пуле потоков внутри cocaine-runtime
– Сами обрабатывают входящую очередь сообщений
• Приложения– Пользовательский код, загруженный в облако
– Выполняется во внешних workers в разного рода isolate'ах
– Сообщения приложению сначала попадают в очередь внутри cocaine-runtime, после чего балансятся на экземпляры воркеров
– Cocaine-runtime управляет количеством запущенных воркеров в зависимости от заполненности очереди и других параметров
12
Core Services
• Node– Деплоит, запускает и останавливает приложения на нодах кластера
• Locator– По имени сервиса или приложения возвращает его endpoint
13
Важные вещи, которые помогают
• Autodiscovery
• Протокол, поддерживающий потоки
• Модульное всё
• Однообразность интерфейса
14
Как с этим взаимодействовать?cocaine-framework-*
• Worker– код, который нужно подключить, чтобы приложение умело отвечать на запросы и работать с кокаин-потоками
• Client– код, который умеет находить сервисы и отправлять понятные им запросы
15
Отправим сообщение в сервис Locator, попросим его найти нам сервис node:
[resolve, 123 /* session_id */, [“node”]]
Фреймворки python, nodejs, etc.
16
Отправим сообщение в сервис Locator, попросим его найти нам сервис node:
[resolve, 123 /* session_id */, [“node”]]
Фреймворки python, nodejs, etc.
На что получим ответ [chunk, 123, [buffer]], и после распаковки buffer обнаружим вот такой ответ:
[[ 'hostname', 42653 ], // endpoint 1, // protocol version { 0: 'start_app', 1: 'pause_app', 2: 'list' }] // methods
17
Примеры плагинов
• isolate: Docker, процессы, cgroups
• gateway: IPVS-балансировщик
• driver: источник сообщений о событиях для приложения– Опрашивать внешнюю очередь
– Мониторить события файловой системы
Persistence, persistence и еще раз persistence
Elliptics
http://doc.reverbrain.com/elliptics:ellipticshttp://ioremap.net/node/tag/elliptics
19
Elliptics это
DHT-based fault-tolerant distributed storage
20
Elliptics это
DHT-based fault-tolerant distributed storage
… и не только.
● Маршрутизация запросов по ключу на ноду storage-кластера● Pluggable storage backend● Execution backend
Сценарии
22
Distributed Persistent Queue
Задача: хранить большой поток записей о событиях.
Интерфейс:
Push()
Pop()
23
Как сделать очередь на DHT?
Distributed Persistent Queue
24
Как сделать очередь на DHT?
Наивный подход мог бы быть таким:
Push ~ write(tail++, data)Pop ~ read(head++, data)
Distributed Persistent Queue
tail и head храним в каких-то специальных ключах.
.
25
Как сделать очередь на DHT?
Наивный подход мог бы быть таким:
Push ~ write(tail++, data)Pop ~ read(head++, data)
Distributed Persistent Queue
tail и head храним в каких-то специальных ключах.
Так у нас и происходит.С поправкой на батчинг и другие оптимизации.
26
Distributed Persistent Queue
27
Веб-фронтенд
– Собрать/агрегировать данные из бекендов, наложить шаблоны, вернуть html.
– Поддерживать websocket-соединения для realtime-клиентского приложения
– Ajax-ручки для доступа к бекендам
28
Веб-фронтенд
coca
ine-h
ttp-p
roxy
IPV
S
29
Бекенд, тяжелые вычисления
– Перемножать большие матрицы– Распознавать голос– Image resize– Кодировать видео– …
30
Бекенд, тяжелые вычисления
100x
31
Вычисления рядом с данными
34
Вычисления рядом с данными
exec(key, event@app, <binary-data>)
http://github.com/reverbrain/grape
Дмитрий Унковский
Разработчик инфраструктурных компонент
http://github.com/reverbrainhttp://github.com/cocainehttp://ioremap.nethttp://reverbrain.com
https://groups.google.com/forum/#!forum/reverbrain
Спасибо