Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
Что вас ждет на пути реализации
SOA
(Битрикс отступает)
Савунов Василий
babr79@yandex.ru
skype: babr79
Цель доклада
 Рассказ на тему «Битрикс в banki.ru»
 Немного рассказать о SOA
 Поделиться нашим опытом внедрения SOA
 П...
Битрикс в banki.ru
 Проблемы масштабирования
 Битрикс – большой
 Спагетти-код, бестолковая файловая структура
 Unit-те...
К чему хотелось придти?
 Для разработчиков:
 Перестать копаться в legacy-коде
 Современный framework
 Уменьшить связан...
Какие есть варианты?
Переписать все с нуля
Плюсы
 Сделаем все хорошо :)
 Не влияем на текущую разработку
Минусы
 Дорого
 Долго
 Нужна отде...
“Подложить” другой framework
Плюсы
 Сделаем все хорошо, но по частям
Минусы
 Непредсказуемость интеграции с Битрикс
 Ра...
Перейти на SOA
Плюсы
 Выбираем framework под сервис
 Понятные границы работ
 Прогнозируемые сроки
 Нет влияния на осно...
Service Oriented Architecture
Основной плюс SOA – атомарные, небольшие,
стабильные сервисы, вместе обеспечивающие нужный
ф...
Монолит vs SOA
Монолитная
архитектура
SOA
К чему хотелось прийти в итоге
Старт
• Форум
• Блоги
• Банки
• Банки на карте
• Кредиты
• Вклады
• Новости
• Фин. Рейтинги...
Что вас ждет на пути SOA?
Начинаем обзор маршрута
Нужно изменить мышление!
SOA — хорошая идея, но трудная задача
Реогранизовать
архитектуру Вот так
Чтобы получить
вот это
М...
Вопросы проектирования SOA
 Как «резать» бизнес-логику на сервисы?
 Где границы сервисов?
 Должны ли сервисы общаться д...
Из нашей практики
проектирования
• Отталкивайтесь от объектной модели при проектировании
• 1 связь – кандидат в сервис
• >...
Слабая связанность!
БД сервисов не общаются напрямую!
 Нет JOIN'ов, нет подзапросов
 Данные другого сервиса = +1 API-зап...
Пример
Задача: получить курсы валют для ближайших банков
Bank-InfoGeo Currency
getNearestXY getProperties getList
1 запрос...
Инфраструктура растет быстро!
Для N сервисов нужно (как минимум):
1. N виртуалок (или серверов)
2. N девелоперских окружен...
Сводные запросы
Как быть если нужны сводные данные от 2 сервисов?
Например: вывести список банков с количеством
доступных ...
Сервис-агрегатор
Можно сделать сервис-агрегатор
Сервис-
Агрегатор
Bank-Info Currency
Клиент
Плюсы:
 Отдельный уровень кеш...
«Разговорчивые» сервисы
Сервисы знают друг о друге и общаются
Bank-Info Currency
Клиент
Service
Locator
getService
Service...
Что выбрали мы?
• Отказались от сервисов-агреггаторов
• Используем Service Locator и «разговорчивые» сервисы
• Для поисков...
Сетевые задержки!
1) Скорость эскадры определяется самым медленным
кораблем!
2) Длинный путь запроса-ответа
3) Бинарный ил...
Сложности интеграции
 Сервис должен работать
 Если сервис «упал» - основной проект должен работать
 Сервис не должен то...
Клиентское API должно быть
неизменно!
А это значит:
Ошибки при проектировании API — фатальны!
Единственный способ менять...
Выше порог вхождения
 Ошибки проектирования — фатальны
 Нужны программисты с опытом работы в SOA
 Нужны JavaScript-прог...
Зоопарк
Независимость SOA от платформы может привести к
зоопарку технологий
Что можно сделать?
•Системный
архитектор – пра...
Рекомендации для старта
1. Составьте список сервисов
2. Что вы оставите в «монолитной» части?
3. Сделайте «пилотные» проек...
Что нам дало SOA
 Независимость разработки сервисов
 Масштабирование – дешевле (виртуалки вместо серверов)
 Балансировк...
Спасибо за внимание!
Надеюсь, вам было интересно
Савунов Василий
babr79@yandex.ru
skype: babr79
Próxima SlideShare
Cargando en…5
×

Что вас ждет на пути реализации Soa (Битрикс отступает)

767 visualizaciones

Publicado el

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

Publicado en: Internet
  • Sé el primero en comentar

