Что вас ждет на пути реализации soa (Битрикс отступает)
DESCRIPTION
Рассказ о том, как проект banki.ru принял решение убегать от Битрикса через SOA, а так же о том, как мы бежали к SOA, и что получилось в итогеTRANSCRIPT
Что вас ждет на пути реализации SOA
(Битрикс отступает)
Савунов Василий[email protected]
skype: babr79
Цель доклада
Рассказ на тему «Битрикс в banki.ru» Немного рассказать о SOA
Поделиться нашим опытом внедрения SOA
Предупредить о трудностях
Вопросы для размышления
Рекомендации
Битрикс в banki.ru
Проблемы масштабирования
Битрикс – большой
Спагетти-код, бестолковая файловая структура
Unit-тесты для компонент Битрикс – проблема
Инфоблоки ;(
Обновления Битрикс непредсказуемо меняют API
Новые “фишки” и bugfix – ждем обновления Битрикс
Демотивация разработчиков
К чему хотелось придти?
Для разработчиков: Перестать копаться в legacy-коде Современный framework Уменьшить связанность кода Возможность покрыть Unit-тестами код Чтобы было интересно работать!
Для бизнеса: Держать нагрузку Чтобы сроки не срывались Минимизация неожиданностей Снижение издержек
Какие есть варианты?
Переписать все с нуля
Плюсы Сделаем все хорошо :) Не влияем на текущую разработку
Минусы Дорого Долго Нужна отдельная команда и менеджер Что-то потеряем по дороге обязательно Трудно прогнозировать сроки А что делать с текущими проектами? А чем будет заниматься текущая команда?
“Подложить” другой framework
Плюсы Сделаем все хорошо, но по частям
Минусы Непредсказуемость интеграции с Битрикс Разработка одновременно на 2х платформах Труднее отследить причины багов Труднее тестировать Как быть с обновлениями Битрикс?
Перейти на SOA
Плюсы Выбираем framework под сервис Понятные границы работ Прогнозируемые сроки Нет влияния на основной проект Слабая связанность Ограниченный объем кода
Минусы Труднее отследить причины багов Риск “зоопарка” Разрастается инфраструктура Трудности с целостностью данных
Service Oriented Architecture
Основной плюс SOA – атомарные, небольшие, стабильные сервисы, вместе обеспечивающие нужный функционал
Сервис = автономный модуль системы, предоставляющий доступ к своим данным через API
БД1
БД2
БД3
Фронтенд БэкендПрокси
Сервис1
Сервис2
Сервис3
Монолит vs SOA
Монолитнаяархитектура
SOA
К чему хотелось прийти в итоге
Старт
• Форум• Блоги• Банки• Банки на карте• Кредиты• Вклады• Новости• Фин. Рейтинги• Друзья банков• Народный рейтинг• Служебный рейтинг• etc.
Битрикс
Отображениеview
Битрикс
Банки
Новости
Фин. рейтинги
Кредиты
Вклады
Банкина
карте
Народный рейтинг
Служебный рейтинг
Друзьябанков
Финиш
APIAPI
APIAPI
API
API
API
API
API
Форум Блоги
Что вас ждет на пути SOA?
Начинаем обзор маршрута
Нужно изменить мышление!
SOA — хорошая идея, но трудная задача
Реогранизоватьархитектуру Вот так
Чтобы получитьвот это
Монолитнаяархитектура
Бизнес - сервисы
Гибкость ираспределенность
Вопросы проектирования SOA
Как «резать» бизнес-логику на сервисы?
Где границы сервисов?
Должны ли сервисы общаться друг с другом?
БД: общая или сегментация по сервисам?
«Жирный» client-side, или «тонкий»?
Общий кеш, или по-сервисно?
Как быть со сложными выборками?
Из нашей практики проектирования
• Отталкивайтесь от объектной модели при проектировании
• 1 связь – кандидат в сервис
• >1 связи - несколько сущностей в одном сервисе
• Сильно связанные сущности - в одну БД
• Атомарные сервисы проще в поддержке, и не создают зависимостей
• Преимущественно «тонкий» client-side
• Кеш под каждый сервис (в т.ч. и под сервис-агреггатор)
• Сложные выборки – Sphinx, сервисы-агреггаторы
Слабая связанность!
БД сервисов не общаются напрямую!
Нет JOIN'ов, нет подзапросов
Данные другого сервиса = +1 API-запрос
Набор данных из разных сервисов = несколько запросов к API + бизнес-логика
Накладные расходы на обеспечение целостности данных
Вместо транзакций – очереди (RabbitMQ)
SQL
API
Пример
Задача: получить курсы валют для ближайших банков
Bank-InfoGeo Currency
getNearestXY getProperties getList
1 запрос 2 запрос 3 запрос
Инфраструктура растет быстро!
Для N сервисов нужно (как минимум):1. N виртуалок (или серверов)2. N девелоперских окружений3. N тестовых окружений4. N pre-production окружений5. N баз данных6. N скриптов выкладки7. N мониторингов
Итого, как минимум:
N +1 => M + 7где M — количество единиц инфраструктуры до внедрения нового сервиса
Сводные запросы
Как быть если нужны сводные данные от 2 сервисов?
Например: вывести список банков с количеством доступных валют
Банк Количество валют
Банк 1 3
Банк 2 2
Банк3 4
... ...
Сервис-агрегатор
Можно сделать сервис-агрегатор
Сервис- Агрегатор
Bank-Info Currency
КлиентПлюсы:Отдельный уровень кешированияПростота основных сервисовНезависимость сервисов
Минусы:«Бутылочное горлышко»«Размазывание» логикиРастет инфраструктура (M+7)
«Разговорчивые» сервисы
Сервисы знают друг о друге и общаются
Bank-Info Currency
Клиент
Service Locator
getService
Service IP or Name
Плюсы:Сдерживаем рост инфраструктурыЛогика и кеш в одном местеНет «бутылочного горлышка»Сохраняется слабая связанность
(за счет broker'а)
Минусы:Сервисы слишком много знают
Что выбрали мы?
• Отказались от сервисов-агреггаторов
• Используем Service Locator и «разговорчивые» сервисы
• Для поисковых запросов: Sphinx index
Сетевые задержки!
1) Скорость эскадры определяется самым медленным кораблем!
2) Длинный путь запроса-ответа3) Бинарный или текстовый протокол?
Сервис- Агрегатор
Сервис 1 Сервис 2
Прокси
Клиент
Сервис 1 Сервис 2
Клиент
Service Broker
getServiceIP or domain
2
3 4
1
3
4Прокси
1
2
Сложности интеграции
Сервис должен работатьЕсли сервис «упал» - основной проект должен работатьСервис не должен тормозить основной проект«Жирный» или «тонкий» client-side?Учесть зависимости от других сервисовПреемственность API
Клиентское API должно быть неизменно!
А это значит:Ошибки при проектировании API — фатальны!
Единственный способ менять API — версии API
Если что-то забыли API — это ваши проблемы, а не клиента.
API должен быть достаточен для клиента
Выше порог вхождения
Ошибки проектирования — фатальны
Нужны программисты с опытом работы в SOA
Нужны JavaScript-программисты (жирный client-side)
Разные языки программирования (возможно)
Разные БД (возможно)
Нужны опытные администраторы
Нужны опытные тестировщики
Команда должна разделять ценности SOA
Зоопарк
Независимость SOA от платформы может привести кзоопарку технологий
Что можно сделать?•Системный архитектор – право «вето»
•Документировать все что можно
•Проводить внутреннееобучение (конференции)
•Сопоставлять эффект и стоимость поддержки
Рекомендации для старта
1. Составьте список сервисов2. Что вы оставите в «монолитной» части?3. Сделайте «пилотные» проекты сервисов на разных
платформах – сможете выбрать нужную4. Где нужен текстовый протокол, а где бинарный?5. Решите, для каких сервисов нужны виртуалки, а для
каких - свои сервера.6. Сервисы-агреггаторы или «разговорчивые» сервисы?7. Где обязательно нужна целостность данных?8. Где нужен «жирный», а где «тонкий» client-side?9. Где можно отказаться от транзакций?10. Выберите инструмент кеширования (memcache?
redis? что-то другое?)
Что нам дало SOA
Независимость разработки сервисов
Масштабирование – дешевле (виртуалки вместо серверов)
Балансировка нагрузки именно там где нужно
Точечный мониторинг
Ограниченность кода сервисов — проще разобраться
Подбор платформы под конкретный сервис
Сроки разработки точнее (~на 30%)
Возможность сразу отдавать данные партнерам (внешнее API)
Программистам интересно работать :)
