Псем привет, давно тут не был!

Ны работаем над проектом код которого в большенстве был разработан уже очень давно, и мягко скажем на сегодняшнуй день систем при нагрузке загибается. После многочисленных анализов и проб, мы пришли к выводу что пора нам двигаться в сторону сервис-ориентированной архитектуры. Много клиентов, множество не свазанных сервисов и т.д.
Сделали несколько пробных сервисов, что бы доказать работоспасобность.

Но мы воткнулись в следующий вопрос:
Вся аппликация разделяется на независимые (но потенциально связанные) функциональные области. На пример: сервис отвечающий за пользователей и сервис отвечающий за встречи это два независимых сервиса. Но дело в том что в том чесле есть требования знать какие пользователи подписались на какие встречи. Есественно, в сегодняшней ситуации это просто many-to-many связь через 3-ю таблицу, но то к чему мы хотим прийти, это максимальный разрыв, в том чесле разнести на разные базы данных. Какой самый удобный подход к такой ситуации?

Просо ныжен совет...

Спасибо.

Несколько не понял.
Что мешает разнести три таблицы по разным БД?

Ну кроме контроля целостности.

Проблемы никакой, но как то не вижу болього смысла порождать целый сервис только для поддержи связи.

Ну так можете верить в безбажность своего кода и не проверять целостность

А отдельная таблица не всегда означает отдельный сервис.

Согласен... И это как раз то что я изначально и стросил, и привёл пример... В надежде что есть какие то другие решения.

Шардинг пробовали?(оно применимо к ваше специфике?)

условная репликация не катит(возможно не всей таблицы, вьюхи)?...  Очень неприятно отказываться от fk и join...  И это, конечно хуже, чем всё в одной бд(с точки зрения целостности)...

В чём именно затык в произвоительности? Объёмы данных? Или контекст у приложения долго поднимается?


Добавлено @ 00:18
ещё раз прочитал... Разрыв контекста сервисов благотворно на безопасности может скажется (если там в другом дырок нет), а тормозов добавит... Плюс дублирование схем данных, что тоже не хорошо... А с инкапсуляцией вполне себе пакеты справиться могут...

Для повышения производительности бд можно порезать горизонтально (для каждой фирмы - своя бд, к примеру, повторяюсь)...

Напиши цель, чего ты хочешь добиться?

Добавлено @ 00:23
Да, по методологии... Советую повтыкать Фаулера (Шаблоны корпоративных приложений), конкретно идею 3слойной архитектуры. Слой работы с бд, Слой сервисов (выделяется по необходимости), слой человеческих посредников(веб странички, портлеты, формы)... А также посмотри работы Томаса Эрла, soa patterns.

Это сообщение отредактировал(а) Farmazon - 24.4.2013, 01:07

Затык главным образом в количестве запросов. У нас бешенное количество RPC запросов, и они приходят волнами. В результате в базе выстраивается очередь.



С такого сорта тормозами планируем совладать двумя слоями кеширования, так что думаю больших проблем не будет. Но самое главное сможем разгризить базу.



Что имеется в виду? почему дублирование схем данных? Под каждого клиента?  На самом деле это то что у нас сейчас и есть, добавлятся комплексность и дико дорого поддерживать.



То жего мы пытаемся добиться это производительность, масштабируемость, упростить поддержку и потенцияльно создать API для внутреннего пользования и партнёров.
На сегодняшний день:

Много клиентов и их будет больше. Самая большая проблемма что не известно сколько, так как мы переходим на self delivery модел
Большое количество баз данных. ООООЧЕНЬ сложно и дорого поддерживать
Имплементация стиля 90х годов - одна большая каша
Почти невозможно разширать функциолнальность без переделывания (что в принцепе не так плохо 

я сейчас нашару предлагать буду)


round-robin из серверовс сервисами(nginx вроде могёт)  с репликацией бд (катит?) Если скорость исполнения единичных запросов приемлемая... Повторюсь про шардинг за одно, у вас данные по строчкам разбиваются в группы? Если да, то резать горизонтально можно, меньше по объёму бд - шустрее запросы.

Насчёт сильно сложно поддерживать несколько... фиг знает... честно.  Можно ведь все операции заскриптовать... накатывание обновлений, сбор бекапов и прочее... Ну а код особо не поменяется, если делать аккуратно...

Дублирование схем = несколько баз с своими схемами + возможно несколько маппингов(если у вас ОРМ езь), на поддержку больше сил уходит... Лучше одна хорошо продокументированная схема, чем несколько плохо... В конце концов на пакеты разрезать можно(вот тут у джанго можно посмотреть как они этого добиваются, надеюсь не расист?)...

Кеширование - поддерживаю, но только зачем для этого полностью сервисы изолировать?... И повсеместно кеширование тоже может не потребоваться... Смотреть надо. С кешами эксперементировать надо... Одно дело те, что живут мало, сложнее с теми, что больше... Они и память жрут, потому они выгружаться в внешнюю бд будут(файлы, редиска или мемкеш), а там и на диск могут... Подсасывание такого кеша может быть соизмеримо с запросом в бд.  Плюс возникнет проблема с консистентностью данных, кеширование и обновление кэша аккуратно планировать надо... Короче свой геморрой. Бывает, что от кешей вообще толку нет, если стараться предугадать запрос клиента и выдавать инфы с избытком на запрос(т.е. порции данных больше и избыточнее, переключений контекста меньше...). Опять же, сервисы можно заставить работать с пакетами команд, можно сделать ассинхронными...



Это сообщение отредактировал(а) Farmazon - 24.4.2013, 03:47

Спасибо, 

вариантов на самом деле множество, вот мы и эксперементируем и пытаемся от других научиться.

А вот не угадаешь... специфика. Я вот могу вспомнить 2 проекта своих сразу: в одном из них кеши давали прирост в 70% быстродействия, а в другом - 0 (ну или около 5%)...

из этого следует, что они весьма зависимы (как минимум - встречи от пользователей). значит, даже разделяя на разные базы, потребуется связь между ними (не доп. сервис, а внутренний механизм). в отношении пользователей, например, можете организовать отдельный сервер аутентификации, через который все сервисы будут работать.

Я значит не понял

Вот у вас уже есть ситуация


Других подходов к этому подходу нет.
Возможно есть другие варианты решения стоящей перед вами проблемы. Но о них никто не спрашивал.

Добавлено через 12 минут и 8 секунд

RPC сам по себе не быстр. Т.е. вы же разрулили его обработку каким-то образом.

Они работают с одними и теми же данными?
Запросы какого рода приходят? Выборки, или апдейты/вставки?
Какую латентность они могут иметь?

Это все влияет на конечное решение в итоге.