Ваш следующий сервис будет асинхронным

Антон Тарасенко

I Мотивация

Native Threads

vs

Event-driven Architecture

Мотивация

● CompletableFuture в Java 8.● Цепочки асинхронных операций.● Альтернативы: Scala Future, Finagle Future и

даже Guava ListenableFuture.● Теперь не нужны сторонние зависимости.● На Java все еще нет легковесного решения. ● Асинхронные приложения - в массы.

Накладные расходы на CompletableFuture

https://github.com/zymosi3/java-async-benchmark

The Reactive Manifesto

http://www.reactivemanifesto.org/

II Решение

Service и Pipeline

● Service - это конфигурируемая сущность, выполняющая одну функцию.

● Function<Context, CompletableFuture<Context>>● Pipeline - это композиция сервисов● И Pipeline - это тоже Service● Каждая функция приложения представлена одним

Pipeline● Нет зависимости от протокола входящих/исходящих

запросов и ответов.

Context

● Состояние запроса● Контракт сервисов● Сознательно используем mutable структуру● Контракт не проверяется на этапе компиляции● По сравнению со статическим связыванием

memory footprint может быть даже уменьшен

Пример: передача управления

Пример: Get User Pipeline

Конфигурация

● Используем typesafe config. https://github.com/typesafehub/config

● Каждый сервис получает свою часть конфигурации при создании.

● Рекофигурация без перезапуска.● Сервис может переопределить стандартную

логику реконфигурации.● Файлы конфигурации хранятся в zookeeper.

Плагины

● Дополнение и добавление функциональности к сервису.● Используется только одна обертка.● Точки расширения: до вызова, после, реконфигурация.

getUserService { plugins { ReconfigurationPlugin { lockOnReconfig: true } TimerPlugin { timerName : getUserRemote.time } TimeoutPlugin {} } class: net.thumbtack.doorkeeper.application.service.GetUserService apiHost: localhost apiPort: 8080}

Обработка ошибок

● Любое исключение прерывает Pipeline.● Исключение сохраняется в контексте.● Результат прерванного Pipeline - контекст с

ошибкой.

Таймауты

● Context содержит время начала и значение таймаута.

● 2 подхода: внешняя и внутренняя обработка.● По умолчанию - внутренняя.● Внешняя - конфигурируемо.

HTTP Server & Client

● Асинхронный HTTP-сервер на netty.● Роутинг URL на Pipeline.● Асинхронный HTTP-клиент на netty.● Можно использовать для внутрикластерных

или сторонних вызовов.

Метрики

● Dropwizard metrics http://metrics.dropwizard.io/

● Контекст содержит MetricRegistry● TimerPlugin и CounterPlugin

Request tracking

● Контекст содержит GUID.● GUID должен быть сквозным во всей системе.

Spring

● Все сервисы - это бины.● Точнее прототипы бинов.● Удобно управлять межсервисными

зависимостями.

Планы

● Инструменты управления приложением● Отладочная информация в ответе● Приоритизация трафика● Тротлинг● Межпроцессное взаимодействие● Балансировка нагрузки

III Альтернативы

Сравнение: RXJava

● Мультиплатформенная реализация паттерна Observable

● Есть несколько инструментов построенных на ней.

● Дает большие накладные расходы чем CompletableFuture.

Сравнение: finagle

● Почти весь API не зависит от сетевого протокола

● Futures● Servers и Clients● Services и Filters● Трассировка, мониторинг и статистика,

балансировка нагрузки.

Сравнение: akka + akka-http

● Java/Scala API.● Модель акторов, вдохновленная Erlang.● Просто создавать конкурентные и распределенные

системы.● Позволяет строить надежные системы.● Мощная конфигурирация через Typesafe Config.● Управляемый жизненный цикл компонент(акторов).● Утилиты для мониторинга actor-system.● “Заражает” дизайн системы моделью акторов.● Реализация синхронных сценариев представляет

проблему.

Сравнение: akka + akka-http

● Проект развился на основе Spray.● До сих пор является экспериментальным модулем.● Предоставляет низкоуровненвый и высокоуровневый API.● Удобные пайплайны через akka-streams.● Монструозный DSL для роутинга, ломающий парсеры,

статические анализаторы и психику разработчика.● Из-за akka-streams сложно отлаживать и понимать что

происходит на уровне акторов.● Разработчики заявляют о феноменальной

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

IV Заключение

Наши проекты

● Интерфейс к высоконагруженному хранилищу данных (60-80k qps, <2ms).

● Сервис обогащения рекламных запросов (50k-60k qps, <3ms)

● AdServer (20k-30k qps, <50ms, запросы через сеть <40ms)

Вопросы?

Антон Тарасенко