Что вас ждет на пути реализации Soa (Битрикс отступает)
•Download as PPT, PDF•
1 like•975 views
Рассказ о том, как проект banki.ru принял решение убегать от Битрикса через SOA, а так же о том, как мы бежали к SOA, и что получилось в итоге
1 of 30
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
More Related Content
Что вас ждет на пути реализации Soa (Битрикс отступает)
1. Что вас ждет на пути реализации
SOA
(Битрикс отступает)
Савунов Василий
babr79@yandex.ru
skype: babr79
2. Цель доклада
Рассказ на тему «Битрикс в banki.ru»
Немного рассказать о SOA
Поделиться нашим опытом внедрения SOA
Предупредить о трудностях
Вопросы для размышления
Рекомендации
3. Битрикс в banki.ru
Проблемы масштабирования
Битрикс – большой
Спагетти-код, бестолковая файловая структура
Unit-тесты для компонент Битрикс – проблема
Инфоблоки ;(
Обновления Битрикс непредсказуемо меняют API
Новые ―фишки‖ и bugfix – ждем обновления Битрикс
Демотивация разработчиков
4. К чему хотелось придти?
Для разработчиков:
Перестать копаться в legacy-коде
Современный framework
Уменьшить связанность кода
Возможность покрыть Unit-тестами код
Чтобы было интересно работать!
Для бизнеса:
Держать нагрузку
Чтобы сроки не срывались
Минимизация неожиданностей
Снижение издержек
6. Переписать все с нуля
Плюсы
Сделаем все хорошо :)
Не влияем на текущую разработку
Минусы
Дорого
Долго
Нужна отдельная команда и менеджер
Что-то потеряем по дороге обязательно
Трудно прогнозировать сроки
А что делать с текущими проектами?
А чем будет заниматься текущая команда?
7. “Подложить” другой framework
Плюсы
Сделаем все хорошо, но по частям
Минусы
Непредсказуемость интеграции с Битрикс
Разработка одновременно на 2х платформах
Труднее отследить причины багов
Труднее тестировать
Как быть с обновлениями Битрикс?
8. Перейти на SOA
Плюсы
Выбираем framework под сервис
Понятные границы работ
Прогнозируемые сроки
Нет влияния на основной проект
Слабая связанность
Ограниченный объем кода
Минусы
Труднее отследить причины багов
Риск ―зоопарка‖
Разрастается инфраструктура
Трудности с целостностью данных
9. Service Oriented Architecture
Основной плюс SOA – атомарные, небольшие,
стабильные сервисы, вместе обеспечивающие нужный
функционал
Сервис = автономный модуль системы,
предоставляющий доступ к своим данным через API
БД1
БД2
БД3
Фронтенд
Бэкенд
Прокси
Сервис1
Сервис2
Сервис3
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
... ...
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)
Программистам интересно работать :)