Передача файлов разных размеров по сети и синхронизация

[programmer_2006]

Передача файлов разных размеров по сети и синхронизация

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

Вообще задачка интересная надеюсь услышать путевые советы и замечания

-~{}~ 07.11.08 12:41:

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

 

[Активист]

programmer_2006
А как ты себе это представляешь?
По пунктам и по русски, первое, второе, третье....

 

[Wicked]

ты забыл рассказать самое главное: ЗАЧЕМ?

 

[programmer_2006]

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

Может кто посоветует какие то решения, варианты, подводные камни или как лучше реализовать, может есть,что почитать...

Буду благодарен за любые советы и рекомендации.

 

[pilot911]

вряд ли кто-то так на планете работает, ну явно, не народ.ру

только представь, имеется куча обращений к ядру в любой цмс... и что ? по сетке будут вызываться функции и возвращаться ответы от них...

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

 

[findnext]

я не думаю что это бред, очень хороший способ дорабатывать системы даже после того когда сайт вышел в LIVE и это вполне реально. Необходимо создать такую систему:
1. Необходимо разделить програмный код на 2 части:
a. код, который не будет никогда менятся и никем кроме разработчиков! Сюда будут входить все базовые классы системы.
b. код который можно будет менять (кустомизировать)

2. Пишите обновления (именно модулями) потому что, если не будет модульности то ничего не получится.

3. С каждым сайтом заливать на сервер и программу которая будет обращаться к центральному серверу. Админу сайта нужно только на кнопку будет нажать чтобы установить какой либо модуль.

-~{}~ 08.11.08 01:01:

совсем забыл сказать что обновлять нужно будет только 1.а - код, который не будет никогда менятся и никем кроме разработчиков!

 

[pilot911]

Автор оригинала: findnext
я не думаю что это бред, очень хороший способ дорабатывать системы даже после того когда сайт вышел в LIVE и это вполне реально. Необходимо создать такую систему:
1. Необходимо разделить програмный код на 2 части:

тут речь о другом:

но каждый сайт так же имеет свою БД и мы хотим,что бы каждый сайт имел и свои файлы кроме общих (ядра), что бы ядро хранилось на главном серваке (хотя не представляю как дочерние сайты будут обращаться к ядру, может кто подскажет?)

 

[findnext]

pilot911пилот я сказал своё мнение как можно организовать этот процесс и как это делают в крупных фирмах у которых сотни и тысячи клиентов, по моему мнению это оптимальный вариант. Полностью автоматизировать процесс так как автор топика хочет на мой взгляд невозможно

 

[programmer_2006]

Автор оригинала: pilot911
вряд ли кто-то так на планете работает, ну явно, не народ.ру

только представь, имеется куча обращений к ядру в любой цмс... и что ? по сетке будут вызываться функции и возвращаться ответы от них...

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

Критиковать может каждый, предложите вариант решения, почему мы пришли к такому варианту
1. База будет очень большой (десятки миллионов записей только по началу т.к. сайтов будет со старту 450)
2. Проект расчитан на долгосрочные перспективы годы...
3. Мне например самому не очень нравится идея держать для каждого сайта отдельно файлы, но зато это позволить гибче управлять сайтами и раслабит связи и на каждом сайте будут только те модули которые ему нужны.

Я описал задачу, если у вас есть другие варианты решения или предложения я с удовольствием их выслушаю.

-~{}~ 08.11.08 19:29:

Автор оригинала: findnext
я не думаю что это бред, очень хороший способ дорабатывать системы даже после того когда сайт вышел в LIVE и это вполне реально. Необходимо создать такую систему:
1. Необходимо разделить програмный код на 2 части:
a. код, который не будет никогда менятся и никем кроме разработчиков! Сюда будут входить все базовые классы системы.
b. код который можно будет менять (кустомизировать)

2. Пишите обновления (именно модулями) потому что, если не будет модульности то ничего не получится.

3. С каждым сайтом заливать на сервер и программу которая будет обращаться к центральному серверу. Админу сайта нужно только на кнопку будет нажать чтобы установить какой либо модуль.

-~{}~ 08.11.08 01:01:

совсем забыл сказать что обновлять нужно будет только 1.а - код, который не будет никогда менятся и никем кроме разработчиков!

Спасибо
А как бы вы решали бы подобную задачку?

 

[dimagolov]

programmer_2006, можешь внятно сказать для чего нужны 450 сайтов с одинаковым контентом? чтобы в поисковиках врагов загнать на ххх-ю страницу выдачи?

 

[pilot911]

обычно как делается? один сервак, на нем несколько сайтов - хоть 500, ядро лежит вне директории сервера

внутри каждого сайта создаются силинки на папки ядра в каждом сайте - вот и все

и так можно на каждом сервере делать.. ну а обновлять можно по методу, который приводили выше )

 

[totamon]

