Лучший способ отделить функциональность администратора от общедоступного сайта?

Question

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

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

Сайт работает на довольно стандартном стеке Rails / MySQL / Linux, но я думаю, что это скорее проблема архитектуры, чем реализация: главным образом, как синхронизировать данные и бизнес-логику между этими различными приложениями

Некоторые стратегии, которые я оцениваю:

1) Создайте подчиненную базу данных общедоступной базы данных на другом компьютере. Извлеките весь код модели и библиотеки, чтобы ее можно было разделить между приложениями. Создайте новые контроллеры и представления для интерфейсов администратора.

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

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

3) Некоторая смесь этих двух. Например, единственная общедоступная информация, необходимая для некоторых задач бэк-офиса, - это время или состояние завершения только для чтения. Имеет ли смысл иметь это в совершенно отдельной системе и отправлять данные в открытый доступ? Между тем, функциональность администратора пользователя / группы будет запускаться в отдельной системе, разделяющей базу данных? Недостатком является то, что это, кажется, сохраняет многие из проблем, которые у меня есть с первыми двумя, особенно реорганизация.

Я уверен, что ответы будут сильно зависеть от конкретных потребностей сайта, но я бы хотел услышать истории успеха (или неудачи).

Answer 1

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

Ключ в том, чтобы получить хорошее представление о том, какие данные используются, где и как эти данные участвуют в процессе. Если вы можете сделать это, попробуйте определить, можете ли вы сделать одну базу данных «ведущей». Это будут ваши текущие данные, а другая база данных будет вашим хранилищем рабочих данных (ODS). ОРВ всегда является производной от ваших реальных данных. Процесс обновления ODS из оперативных данных может происходить с интервалом и может как упростить данные, так и выполнить дополнительную обработку, чтобы сделать их более подходящими для приложения, использующего ODS.

Теперь, если вы обнаружите, что это станет большим скачком для вашей текущей ситуации, вы можете попробовать и, по крайней мере, отделить данные в базе данных, чтобы вы не столкнулись с проблемами производительности, такими как блокировки таблиц и т. Д. Это также может быть шагом в правильном направлении, если в будущем вам потребуется перейти на модель, подобную ОРВ.

Answer 2

Я не фанат воспроизведения того, что не нужно. Я бы пометил что такое только admin и построил эту часть как отдельную БД с внутренним IP или другим портом. Затем установите внешние ключи на общедоступном сайте для доступа администратора. Обрабатывать ее как индексированную таблицу было бы гораздо проще для администрирования, чем для репликации, а разработка API - ненужная задача, если вы не общаетесь с устаревшими системами. Также зачем копировать, если вы хотите, чтобы системы были раздельными. Темы мои два цента.