Эффективный обмен данными между тремя веб сайтами?

Question

[Станислав Катков]

Добрый день,

Унаследовал три веб сервиса на Ruby On Rails которые я постепенно улучшаю. И есть у меня одна проблема архитектурная которую я постоянно обходил стороной и отказывался решать, но время пришло...

и так, ПРОБЛЕМА:
Три апликейшена по сути шарят базу между друг другом. (т.е. все читают\пишут из одной базы на прямую). У этого способа есть свои плюсы и свои недостатки:
- Приходиться копировать модели везде (и тесты вместе с ними)
- опять же, приходится очень четко проверять чтобы все верикации данных ВЕЗДЕ работали одинаково, чтобы потом как нибудь не случилось страшного
- Проблемы с миграциями, приходиться как минимум рестартить апликейшены после деплоя миграций (чтобы все схемы обновились)
- Сложно гарантировать секьюрность данных, когда все три аппы имееют одинаковый доступ к базе. Если бы одна аппа имела доступ к базе и раздавала это другим - мне бы спалось спокойнее.

Хочется сделать один апликейшен основным - чтобы только один из них имел доступ к базе.

Варианты которые я рассматривал, но отбросил:
- Репликация базы данных - каждое из апликейшенов не только читает, но и пишет данные в базу. ПОэтому придется создавать двух-сторонюю репликацию (между тремя базами) - звучит страшно, не хочу.
- Создание JSON API - у нас уже есть апи у "главного" прилажения, которые отдает данные мобильным приложениям. Но придется значительно расширить это апи (функциональность мобильных приложений крайне лимитировано, и они не потребляет все данные что нужны другим сайтам), а так же придется написать код которые эти данные читает - дофига работы помоему для нашей маленькой команды

Что для меня является главным:
- Максимальная секьюрность данных (желатетльно шифрованый канал)
- Крайне мало ресурсов в моих распоряжении (3 человека один из них тестер) - поэтому максимальная простота имплементации
- Возможность постепенного введения - мы наврятли сможем все апликейшены сразу перенести на новую архитектуру
- Быстрая скорость считывания данных (чтобы не нужно было ничего кэшировать на стороних аппах) - желательно наверно держать постоянно открытое соединение к основному серверу. (запись в базу может быть eventually consistent")

Какие варианты я рассматриваю:
- Event Sourcing - мы уже испльзуем Redis, возможно использовать для записи данных. Как вариант, можно продолжать считывать напрямую из базы, но запись в базу только через Event Sourcing.
- WebSockets - вариант который мне кажется сейчас самым подходящим
- ActiveRecord::Live - ни разу не пробовал даже, поэтому пока еще не понимаю что это такое.

С удовольствием бы послушал ваше мнение как решить такую проблему.

Answer 1

[vsuhachev]

Принципиально есть 2 варианта:

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

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

Answer 2

[Антон Радушев]

возможно предложение не корректное, но почему бы не сделать через engine?
модели в основной области видимости, контроллеры раскидать по нескольким engine и как то роутингом разруливать все?

Comments

[Станислав Катков]

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

Опять же, все равно все три приложения будут читать на прямую из базы. Такое решение никак не улучшает ситуацию с безопасностью данных (а хотелось бы, клиент очень за это переживает) :\

Answer 3

[sim3x]

Убери дублирование кода
Сделай многосайтовость - единая БД убирает необходимость обмена данными между сайтами = меньше кода = меньше ошибок
Репликацию лучше наладить в целях сохранности данных в БД

- WebSockets - вариант который мне кажется сейчас самым подходящим

оверкил

Event Sourcingесли речь про https://developer.mozilla.org/en-US/docs/Web/API/E... то он оптимален для самописного варианта асинхронного взаимодействия фроентед-бекенд

- Сложно гарантировать секьюрность данных, когда все три аппы имееют одинаковый доступ к базе. Если бы одна аппа имела доступ к базе и раздавала это другим - мне бы спалось спокойнее.

и получишь единую точку отказа для трех сайтов и такой же уровнеь секурности

- Максимальная секьюрность данных (желатетльно шифрованый канал)

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

Пилишь АПИ - пили фронтенд в виде SPA

Comments

[Everything_is_not_so_bad]

и получишь единую точку отказа для трех сайтов и такой же уровнеь секурности

Разве не лучше иметь 1 точку отказа, чем несколько?
Станислав Катков

[sim3x]

Роман Мирр: не "одну", а еще одну, долнительную, точку отказа

Answer 4

[Everything_is_not_so_bad]

У нас в компании те же задачи стоят, с разницей что не 3, а 2 веб-сервиса, написанных на разных языках и разных платформах.
Моё видение таково, что необходимо компонент за компонентом переводить на центральный веб-сервис JSON API, имеющий доступ к СУБД. API обязан иметь аутентикацию (JSON Web Token или OAuth 2) и быть доступным только по HTTPS и HSTS.

Всю предметную логику нужно иметь в одном месте для гарантии правильности работы и сокращения необходимых для разработки ресурсов.
Гарантию правильности даст покрытие тестами. Станет проще разрабатывать и не нужно будет разрываться на части. То есть двигаться можно в сторону расчленения на более мелкие сервисы. Будет проще разграничить зону ответственности каждому разработчику.

Если есть какие-то общие задачи, особенно долгоиграющие, то необходимо использовать очереди сообщений при помощи такого ПО как Beanstalk, RabbitMQ или использовать сторонние API. С помощью очередей можно добиться масштабируемости, отказоустойчивости и отвязаться от связанности сервисов и используемых технологий.

Быстрая скорость считывания данных

Она обеспечивается правильной архитектурой приложения и кешированием данных на API сервере, зная типичные сценарии использования. Тут могут подойти всякие решения типа memchached, Aerospike и т.д.
Согласен с sim3x что WebSockets излишен для этих целей.