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

Что вас ждет на пути реализации SOA

(Битрикс отступает)

Савунов Василийbabr79@yandex.ru

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)

Программистам интересно работать :)

Спасибо за внимание!

Надеюсь, вам было интересно

Савунов Василий

babr79@yandex.ruskype: babr79