Асинхронный билинг для

Такси

Pavel Vinogradov для IzhDevCom

Izhevsk, 2014

Pavel Vinogradov

• Lead Java Developer / Architect• Работаю в: Epam / NixDev• Специализируюсь в

– Billing systems– Data Mining

Контакты:

Email: pavel_vinogradov@epam.comTwitter: pavelvinogradov

Запускать сервисы такси сейчас модно

Мы тоже приняли в этом участие

• Существующее решение одной из служб такси не справлялось с ростом нагрузки

• За 4 месяца надо было понять как работает существующая система

• Разработать новый сервис тарификатора

• Реализовать набор новых требований

• Выполнить интеграцию с существующими системами

Проблемы существовавшего решения

• Биллинг, реализованный в виде хранимок в БД

• Монолитные функции, которые умеют слишком многое

• Отсутствие документации

• Существующие нагрузки все чаще приводили к блокировкам в БД

• Необходимость развивать систему

Наши задачи

• Разработка системы тарифов и бизнес правил для тарификации услуг такси

• Предоставление API для управления тарифами из панели администратора

• Интеграция с существующей структурой БД

• Поддержка популярных БД (SqlServer, MySQL, PgSQL)

• Обработка потока 60 тыс. заказов в сутки

Что мы использовали

• Java Runtime 1.6.x -> 1.7.x

• Java EE 6.0 Glassfish 3.x

• JAX-WS (Metro)

• EJB 3.1

• JPA 2.0 (EclipseLink)

• Quartz Scheduler 2.x

• SqlServer 2005, PostgreSQL

С чего мы начинали

Добавляем API для управления тарифами

Добавляем асинхронности

Особенности архитектуры

• Приложение разделено на две группы сервисов

• Управления доменной областью / базой даных

• Выполнения задач и бизнес логики

• Все действия оператора сводятся только к управлению справочниками в БД

• При старте приложения планируются необходимые задачи

• Вся бизнес логика выполняется отложенно / асинхронно через планировщик

Сервер приложений Java EE

• Самые популярные Java EE сервера приложений

• Jboss / Wildfly

• Glassfish

• Tomcat + TomEE

• WebLogic / WebSphere

• EJB Interceptor

• Реализация логгирования на базе Interceptor – стоит примерно 15-20% производительности

• Glassfish как сервер приложений

• Это Reference Implementation для Java EE и не более

Реализация API

• REST или SOAP

• Современное поколение выбирает REST, мы выбрали SOAP

• Автоматическая генерация API

• Аннотации наше все

• Не все так хорошо

• Генерация документации по API на базе комментариев

• Безопасность

Работа с БД

• JPA как абстракция для БД

• Минимум кода для управления сущностями

• Позволило легко добавить поддержку PostgreSQL

• Версионирование БД

• Общие таблицы в БД

• Отсутствие или нарушение constraints между сущностями БД

• Мусор в таблицах

• Multitenancy с JPA уже возможно

Асинхронная обработка задач

• Популярный паттерн проектирования

• Простейшая реализация – отдельный поток, который вычитывает задачи из БД

• Обычно реализуют на базе Message Queue

• Мы использовали планировщик Quartz и очередь задач в БД

Асинхронная обработка задач

• Плюсы

• Упрощение масштабирования системы

• Выделение логики обработки задач в отдельные компоненты

• Минусы

• Зависимости между задачами

• Необходимы средства мониторинга очередей

• Мы не знаем когда задача будет выполнена

• Восстановление работы после простоя

Производительность

• Плановая нагрузка легко обрабатывается существующей архитектурой

• Основное время тратится на работу с БД

• После анализа работы системы часть таблиц БД можно кэшировать

• JProfiler для анализа работы системы и анализа производительности

• Лишние обращения к БД (повторные чтения)

• Чтение из БД неизменных данных (возможность кэширования)

Интеграционное тестирование

Как это было у нас

Впечатления после внедрения

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

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

• Поиск виноватых в связке Админка - Billing. Все кивали друг на друга, пришлось логгировать большинство входящих запросов (а еще SOAP)

• Сторонние системы не соблюдали форматы обмена данными.

Чем мы гордимся

• Система работает в режиме 24 * 7 без сбоев и замечаний

• Система логирования предоставляет достаточно информации для объяснения 98% ситуаций

• API возваращает понятное описание ошибок, поэтому оператор может сам исправить некорректные данные

• Валидация данных не позволяет создавать некорректные сущности

• Мы смогли добиться этого без помощи тестировщиков

Немного статистики

2012 2013 20140%

20%

40%

60%

80%

100%

Задачи 2012-2014

Доработки Ошибки Консультации

Планы на будущее

• Переход на SaaS модель

• Поддержка Multitenancy

• Использование REST для public API

• Использование SoapUI для TDD

• Оптимизация слоя работы с БД

Советы

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

• Очень аккуратно работайте с чужими таблицами

• Кэширование сущностей БД позволят выиграть 30% производительности, но может быть источником проблем

• Избегайте зависимостей между асинхронными задачами

• Автоматизируйте тестирование с самого начала

• Не публикуйте внутреннее API

Спасибо за внимание

Email: pavel_vinogradov@epam.comTwitter: pavelvinogradov