Рассказ о том, как проект banki.ru принял решение убегать от Битрикса через SOA, а так же о том, как мы бежали к SOA, и что получилось в итоге

1. Что вас ждет на пути реализации
SOA
(Битрикс отступает)
Савунов Василий
babr79@yandex.ru
skype: babr79

2. Цель доклада
 Рассказ на тему «Битрикс в banki.ru»
 Немного рассказать о SOA
 Поделиться нашим опытом внедрения SOA
 Предупредить о трудностях
 Вопросы для размышления
 Рекомендации

3. Битрикс в banki.ru
 Проблемы масштабирования
 Битрикс – большой
 Спагетти-код, бестолковая файловая структура
 Unit-тесты для компонент Битрикс – проблема
 Инфоблоки ;(
 Обновления Битрикс непредсказуемо меняют API
 Новые ―фишки‖ и bugfix – ждем обновления Битрикс
 Демотивация разработчиков

4. К чему хотелось придти?
 Для разработчиков:
 Перестать копаться в legacy-коде
 Современный framework
 Уменьшить связанность кода
 Возможность покрыть Unit-тестами код
 Чтобы было интересно работать!
 Для бизнеса:
 Держать нагрузку
 Чтобы сроки не срывались
 Минимизация неожиданностей
 Снижение издержек

5. Какие есть варианты?

6. Переписать все с нуля
Плюсы
 Сделаем все хорошо :)
 Не влияем на текущую разработку
Минусы
 Дорого
 Долго
 Нужна отдельная команда и менеджер
 Что-то потеряем по дороге обязательно
 Трудно прогнозировать сроки
 А что делать с текущими проектами?
 А чем будет заниматься текущая команда?

7. “Подложить” другой framework
Плюсы
 Сделаем все хорошо, но по частям
Минусы
 Непредсказуемость интеграции с Битрикс
 Разработка одновременно на 2х платформах
 Труднее отследить причины багов
 Труднее тестировать
 Как быть с обновлениями Битрикс?

8. Перейти на SOA
Плюсы
 Выбираем framework под сервис
 Понятные границы работ
 Прогнозируемые сроки
 Нет влияния на основной проект
 Слабая связанность
 Ограниченный объем кода
Минусы
 Труднее отследить причины багов
 Риск ―зоопарка‖
 Разрастается инфраструктура
 Трудности с целостностью данных

9. Service Oriented Architecture
Основной плюс SOA – атомарные, небольшие,
стабильные сервисы, вместе обеспечивающие нужный
функционал
Сервис = автономный модуль системы,
предоставляющий доступ к своим данным через API
БД1
БД2
БД3
Фронтенд
Бэкенд
Прокси
Сервис1
Сервис2
Сервис3

10. Монолит vs SOA
Монолитная
архитектура
SOA

11. К чему хотелось прийти в итоге
Старт
• Форум
• Блоги
• Банки
• Банки на карте
• Кредиты
• Вклады
• Новости
• Фин. Рейтинги
• Друзья банков
• Народный рейтинг
• Служебный рейтинг
• etc.
Битрикс
Отображение
view
Битрикс
Банки
Новости
Фин.
рейтинги
Кредиты
Вклады
Банки
на
карте
Народный
рейтинг
Служебный
рейтинг
Друзья
банков
Финиш
APIAPI
APIAPI
API
API
API
API
API
Форум Блоги

12. Что вас ждет на пути SOA?
Начинаем обзор маршрута

13. Нужно изменить мышление!
SOA — хорошая идея, но трудная задача
Реогранизовать
архитектуру Вот так
Чтобы получить
вот это
Монолитная
архитектура
Бизнес -
сервисы
Гибкость и
распределенность

14. Вопросы проектирования SOA
 Как «резать» бизнес-логику на сервисы?
 Где границы сервисов?
 Должны ли сервисы общаться друг с другом?
 БД: общая или сегментация по сервисам?
 «Жирный» client-side, или «тонкий»?
 Общий кеш, или по-сервисно?
 Как быть со сложными выборками?

15. Из нашей практики
проектирования
• Отталкивайтесь от объектной модели при проектировании
• 1 связь – кандидат в сервис
• >1 связи - несколько сущностей в одном сервисе
• Сильно связанные сущности - в одну БД
• Атомарные сервисы проще в поддержке, и не создают
зависимостей
• Преимущественно «тонкий» client-side
• Кеш под каждый сервис (в т.ч. и под сервис-агреггатор)
• Сложные выборки – Sphinx, сервисы-агреггаторы

16. Слабая связанность!
БД сервисов не общаются напрямую!
 Нет JOIN'ов, нет подзапросов
 Данные другого сервиса = +1 API-запрос
 Набор данных из разных сервисов =