Что вас ждет на пути реализации Soa (Битрикс отступает)

  1. 1. Что вас ждет на пути реализации SOA (Битрикс отступает) Савунов Василий babr79@yandex.ru skype: babr79
  2. 2. Цель доклада  Рассказ на тему «Битрикс в banki.ru»  Немного рассказать о SOA  Поделиться нашим опытом внедрения SOA  Предупредить о трудностях  Вопросы для размышления  Рекомендации
  3. 3. Битрикс в banki.ru  Проблемы масштабирования  Битрикс – большой  Спагетти-код, бестолковая файловая структура  Unit-тесты для компонент Битрикс – проблема  Инфоблоки ;(  Обновления Битрикс непредсказуемо меняют API  Новые ―фишки‖ и bugfix – ждем обновления Битрикс  Демотивация разработчиков
  4. 4. К чему хотелось придти?  Для разработчиков:  Перестать копаться в legacy-коде  Современный framework  Уменьшить связанность кода  Возможность покрыть Unit-тестами код  Чтобы было интересно работать!  Для бизнеса:  Держать нагрузку  Чтобы сроки не срывались  Минимизация неожиданностей  Снижение издержек
  5. 5. Какие есть варианты?
  6. 6. Переписать все с нуля Плюсы  Сделаем все хорошо :)  Не влияем на текущую разработку Минусы  Дорого  Долго  Нужна отдельная команда и менеджер  Что-то потеряем по дороге обязательно  Трудно прогнозировать сроки  А что делать с текущими проектами?  А чем будет заниматься текущая команда?
  7. 7. “Подложить” другой framework Плюсы  Сделаем все хорошо, но по частям Минусы  Непредсказуемость интеграции с Битрикс  Разработка одновременно на 2х платформах  Труднее отследить причины багов  Труднее тестировать  Как быть с обновлениями Битрикс?
  8. 8. Перейти на SOA Плюсы  Выбираем framework под сервис  Понятные границы работ  Прогнозируемые сроки  Нет влияния на основной проект  Слабая связанность  Ограниченный объем кода Минусы  Труднее отследить причины багов  Риск ―зоопарка‖  Разрастается инфраструктура  Трудности с целостностью данных
  9. 9. Service Oriented Architecture Основной плюс SOA – атомарные, небольшие, стабильные сервисы, вместе обеспечивающие нужный функционал Сервис = автономный модуль системы, предоставляющий доступ к своим данным через API БД1 БД2 БД3 Фронтенд Бэкенд Прокси Сервис1 Сервис2 Сервис3
  10. 10. Монолит vs SOA Монолитная архитектура SOA
  11. 11. К чему хотелось прийти в итоге Старт • Форум • Блоги • Банки • Банки на карте • Кредиты • Вклады • Новости • Фин. Рейтинги • Друзья банков • Народный рейтинг • Служебный рейтинг • etc. Битрикс Отображение view Битрикс Банки Новости Фин. рейтинги Кредиты Вклады Банки на карте Народный рейтинг Служебный рейтинг Друзья банков Финиш APIAPI APIAPI API API API API API Форум Блоги
  12. 12. Что вас ждет на пути SOA? Начинаем обзор маршрута
  13. 13. Нужно изменить мышление! SOA — хорошая идея, но трудная задача Реогранизовать архитектуру Вот так Чтобы получить вот это Монолитная архитектура Бизнес - сервисы Гибкость и распределенность
  14. 14. Вопросы проектирования SOA  Как «резать» бизнес-логику на сервисы?  Где границы сервисов?  Должны ли сервисы общаться друг с другом?  БД: общая или сегментация по сервисам?  «Жирный» client-side, или «тонкий»?  Общий кеш, или по-сервисно?  Как быть со сложными выборками?
  15. 15. Из нашей практики проектирования • Отталкивайтесь от объектной модели при проектировании • 1 связь – кандидат в сервис • >1 связи - несколько сущностей в одном сервисе • Сильно связанные сущности - в одну БД • Атомарные сервисы проще в поддержке, и не создают зависимостей • Преимущественно «тонкий» client-side • Кеш под каждый сервис (в т.ч. и под сервис-агреггатор) • Сложные выборки – Sphinx, сервисы-агреггаторы
  16. 16. Слабая связанность! БД сервисов не общаются напрямую!  Нет JOIN'ов, нет подзапросов  Данные другого сервиса = +1 API-запрос  Набор данных из разных сервисов = несколько запросов к API + бизнес-логика  Накладные расходы на обеспечение целостности данных  Вместо транзакций – очереди (RabbitMQ) SQL API
  17. 17. Пример Задача: получить курсы валют для ближайших банков Bank-InfoGeo Currency getNearestXY getProperties getList 1 запрос 2 запрос 3 запрос
  18. 18. Инфраструктура растет быстро! Для N сервисов нужно (как минимум): 1. N виртуалок (или серверов) 2. N девелоперских окружений 3. N тестовых окружений 4. N pre-production окружений 5. N баз данных 6. N скриптов выкладки 7. N мониторингов Итого, как минимум: N +1 => M + 7 где M — количество единиц инфраструктуры до внедрения нового сервиса
  19. 19. Сводные запросы Как быть если нужны сводные данные от 2 сервисов? Например: вывести список банков с количеством доступных валют Банк Количество валют Банк 1 3 Банк 2 2 Банк3 4 ... ...
  20. 20. Сервис-агрегатор Можно сделать сервис-агрегатор Сервис- Агрегатор Bank-Info Currency Клиент Плюсы:  Отдельный уровень кеширования  Простота основных сервисов  Независимость сервисов Минусы:  «Бутылочное горлышко»  «Размазывание» логики  Растет инфраструктура (M+7)
  21. 21. «Разговорчивые» сервисы Сервисы знают друг о друге и общаются Bank-Info Currency Клиент Service Locator getService Service IP or Name Плюсы:  Сдерживаем рост инфраструктуры  Логика и кеш в одном месте  Нет «бутылочного горлышка»  Сохраняется слабая связанность (за счет broker'а) Минусы:  Сервисы слишком много знают
  22. 22. Что выбрали мы? • Отказались от сервисов-агреггаторов • Используем Service Locator и «разговорчивые» сервисы • Для поисковых запросов: Sphinx index
  23. 23. Сетевые задержки! 1) Скорость эскадры определяется самым медленным кораблем! 2) Длинный путь запроса-ответа 3) Бинарный или текстовый протокол? Сервис- Агрегатор Сервис 1 Сервис 2 Прокси Клиент Сервис 1 Сервис 2 Клиент Service Broker getService IP or domain 2 3 4 1 3 4 Прокси 1 2
  24. 24. Сложности интеграции  Сервис должен работать  Если сервис «упал» - основной проект должен работать  Сервис не должен тормозить основной проект  «Жирный» или «тонкий» client-side?  Учесть зависимости от других сервисов  Преемственность API
  25. 25. Клиентское API должно быть неизменно! А это значит: Ошибки при проектировании API — фатальны! Единственный способ менять API — версии API Если что-то забыли API — это ваши проблемы, а не клиента. API должен быть достаточен для клиента
  26. 26. Выше порог вхождения  Ошибки проектирования — фатальны  Нужны программисты с опытом работы в SOA  Нужны JavaScript-программисты (жирный client-side)  Разные языки программирования (возможно)  Разные БД (возможно)  Нужны опытные администраторы  Нужны опытные тестировщики  Команда должна разделять ценности SOA
  27. 27. Зоопарк Независимость SOA от платформы может привести к зоопарку технологий Что можно сделать? •Системный архитектор – право «вето» •Документировать все что можно •Проводить внутреннее обучение (конференции) •Сопоставлять эффект и стоимость поддержки
  28. 28. Рекомендации для старта 1. Составьте список сервисов 2. Что вы оставите в «монолитной» части? 3. Сделайте «пилотные» проекты сервисов на разных платформах – сможете выбрать нужную 4. Где нужен текстовый протокол, а где бинарный? 5. Решите, для каких сервисов нужны виртуалки, а для каких - свои сервера. 6. Сервисы-агреггаторы или «разговорчивые» сервисы? 7. Где обязательно нужна целостность данных? 8. Где нужен «жирный», а где «тонкий» client-side? 9. Где можно отказаться от транзакций? 10. Выберите инструмент кеширования (memcache? redis? что-то другое?)
  29. 29. Что нам дало SOA  Независимость разработки сервисов  Масштабирование – дешевле (виртуалки вместо серверов)  Балансировка нагрузки именно там где нужно  Точечный мониторинг  Ограниченность кода сервисов — проще разобраться  Подбор платформы под конкретный сервис  Сроки разработки точнее (~на 30%)  Возможность сразу отдавать данные партнерам (внешнее API)  Программистам интересно работать :)
  30. 30. Спасибо за внимание! Надеюсь, вам было интересно Савунов Василий babr79@yandex.ru skype: babr79

×