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