Лучший способ отделить функциональность администратора от общедоступного сайта?
Я работаю над сайтом, который вырос как с точки зрения пользовательской базы, так и функциональности до такой степени, что становится очевидным, что некоторые задачи администратора должны быть отделены от общедоступного веб-сайта. Мне было интересно, каким будет лучший способ сделать это.
Например, сайт имеет большой социальный компонент и интерфейс для публичных продаж. Но в то же время в разделе администрирования есть задачи бэк-офиса, обработка массовой загрузки, информационные панели (с длительными запросами) и инструменты взаимодействия с клиентами, на которые я бы не хотел повлиять всплесками публичного трафика (или на общедоступные). время отклика).
Сайт работает в довольно стандартном стеке Rails/MySQL/Linux, но я думаю, что это скорее проблема архитектуры, чем реализация: главным образом, как синхронизировать данные и бизнес-логику между этими различными приложениями?
Некоторые стратегии, которые я оцениваю:
1) Создайте подчиненную базу данных общедоступной базы данных на другом компьютере. Извлеките весь код модели и библиотеки, чтобы его можно было разделить между приложениями. Создать новые контроллеры и представления для интерфейсов администратора.
У меня ограниченный опыт репликации, и я даже не уверен, что он должен использоваться таким образом (большую часть времени я видел его, это было для того, чтобы расширить возможности чтения одного и того же приложения, а не иметь несколько разных), Меня также беспокоит вероятность возникновения проблем с задержкой, если ведомое устройство не подключено к той же сети.
2) Создайте новые приложения для конкретных задач / отделов и используйте промежуточное программное обеспечение, ориентированное на сообщения, для их интеграции. Некоторое время назад я прочитал паттерны интеграции предприятия, и они, похоже, выступают за это для распределенных систем. (В качестве альтернативы, в некоторых случаях может оказаться достаточной базовая функциональность RESTful API в стиле Rails.) Но у меня есть кошмары о проблемах синхронизации данных и масштабной ре-архитектуре, которую это повлечет за собой.
3) Некоторая смесь двух. Например, единственная общедоступная информация, необходимая для некоторых задач бэк-офиса, - это время или статус завершения только для чтения. Имеет ли смысл иметь это в совершенно отдельной системе и отправлять данные в открытый доступ? Между тем, функциональность администратора пользователя / группы будет запускаться в отдельной системе, разделяющей базу данных? Недостатком является то, что это, кажется, сохраняет многие из проблем, которые у меня есть с первыми двумя, особенно реорганизация.
Я уверен, что ответы будут сильно зависеть от конкретных потребностей сайта, но я бы хотел услышать истории успеха (или неудачи).
2 ответа
Насколько я могу судить из вашего описания, если вы действительно хотите, чтобы общедоступная производительность и производительность администратора не влияли друг на друга, вам придется использовать отдельные базы данных на отдельных серверах.
Ключ должен получить хорошее понимание того, какие данные используются, где и как эти данные участвуют в процессе. Если вы можете сделать это, попробуйте определить, можете ли вы сделать одну базу данных "ведущей". Это будут ваши текущие данные, а другая база данных будет вашим хранилищем рабочих данных (ODS). ОРВ всегда является производной от ваших реальных данных. Процесс обновления ODS из оперативных данных может происходить с интервалом и может как упростить данные, так и выполнить дополнительную обработку, чтобы сделать их более подходящими для приложения, использующего ODS.
Теперь, если вы обнаружите, что это будет в значительной степени скачком для вашей текущей ситуации, вы можете попробовать и хотя бы разделить данные в базе данных, чтобы вы не столкнулись с проблемами производительности, такими как блокировки таблиц и т. Д. быть шагом в правильном направлении, если в будущем вам потребуется перейти на модель, подобную ОРВ.
Я не фанат воспроизведения того, что не должно быть. Я бы пометил что такое только admin и построил эту часть как отдельную БД с внутренним IP или другим портом. Затем установите внешние ключи на общедоступном сайте для доступа администратора. Обрабатывать ее как индексированную таблицу было бы гораздо проще для администрирования, чем для репликации, а разработка API - ненужная задача, когда вы не общаетесь с устаревшими системами. Также зачем копировать, если вы хотите, чтобы системы были раздельными. Темы мои два цента.