CodeFreeze 2013: как устроен enter (расширенная версия)
10 likes3,415 views
Слайды для рассказа на CodeFreeze, 2013.11.21
More Related Content
Similar to CodeFreeze 2013: как устроен enter (расширенная версия) (20)
CodeFreeze 2013: как устроен enter (расширенная версия)
- 1. Как устроен Enter по версии 2013Q3
- 2. Обо мне • Андрей Татаринов • Опыт • • Google: 2010-2012 • HH.ru: 2009-2010 • • Enter: 2012~now Yandex: 2005-2009 Цель • Уменьшение энтропии
- 3. Что такое Enter? • мультиканальный ритейл • • сайт • колл-центр • • реальные магазины (терминалы и касса) мобильные приложения все сложно • много регионов присутствия • много складов • много магазинов • расчет доступности • расчет сроков доставки
- 4. Все сложно • Общий сток • • нет классического деления на сток интернетмагазина и реальных магазинов Единая бизнес-логика • • расчет доступности • расчет стоимостей и сроков • • группировка товаров по моделям/линиям/наборам etc 60+ типов конфигурационных мастер-данных
- 6. Все еще сложнее: сток
- 7. Этапы развития информационной системы • 2012Q1 Старт • 2012Q1~2013Q1 • • Переход на синхронный внутренний API • • Стабилизация фронтов Развитие бизнес-логики 2013Q1~now • Развитие сервисной инфраструктуры • Новый поиск/листинги на sphinx • Новая CMS • Внедрение ESB для интеграции stateful сервисов • Рефакторинг обменов 1С, WEBCORE, etc.
- 8. Как это было на старте 2012Q1 • Результат трехмесячного спринта • Фронты - отдельные независимые системы • сайт, терминалы, мобильные, соц.приложения • разрабатывались параллельно независимыми командами • stateful • отдельная база на каждом фронте • отдельная реализация бизнес-логики • независимое состояние синхронизации
- 11. Как это было на старте 2012Q1: Проблемы • Нестабильный сайт • Рассинхронизация между фронтами и учетной системой (1С) • Несоответствие бизнес-логики между фронтами • Нестабильные протоколы обменов • потеря данных
- 12. Как это было на старте 2012Q1: Нестабильный сайт • Сайт: Symfony+Doctrine • Агрессивное кеширование на 24 часа • Динамические элементы: AJAX • 2~5 сек/страница в среднем
- 13. Как это было на старте 2012Q1: Кеширование
- 14. Как это было на старте 2012Q1: Нестабильный сайт
- 16. Синхронизация web-систем с ERP • Идентификация • Общая БД: все вместе читают • • • Нет списка изменений Нельзя делать инкрементальные изменения Pull, метод: ДайНовыеДанные • • • Висящие ссылки Легко сделать неправильно Push, метод: ВозьмиНовыеДанные
- 17. 2012Q1: Проблемы
- 18. 2012Q1: Первая итерация рефакторинга • убить синхронизацию между WEBCORE и фронтами • stateless-фронты • внутренний API • • HTTP+JSON роли фронта: • • агреггация данных • • преобразование запроса клиента в несколько запросов API визуализация данных новые вспомогательные сервисы
- 24. Отладка сайта • Распределенная система: • • Логи • • request_id Отладочная информация прямо в ответе Сайт - отладочная панель • • Список всех запросов: хост, время ответа, содержимое ответа API - логи прямо в JSON ответе
- 25. Терминал • Основной инструмент продаж в магазине • Ассортимент магазина • Ассортимент доступный к доставке • QT-приложение/Windows • Полноценный клиент API • Нагрузка: 400 терминалов * 0.2 действия/терм/сек * 5 запросов/действие = 400 запросов/сек • Конфигурация: • Как терминалу узнать где он находится? • Как перенастроить терминал удаленно?
- 26. RW/RO-API и терминалы • • RO • RO/RW ≈ 100/1 • репликация • горизонтальное масштабирование Магазины • ~80 магазинов • ~400 терминалов • плохой канал • большие запросы от терминалов • локальные реплики RO-core • mysql-репликация • проксирование RW на площадку
- 27. RW/RO-API и терминалы: WEBCORE в каждом магазине
- 29. 2013Q1: Проблемы
- 30. 2013Q1: Проблемы
- 31. 2013Q1: Вторая итерация рефакторинга • Декомпозиция WEBCORE • CORE - бизнес-логика, доступность, цены • CMS - описания товаров, каталог • Search - листинги и поиск • Внедрение ESB Apache ServiceMix • Переработка интеграции сервисов • 1С • WEBCORE • Search • OLAP • etc
- 35. Новая платформа поиска: предпосылки • Медленно работает сложная фильтрация на SQL • Требуются предрасчеты • Количество товаров в категории • Модели • Две системы работы со списками товаров: SQL, sphinx • Нет возможности фильтровать поиск по бизнесданным
- 36. Новая платформа поиска: концепция • Шире чем полнотекстовый поиск • Поиск - система для фильтрации структурированных и не структурированных данных по товарам • Точка объединения бизнес- и описательных данных • Единственный способ получить любой список товаров
- 37. Новая платформа поиска: разработка • Аутсорс команде Андрея Аксенова • Первая итерация не взлетела - слишком широкая таблица • Переехали на beta-версию с поддержкой JSONполей • Вторая итерация тормозила - попытались все данные записать в JSON • Остановились на гетерогенном индексе: • Свойства - JSON • Регион-зависимая информация - обычные колонки
- 39. Обмен сообщениями • Обмен сообщениями неизбежен • Можно сделать по-разному • Плохо: реализовать очереди самостоятельно PHP+MySQL+cron • Не очень плохо: RabbitMQ+PHP-worker • • Работает для небольшого количества очередей Хорошо: ESB • Большое количество интеграционных потоков и сценариев
- 40. ESB: Apache ServiceMix • Альтернативы • MuleESB • WSO2 ESB • JBoss ESB • Apache ServiceMix • Выбрали ServiceMix • Нагрузка • Основная синхронизация CORE 1C: ~3000 пакетов, 2Gb данных • CORE Sphinx: ~300000-500000 пакетов
- 41. CMS • Альтернативы • Самописный софт на PHP • Drupal • Magento • ShopScript • Выбрали ShopScript • Work in progress • Нюансы • Смена идентификации • Разбиение API (product/get) • Доработки фронтов
- 42. Итого • Не копировать информацию без необходимости • • Не усложнять • • stateless лучше чем stateful Поддерживать компоненты простыми Использовать мозг