Нормальна ли такая архитектура обмена данными? Суть — сайт платных объявлений о продаже недвижимости. Интересует, насколько разумно использовать архитектуру, описанную ниже.
Основную часть работы по размещению объявлений осуществляют менеджеры из офиса, также критично чтобы актуальная база объявлений и все данные о платежах содержались в одном контролируемом месте. При этом в вебе для подателей объявлений должно быть реализовано некое подобие личного кабинета, где они могли бы править свои объявления.
Предлагается полную БД со всеми данными проекта вести внутри офиса на какой-либо СУБД/CRM, а в интернете держать лишь отражение/зеркало данных, необходимых для работы сайта.
Данные синхронизируются из БД в веб при изменениях, а также из веба в БД при изменениях клиентами из своих личных кабинетов. Предполагается, что процесс должен быть относительно оперативным (скажем, 5 минутная задержка позволяется).
В СУБД/CRM формируется очередь запросов/команд на обновление, которые отправляются в интернет по крону. Аналогичная очередь есть на стороне веб-сайта, она содержит данные, которые были изменены из личных кабинетов и которые нужно внести в СУБД/CRM.
Запросы в обоих очередях движутся по запуску ботов-воркеров и в зависимости от результатов выполнения помечаются как выполненные/невыполненные. Делается это чтобы не потерять какие-либо изменения и в случае чего видеть какие запросы не отработали как «сверху» (с сайта) так и снизу (из CRM).
Файлы (фото) синхронизируются простым копированием, скажем, посредством rsync по FTP или типа того.
Все (объявления, данные о платежах и бизнес-логику взаиморасчетов) держать в интернете не хочется: данные коммерчески критичные. Плюс в случае сбоев хотелось бы чтобы в офисе оставался актуальный набор данных и с ним можно было продолжать работу до восстановления соединения, после чего накопившиеся запросы уходили бы из очереди на сайт.
Предполагается, что при такой схеме может быть обеспечен быстрый переезд офиса и сайта.
Так — нормально? Может есть какие-то более разумные практики и решения?
Буду благодарен за любые мнения, даже сугубо скептические.
Нормальна ли такая архитектура обмена данными? Суть — сайт платных объявлений о продаже недвижимости. Интересует, насколько разумно использовать архитектуру, описанную ниже.
Основную часть работы по размещению объявлений осуществляют менеджеры из офиса, также критично чтобы актуальная база объявлений и все данные о платежах содержались в одном контролируемом месте. При этом в вебе для подателей объявлений должно быть реализовано некое подобие личного кабинета, где они могли бы править свои объявления.
Предлагается полную БД со всеми данными проекта вести внутри офиса на какой-либо СУБД/CRM, а в интернете держать лишь отражение/зеркало данных, необходимых для работы сайта.
Данные синхронизируются из БД в веб при изменениях, а также из веба в БД при изменениях клиентами из своих личных кабинетов. Предполагается, что процесс должен быть относительно оперативным (скажем, 5 минутная задержка позволяется).
В СУБД/CRM формируется очередь запросов/команд на обновление, которые отправляются в интернет по крону. Аналогичная очередь есть на стороне веб-сайта, она содержит данные, которые были изменены из личных кабинетов и которые нужно внести в СУБД/CRM.
Запросы в обоих очередях движутся по запуску ботов-воркеров и в зависимости от результатов выполнения помечаются как выполненные/невыполненные. Делается это чтобы не потерять какие-либо изменения и в случае чего видеть какие запросы не отработали как «сверху» (с сайта) так и снизу (из CRM).
Файлы (фото) синхронизируются простым копированием, скажем, посредством rsync по FTP или типа того.
Все (объявления, данные о платежах и бизнес-логику взаиморасчетов) держать в интернете не хочется: данные коммерчески критичные. Плюс в случае сбоев хотелось бы чтобы в офисе оставался актуальный набор данных и с ним можно было продолжать работу до восстановления соединения, после чего накопившиеся запросы уходили бы из очереди на сайт.
Предполагается, что при такой схеме может быть обеспечен быстрый переезд офиса и сайта.
Так — нормально? Может есть какие-то более разумные практики и решения?
Буду благодарен за любые мнения, даже сугубо скептические.
Основную часть работы по размещению объявлений осуществляют менеджеры из офиса, также критично чтобы актуальная база объявлений и все данные о платежах содержались в одном контролируемом месте. При этом в вебе для подателей объявлений должно быть реализовано некое подобие личного кабинета, где они могли бы править свои объявления.
Предлагается полную БД со всеми данными проекта вести внутри офиса на какой-либо СУБД/CRM, а в интернете держать лишь отражение/зеркало данных, необходимых для работы сайта.
Данные синхронизируются из БД в веб при изменениях, а также из веба в БД при изменениях клиентами из своих личных кабинетов. Предполагается, что процесс должен быть относительно оперативным (скажем, 5 минутная задержка позволяется).
В СУБД/CRM формируется очередь запросов/команд на обновление, которые отправляются в интернет по крону. Аналогичная очередь есть на стороне веб-сайта, она содержит данные, которые были изменены из личных кабинетов и которые нужно внести в СУБД/CRM.
Запросы в обоих очередях движутся по запуску ботов-воркеров и в зависимости от результатов выполнения помечаются как выполненные/невыполненные. Делается это чтобы не потерять какие-либо изменения и в случае чего видеть какие запросы не отработали как «сверху» (с сайта) так и снизу (из CRM).
Файлы (фото) синхронизируются простым копированием, скажем, посредством rsync по FTP или типа того.
Все (объявления, данные о платежах и бизнес-логику взаиморасчетов) держать в интернете не хочется: данные коммерчески критичные. Плюс в случае сбоев хотелось бы чтобы в офисе оставался актуальный набор данных и с ним можно было продолжать работу до восстановления соединения, после чего накопившиеся запросы уходили бы из очереди на сайт.
Предполагается, что при такой схеме может быть обеспечен быстрый переезд офиса и сайта.
Так — нормально? Может есть какие-то более разумные практики и решения?
Буду благодарен за любые мнения, даже сугубо скептические.
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Отвечай на вопросы, зарабатывай баллы и трать их на призы.
Подробнее
Подробнее
Данная архитектура обмена данными довольно сложна и требует поддержки множества элементов (очереди, боты-воркеры, синхронизация файлов) в разных системах. В то же время, она может быть достаточно надежной и эффективной при правильной реализации.
Однако, следует учитывать, что такая сложная система может стать источником множества проблем, связанных с синхронизацией и целостностью данных. Кроме того, она может быть дорогостоящей в поддержке и разработке.
Возможно, стоит рассмотреть альтернативные варианты, например, использование облачных баз данных или сервисов, которые позволяют синхронизировать данные между офисом и сайтом автоматически. Также, стоит провести анализ рисков и возможных уязвимостей данной архитектуры.
В любом случае, рекомендуется обратиться к специалистам в области архитектуры информационных систем для получения консультации и рекомендаций.