несколько запросов к API + бизнес-логика
 Накладные расходы на обеспечение
целостности данных
 Вместо транзакций – очереди (RabbitMQ)
SQL
API

17. Пример
Задача: получить курсы валют для ближайших банков
Bank-InfoGeo Currency
getNearestXY getProperties getList
1 запрос 2 запрос 3 запрос

18. Инфраструктура растет быстро!
Для N сервисов нужно (как минимум):
1. N виртуалок (или серверов)
2. N девелоперских окружений
3. N тестовых окружений
4. N pre-production окружений
5. N баз данных
6. N скриптов выкладки
7. N мониторингов
Итого, как минимум:
N +1 => M + 7
где M — количество единиц инфраструктуры до внедрения нового сервиса

19. Сводные запросы
Как быть если нужны сводные данные от 2 сервисов?
Например: вывести список банков с количеством
доступных валют
Банк Количество валют
Банк 1 3
Банк 2 2
Банк3 4
... ...

20. Сервис-агрегатор
Можно сделать сервис-агрегатор
Сервис-
Агрегатор
Bank-Info Currency
Клиент
Плюсы:
 Отдельный уровень кеширования
 Простота основных сервисов
 Независимость сервисов
Минусы:
 «Бутылочное горлышко»
 «Размазывание» логики
 Растет инфраструктура (M+7)

21. «Разговорчивые» сервисы
Сервисы знают друг о друге и общаются
Bank-Info Currency
Клиент
Service
Locator
getService
Service IP
or Name
Плюсы:
 Сдерживаем рост инфраструктуры
 Логика и кеш в одном месте
 Нет «бутылочного горлышка»
 Сохраняется слабая связанность
(за счет broker'а)
Минусы:
 Сервисы слишком много знают

22. Что выбрали мы?
• Отказались от сервисов-агреггаторов
• Используем Service Locator и «разговорчивые» сервисы
• Для поисковых запросов: Sphinx index

23. Сетевые задержки!
1) Скорость эскадры определяется самым медленным
кораблем!
2) Длинный путь запроса-ответа
3) Бинарный или текстовый протокол?
Сервис-
Агрегатор
Сервис 1 Сервис 2
Прокси
Клиент
Сервис 1 Сервис 2
Клиент
Service
Broker
getService
IP or domain
2
3 4
1
3
4
Прокси
1
2

24. Сложности интеграции
 Сервис должен работать
 Если сервис «упал» - основной проект должен работать
 Сервис не должен тормозить основной проект
 «Жирный» или «тонкий» client-side?
 Учесть зависимости от других сервисов
 Преемственность API

25. Клиентское API должно быть
неизменно!
А это значит:
Ошибки при проектировании API — фатальны!
Единственный способ менять API — версии API
Если что-то забыли API — это ваши проблемы, а не
клиента.
API должен быть достаточен для клиента

26. Выше порог вхождения
 Ошибки проектирования — фатальны
 Нужны программисты с опытом работы в SOA
 Нужны JavaScript-программисты (жирный client-side)
 Разные языки программирования (возможно)
 Разные БД (возможно)
 Нужны опытные администраторы
 Нужны опытные тестировщики
 Команда должна разделять ценности SOA

27. Зоопарк
Независимость SOA от платформы может привести к
зоопарку технологий
Что можно сделать?
•Системный
архитектор – право «вето»
•Документировать все
что можно
•Проводить внутреннее
обучение (конференции)
•Сопоставлять эффект
и стоимость поддержки

28. Рекомендации для старта
1. Составьте список сервисов
2. Что вы оставите в «монолитной» части?
3. Сделайте «пилотные» проекты сервисов на разных
платформах – сможете выбрать нужную
4. Где нужен текстовый протокол, а где бинарный?
5. Решите, для каких сервисов нужны виртуалки, а для
каких - свои сервера.
6. Сервисы-агреггаторы или «разговорчивые» сервисы?
7. Где обязательно нужна целостность данных?
8. Где нужен «жирный», а где «тонкий» client-side?
9. Где можно отказаться от транзакций?
10. Выберите инструмент кеширования (memcache?
redis? что-то другое?)

29. Что нам дало SOA
 Независимость разработки сервисов
 Масштабирование – дешевле (виртуалки вместо серверов)
 Балансировка нагрузки именно там где нужно
 Точечный мониторинг
 Ограниченность кода сервисов — проще разобраться
 Подбор платформы под конкретный сервис
 Сроки разработки точнее (~на 30%)
 Возможность сразу отдавать данные партнерам (внешнее API)
 Программистам интересно работать :)

30. Спасибо за внимание!
Надеюсь, вам было интересно
Савунов Василий
babr79@yandex.ru
skype: babr79