dimagolov , речь не идет об одинаковом контенте. на сколько я понял, речь идет об одинаковых скриптах на 450 сайтах и возможности их контороля, модификации, добавлении новых функций.
зачем это нужно? недавно столкнулся с такой ситуацией - по нацпроекту развития образования каждая школа должна иметь свой сайт обновляемый не менее 2 раз в месяц, это проверяется и ежемесячно составляется рейтинг городов, областей, краев... кстати, неплохое поле деятельности как для кустарей-одиночек-школьников так и для солидных вебстудий или даже интеграторов, смотря на каком уровне ввязаться... в среднего размера области примерно 500-700 школ, вот вам и сеть)
или сеть сайтов региональных представителей какой-нибудь торговой компании или бренда...
подход programmer_2006 не очень понятен, тк и ядро вроде должно быть одно, и сайты на разных доменах, со своим набором модулей и файлов. я бы предложил 2 подхода:
1. многосайтовая система, одно ядро, одна БД, все на ваших серверах, для сайтов клиентов отдельные настройки, шаблоны, файловые папки. даже домены можно разные прикрутить. проблемы с модулями никакой, написали - добавили в систему - стал доступен в настройках клиентов - оплатили - включили- пользуются) минус - клиенты не могут модифицировать код, только то что вы им разрешите. вкачестве примера - не народ, но юкоз) или любая соц.сеть или многоблоговые движки...
2. система кучасайтов). вы продвигаете клиентам свой движок сайта с набором модулей. У клиентов свой хостинг с Бд, свои домены. для контроля вам достаточно их доступа по фтп и параметры БД. можно после регистрации и ввода данных фтп доступа автоматом закачивать скрипты, распаковывать, запускать установку и конфигурирование. те ваша система ведет учет клиентов, их настроек и реализует работу с файлами движка по фтп. работу с модулями можно построить 2мя путями - модуль закачивается в специальную папку на сайте клиента, и клиент сам запускает его установку из своей админки, или, вы можете сами заменять файлы модуля, или куски кода в скрипте, а там и до системы субверсий совсем рядом...
вернее я бы предложил первый) и не стал бы их мешать... каждый из них достаточно сложен, зачем усложнять все в 2 раза?
понимаю что это все только общие слова, но описание реализации каждой по книжке займет, я только хотел бы разделить эти подходы.

 

[programmer_2006]

Автор оригинала: pilot911
обычно как делается? один сервак, на нем несколько сайтов - хоть 500, ядро лежит вне директории сервера

внутри каждого сайта создаются силинки на папки ядра в каждом сайте - вот и все

и так можно на каждом сервере делать.. ну а обновлять можно по методу, который приводили выше )

Дело в том, что серваки могут быть разные, так,что один сервак не вариант. А вот как реализовать с расчетом на то,что серваков может быть много и они могут быть в разных места, а не в одном дата центре.

-~{}~ 09.11.08 00:11:

Автор оригинала: totamon
dimagolov , речь не идет об одинаковом контенте. на сколько я понял, речь идет об одинаковых скриптах на 450 сайтах и возможности их контороля, модификации, добавлении новых функций.
зачем это нужно? недавно столкнулся с такой ситуацией - по нацпроекту развития образования каждая школа должна иметь свой сайт обновляемый не менее 2 раз в месяц, это проверяется и ежемесячно составляется рейтинг городов, областей, краев... кстати, неплохое поле деятельности как для кустарей-одиночек-школьников так и для солидных вебстудий или даже интеграторов, смотря на каком уровне ввязаться... в среднего размера области примерно 500-700 школ, вот вам и сеть)
или сеть сайтов региональных представителей какой-нибудь торговой компании или бренда...
подход programmer_2006 не очень понятен, тк и ядро вроде должно быть одно, и сайты на разных доменах, со своим набором модулей и файлов. я бы предложил 2 подхода:
1. многосайтовая система, одно ядро, одна БД, все на ваших серверах, для сайтов клиентов отдельные настройки, шаблоны, файловые папки. даже домены можно разные прикрутить. проблемы с модулями никакой, написали - добавили в систему - стал доступен в настройках клиентов - оплатили - включили- пользуются) минус - клиенты не могут модифицировать код, только то что вы им разрешите. вкачестве примера - не народ, но юкоз) или любая соц.сеть или многоблоговые движки...
2. система кучасайтов). вы продвигаете клиентам свой движок сайта с набором модулей. У клиентов свой хостинг с Бд, свои домены. для контроля вам достаточно их доступа по фтп и параметры БД. можно после регистрации и ввода данных фтп доступа автоматом закачивать скрипты, распаковывать, запускать установку и конфигурирование. те ваша система ведет учет клиентов, их настроек и реализует работу с файлами движка по фтп. работу с модулями можно построить 2мя путями - модуль закачивается в специальную папку на сайте клиента, и клиент сам запускает его установку из своей админки, или, вы можете сами заменять файлы модуля, или куски кода в скрипте, а там и до системы субверсий совсем рядом...
вернее я бы предложил первый) и не стал бы их мешать... каждый из них достаточно сложен, зачем усложнять все в 2 раза?
понимаю что это все только общие слова, но описание реализации каждой по книжке займет, я только хотел бы разделить эти подходы.

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

 

[prolis]

профессионально эти задачи решаются по разному:
1. SVN
2. SOAP