Здравствуйте,
Не знал как лучше назвать тему, лучше опишу проблему. Компания занимается поставкой запчастей, есть сайт, есть сотни клиентов которые на этом сайте видят всю нужную информацию в реальном времени. Также клиенты на сайте добавляют заказы. Программа в компании забирает заказы с сайта через веб-сервис, а обратно постоянно шлет все обновления (обновления информации о заказах, обновления прайсов, балансов клиентов и т.д. и т.п.). Время тут достаточно критично, и если клиент вдруг не может сделать заказ потому что сайт ушел в даун (да, пробовали много разных хостингов, все равно никто 100% uptime не дает, хотя бы даже по причине провайдеров-посредников, т.е. например у конкретного провайдера в Киеве может стать недоступен какой либо конкретный хостинг, сами понимаете) то это очень плохо. Так же плохо если клиент сделал заказ, после этого появляются проблемы со связью и уже в компании программа не может соединиться с сайтом чтобы забрать заказы.
В общем как тут быть... Сначала были мысли поставить копию сайта на втором хостинге с другим доменом, клиентом сообщить "запасной адрес" и как-то проводить полную синхронизацию баз данных на обоих хостингах. Ну точнее либо "вручную" (например при отправке обновлений на сайт, слать их на оба сайта, а когда клиент делает заказ на одном из сайтов, прямо с этого сайта коннектиться к БД другого сайта и слать заказ еще и туда и т.д.) либо покупать 2 выделенных сервера и делать двустороннюю репликацию.
Первый вариант очень уж стремный и трудноподдерживаемый, второй вариант — дорогой, не хотят в фирме ежемесячно платить за 2 выделенных сервера.
Поэтому появилась мысль сделать так:
При отправке обновлений на сайт, все-таки слать обновления на оба сайта (ну как-то продумать чтобы это было универсальнее)
При получении заказов с сайта — проверять оба сайта, т.е. клиент чтобы мог сделать заказ на любом из сайтов
И еще например получать заказы с сайта не когда девушка-пользователь в компании решит их принять, а принимать их автоматом например каждую минуту (ну или точнее не принимать, а просто получать), тогда если клиент сделает заказ, а сайт через 5 минут накроется, то наша программа уже успеет заказ получить.
Вот такие мысли... Вариант конечно тоже не супер, но наверное получше первых двух.
Очень жду ваших комментариев и более лучших предложений, надеюсь посоветуете что-то более красивое, простое и удобное в поддержке и расширении.
MC>Очень жду ваших комментариев и более лучших предложений, надеюсь посоветуете что-то более красивое, простое и удобное в поддержке и расширении.
На правах идеи — поплясать вокруг клиентской части. Т.е., к примеру, сделать продвинутую AJAX-страничку, которая сможет слать обновления на несколько сайтов одновременно, дожидаясь нотификации о том что заказ принят хотя бы с одного из них. Разработать протокол получения обновлений клиентом, который сможет работать с несколькими сайтами.
Здравствуйте, MozgC, Вы писали:
MC>Очень жду ваших комментариев и более лучших предложений, надеюсь посоветуете что-то более красивое, простое и удобное в поддержке и расширении.
Я бы сделал так:
1) Почему вас не устраивают выделенные сервера? Тоесть один? У меня есть сервер и проблем вроде нет, и надеюсь не будет. Да и стоит сервер копейки.
2) Есть тут один тоже интересный вариант. Хотя тут вопрос, как его реализовывать: у клиента страничка (Даже может быть сохранена.) На страничке две картинки с двух сайтов. Запретить их кэширование. Какая загрузится, тот сайт и доступен. На картинках приглашение перейти на сайт.
3) Программа на стороне клиента. В которой он собственно и работает.
4) Тоже интересная идея: Прокси-сервер на стороне клиента. Клиент просит ваш сайт. Проксик, как собака, отроет ваш сайт, определит живучесть, направит клиента.
5) А вот наверное попроще: программа типа прокси, только запускается клиентом один раз, тыкает клиента носом, убегает. Висит в виде ярлычка.
Хм, вообще сайт не должен накрываться. Как я говорил, у меня сервер, так я не замечал, что он когда-то не работал.
Мне кажется, что у вас там большая фирма. Но почему вы не смогли обеспечить себя нормальным сайтом вопрос. Также очень интересная фраза: "а сайт через 5 минут накроется". Ощущение, что сайт накрывается частенько, и это стало для вас кошмаром. Как же мне все-таки повезло с хостингами.
Берите сервер и наслаждайтесь тишиной и покоем. Я уж год на нем ничего масштабного не делаю. Так пару раз перезапустил Apache, чтоб домены новые прописались.
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, MikelSV, Вы писали:
MSV>Хм, вообще сайт не должен накрываться. Как я говорил, у меня сервер, так я не замечал, что он когда-то не работал.
А ты на него internetseer.com натрави. Есть шанс, что узнаешь много нового. У нас вот выделенный сервер регулярно (где-то час-два в месяц) уходит в недоступность. По различным причинам. Без мониторинга мы бы об этом даже и не знали.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, MikelSV, Вы писали:
MSV>1) Почему вас не устраивают выделенные сервера? Тоесть один? У меня есть сервер и проблем вроде нет, и надеюсь не будет. Да и стоит сервер копейки.
Ну не хочет руководство тратиться на 2 выделенных сервера. Именно 2 для репликации. 1 выделенный сервер может так же уйти в down.
MSV>Хм, вообще сайт не должен накрываться. Как я говорил, у меня сервер, так я не замечал, что он когда-то не работал.
Видимо вы действительно просто не замечали. А когда 100 клиентов, то шанс что кто-то заметит и напишет нам — довольно большой.
MSV>Мне кажется, что у вас там большая фирма. Но почему вы не смогли обеспечить себя нормальным сайтом вопрос. Также очень интересная фраза: "а сайт через 5 минут накроется". Ощущение, что сайт накрывается частенько, и это стало для вас кошмаром. Как же мне все-таки повезло с хостингами.
Фирма скажем так средняя. Перепробовали уже много хостингом, 100% uptime'а нигде нет. Сайт накрывается не частенько, но например раз в месяц либо мы замечаем что не грузится, либо клиенты сообщают. Как уже сказал пробовали много хостингов — различия есть — где-то лучше, где-то хуже, но 100% uptime нигде нет. Повторюсь, что дело даже не только в хостере, дело еще в провайдерах. Например у меня может провайдер затупить раз в пару месяцев так, что ya.ru не будет грузиться, а google.ru — будет (хотя я буду знать, что у людей у которых другой провайдер — грузятся оба сайта). Так же и у нас, хостинг даже может быть в порядке, но какой-то клиент конкретно на этот хостинг зайти не может. Или опять же хостинг может быть работать, а в компании он может не грузится, хотя другие сайты грузятся и т.д. В общем такие вот заморочки.
MSV>Берите сервер и наслаждайтесь тишиной и покоем. Я уж год на нем ничего масштабного не делаю. Так пару раз перезапустил Apache, чтоб домены новые прописались.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Переставить вебсервер в офис рядом с главным сервером базы данных и послать хостинги напрочь. MSS>Это повысит надежность процесса перекачки с вебсервера в главную базу практически на 100%.
Я думаю это будет относительно дорого (хотя дороже может выйти оплачивать мою работу) и по сути дела ничего не гарантирует. Ставим веб-сервер в офисе, провайдер вдруг тупит — в результате клиенты не могут сделать заказы.
MC>Я думаю это будет относительно дорого (хотя дороже может выйти оплачивать мою работу)
Чем дорого? стоимостью сервера в 1000 долларов (не такой у вас трафик на сайте, чтобы понадобился сервер за бОльшие деньги)? не забываем еще, что за хостинг надо платить, а перемещение сервера к себе в офис убирает эту статью расходов.
Использование хостинга организацией с развитым "домашним" ИТ отделом — просто глупость, хотя да, модная. Модных глупостей вообще много.
MC>и по сути дела ничего не гарантирует. Ставим веб-сервер в офисе, провайдер вдруг тупит — в результате клиенты не могут сделать заказы.
Эээ нет. Одна из частей выполнения задачи — перекачка с вебсервера в главную базу. При использовании хостинга эта перекачка 2 раза ненадежна — может упасть хостинг-провайдер, а может и офисный. Без использования хостинга эта перекачка почти 100% надежна.
Еще больше повысить надежность можно только решением с несколькими вебсерверами на разных провайдерах (один офисный и несколько хостинговых) и round-robin DNS, скажем, тот же ЖЖ так работает. Тут уже такую архитектуру предлагали.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MC>>Я думаю это будет относительно дорого (хотя дороже может выйти оплачивать мою работу)
MSS>Чем дорого? стоимостью сервера в 1000 долларов (не такой у вас трафик на сайте, чтобы понадобился сервер за бОльшие деньги)? не забываем еще, что за хостинг надо платить, а перемещение сервера к себе в офис убирает эту статью расходов.
Подводкой соответствующего интернет-канала с выделенным IP. За хостинг же платится например 10 долларов в месяц.
MSS>Использование хостинга организацией с развитым "домашним" ИТ отделом — просто глупость, хотя да, модная. Модных глупостей вообще много.
Почему глупость?
MC>>и по сути дела ничего не гарантирует. Ставим веб-сервер в офисе, провайдер вдруг тупит — в результате клиенты не могут сделать заказы.
MSS>Эээ нет. Одна из частей выполнения задачи — перекачка с вебсервера в главную базу. При использовании хостинга эта перекачка 2 раза ненадежна — может упасть хостинг-провайдер, а может и офисный. Без использования хостинга эта перекачка почти 100% надежна.
Частично согласен. Перекачка с веб-сервера в главную базу уже не составит проблем. Но вот на нашем теперь уже домашнем хостинге так же может возникнуть downtime, как и на обычном хостинге, и клиенты не смогут сделать заказы.
А как тебе такой вариант:
1)Рисуешь тонкого клиента.
2)При отправке заказа заворачиваешь все в письмо и посылаешь это письмо на несколько разных почтовых ящиков.
Хоть через один да дойдет.
Подойдут даже бесплатные.
Если есть параноя заказ можно зашифровать и подписать.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, MozgC, Вы писали:
WH>А как тебе такой вариант: WH>1)Рисуешь тонкого клиента. WH>2)При отправке заказа заворачиваешь все в письмо и посылаешь это письмо на несколько разных почтовых ящиков. WH>Хоть через один да дойдет. WH>Подойдут даже бесплатные. WH>Если есть параноя заказ можно зашифровать и подписать.
При таком объеме работы крайне невыгодно обрабатывать заказы полученные по email'у: долго это, неэффективно, ненадежно (письмо может не дойти например). Мы как раз изначально принимали заказы по почте, а потом сделали добавление заказов через сайт. Заказ сохраняется в БД сайта а потом через веб-сервис забирается.
Можно соорудить тонкого клиента который бы на несколько сайтов отсылал через веб-сервис. Но этот вариант я считаю хуже (по причинам поддержки, обновления) чем вариант например с 2 сайтами — т.е. когда клиент (человек) в случае неработоспособности одного сайта — зашел бы на другой и добавил заказ сам, а программа в компании уже каждую минуту бы собирала заказы с обоих сайтов.
Форма заказа сложная? Напиши программу, которая будет соединяться со списком сайтов и пересылать им заказы. Сначала будет пытаться на главный сервер, если не идет, тогда на резервный.
О, было у меня как-то два интернета. Подключите два канала, вероятность недоступности резко уменьшится.
У меня тоже много посетителей на сайте. Опа, как они сегодня активизировались. Две штуки на 3 сайтах будут. (Позор мне, я эти сайты уже год не обновляю.)
У меня на сайте счетчик траффика. Смотрю не часто, надоело, но траффик все время идет. Могу подкорректировать статистику и посмотреть по секундам. Месяца два, а то и больше уже считается.
Считается траффик проходящий через сетевую карту. За последний час была пара секунд, в которые количество отправленных данных было равно 0.
Кажется там еще учитывается служебный траффик, по идее будет сложновато подсчитать реальный.
Счетчик uptimeа ставить просто лень.
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, MikelSV, Вы писали:
MSV>Форма заказа сложная? Напиши программу, которая будет соединяться со списком сайтов и пересылать им заказы. Сначала будет пытаться на главный сервер, если не идет, тогда на резервный.
Ну я про это и написал. Я не думаю что это хорошее решение, чтобы высылать всем клиентам программу для добавления заказов. Потому что потом ее надо будет поддерживать (включая все что связано с этим страшным словом) у всех этих 100-200-300 и т.д. клиентов.
Здравствуйте, MozgC, Вы писали:
MC>Здравствуйте, MikelSV, Вы писали:
MSV>>Форма заказа сложная? Напиши программу, которая будет соединяться со списком сайтов и пересылать им заказы. Сначала будет пытаться на главный сервер, если не идет, тогда на резервный.
MC>Ну я про это и написал. Я не думаю что это хорошее решение, чтобы высылать всем клиентам программу для добавления заказов. Потому что потом ее надо будет поддерживать (включая все что связано с этим страшным словом) у всех этих 100-200-300 и т.д. клиентов.
Интересно, как Яндекс поддерживает свой сайт. У них вроде всегда сайт доступен. Много серверов или мало, но доступ к главному должен быть, без этого никак. Или уже научились обходиться?
Хм, сделай программу открытия клиенту доступного сайта. Действительно — самый лучший вариант.
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
MC>Подводкой соответствующего интернет-канала с выделенным IP. За хостинг же платится например 10 долларов в месяц.
Офис имеет выход в интернет? т.е. канал уже есть?
MSS>>Использование хостинга организацией с развитым "домашним" ИТ отделом — просто глупость, хотя да, модная. Модных глупостей вообще много.
MC>Почему глупость?
Потому что дороже и гиморнее.
MC>Частично согласен. Перекачка с веб-сервера в главную базу уже не составит проблем. Но вот на нашем теперь уже домашнем хостинге так же может возникнуть downtime, как и на обычном хостинге, и клиенты не смогут сделать заказы.
Вперед к распределенному решению по типу ЖЖ с round robin DNS и кучей разных хостингов.
MSS>Офис имеет выход в интернет? т.е. канал уже есть?
Есть, только для того чтобы сайт хостить — явно слабоват — надо будет у провайдера покупать что-то более мощное, да и выделенного IP нету.
MSS>>>Использование хостинга организацией с развитым "домашним" ИТ отделом — просто глупость, хотя да, модная. Модных глупостей вообще много.
MC>>Почему глупость?
MSS>Потому что дороже и гиморнее.
Насчет геморнее — спорно. Насчет дороже — точно неверно — повторюсь хостинг стоит максимум 10 долларов в месяц.
Здравствуйте, MozgC, Вы писали:
MC>При таком объеме работы крайне невыгодно обрабатывать заказы полученные по email'у: MC>долго это, неэффективно,
Почему? MC>ненадежно (письмо может не дойти например).
Если отправить на несколько разных серверов стоящих в разных концах земли (yandex.ru, mail.ru, gmail.com, mail.yahoo.com...) то хоть через один да дайдет.
И время доставки будет == времени самого быстрого сервера.
MC>Мы как раз изначально принимали заказы по почте,
Чем принимали?
Только не говори что сидела девочка и вбивала то что приходит по почте в базу.
Этим может и должна заниматься программа.
MC>а потом сделали добавление заказов через сайт. Заказ сохраняется в БД сайта а потом через веб-сервис забирается.
И клиенты курят бамбук пока сайт лежит.
MC>Можно соорудить тонкого клиента который бы на несколько сайтов отсылал через веб-сервис. Но этот вариант я считаю хуже (по причинам поддержки, обновления)
Поддержки и обновления чего?
MC>чем вариант например с 2 сайтами — т.е. когда клиент (человек) в случае неработоспособности одного сайта — зашел бы на другой и добавил заказ сам, а программа в компании уже каждую минуту бы собирала заказы с обоих сайтов.
Те проблемы которые должен решать ты при помощи умного софта ты перекладываешь на клиентов?
Маладца!
Делать нужно так:
Основная база находится в офисе.
Все обновления идут только через нее.
Хостинги и клиенты будут просто кешами.
Причем для хостингов нужно использовать push, а для клиентов pull.
Те когда данные обновляются основной сервис сам проталкивает новые данные на хостинги, а клиенты тянут данные по требованию и не с основного сервера, а с хостингов.
Таким образом если на хостинге или у клиента что-то поломается то просто тупо дропаешь базу и система сама все выкачает с главного сервера.
При оформлении заявки клиент одну и туже заявку отправляет на несколько почтовых серверов. Ессно к заявке нужно прицепить GUID чтобы различать разные заявки.
Главный сервер раз минуту опрашивает почтовые сервисы на предмет новых заявок.
Таким образом слабым звеном остается только комп в офисе. Но это не избежно ибо если офис умер то и заявки не обработать.
Но как только основной сервер очнется он выгребет все заявки с почтовых серверов.
Писать все это дело нужно на .NET таким образом ты сможешь расшарить очень много кода между основным сервером, хостингами и клиентами.
Клиент должен из себя представлять простой exe'шник который при старте проверяет обновления и если есть болие новая версия то молча скачивает с сайта dll'ки.
Вся логика должна быть в dll'ках.
Таким образом клиенты всегда будут up-to-date.
ИМХО это самый простой и дешовый способ обеспечить очень высокий уровень отказоустойчивости системы.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
А проводили ориентировочный расчет, сколько клиентов не смогло отправить заказы скажем за неделю, месяц, и сколько фирма на этом потеряла, из-за курения бамбука. Хотя бы среднестатический с учетом активности в течении суток, недели и месяца. От сюда можна сказать сколько стоит потратить денег на усовершенствование. А так проблема теоретическая, может потери составят 0 целых 00000....001 %, и все это пустой разговор.
