Один крупный экземпляр приложения или много среднего размера?
Сокеты обеспечивают мощные асинхронные возможности. Смотрите на Используя Асинхронный Сокет Сервера
, Вот несколько примечаний по коду.
Используя вручную созданные потоки в этом случае могут быть издержки.
код ниже подвергается условиям состязания - TcpClient. Близко () закрывает сетевой поток, Вы проходите через TcpClient. GetStream (). Рассмотрите заключительный клиент, где можно определенно сказать, что это больше не необходимо.
clientThread.Start(client.GetStream());
client.Close();
TcpClient. Остановите () завершения, лежащие в основе сокета. TcpCliet. AcceptTcpClient () использует Сокет. Примите () метод на базовом сокете, который бросит SocketException, как только это закрывается. Можно назвать его от различного потока.
Так или иначе я рекомендую асинхронные сокеты.
6 ответов
Я не вижу веских причин для любого из ваших двух вариантов. Я думаю, что настоящий ответ находится где-то посередине: наличие нескольких экземпляров, каждый из которых обслуживает несколько клиентов.
Это добавляет еще один уровень автоматизации обработки, но это означает, что вы можете сохранить дешевый хостинг (вам не нужно будет выходить и купите Cray в ближайшее время) и (надеюсь) такой образ мышления означает, что вы можете довольно легко выполнять резервное копирование при отказе.
Но давайте не будем забегать вперед ... Мы говорим о веб-приложении, верно? Получите вашу базу данных и aspnet на разных машинах. Кластеризуйте свои базы данных, и вам будет гораздо приятнее играть с различными интерфейсными сценариями. Вы также сможете масштабировать ту область, где сначала закончится затяжка.
Судя по звукам, вы » В итоге у меня будет одна кластеризованная база данных более половины, если не целая дюжина компьютеров с базами данных, и только пара интерфейсных модулей.
Что касается настроек, то вы это прибили. Вы либо предоставляете полностью размещенный в базе данных набор редактируемых шаблонов, либо вам нужно настроить, кто экземпляры. Я все за первый. Это большая работа (без особой отдачи), но она того стоит, поскольку вам нужно будет изменить только основной код, когда (вы это сделаете!) Вы будете выполнять обновления. Поиск по сотне пользовательских экземпляров клиентов, чтобы убедиться, что они обновляются безопасно, убьет разработчика! Шаблон - это ответ. По крайней мере, вы можете разрешить собственный CSS без особых проблем (но им понадобится кто-то, кто знает свое дело).
Изменить: Я видел пару сообщений, посвященных методу «все в одном». Разделение экземпляров на несколько машин изолирует вас от нескольких вещей:
Если вы вводите ошибку, не обнаруженную при тестировании, одновременно обрабатываются только несколько клиентов.
Аппаратный сбой. Падение одного мегасервера вызовет раздражение сразу у множества людей. Наличие отказоустойчивого мегасервера стоит очень дорого. Наличие запасного блока аварийного переключения на три или четыре работающих сервера намного дешевле и раздражает меньшее количество людей.
Производительность может быть сбалансирована между блоками для каждого клиента отдельно, так что вы можете добавить немного света -использовать клиентов с тяжелым клиентом или просто заполнить ящик несколькими клиентами со средним уровнем использования и т. д.
По той же идее всплески использования или другие замедления влияют только на клиентов в том же самом ящике. Конечно, это не значит то же самое для базы данных, но вы можете разделить это на кластер кластеров, когда доберетесь туда.
Я настоятельно рекомендую использовать единственный экземпляр, размещенный в вашей компании. Это дает следующие преимущества:
- У вас есть физический доступ ко всему коду. и базы данных для внесения изменений и обновления.
- Вы контролируете качество оборудование, на котором оно работает.
- Когда вы исправляете ошибку в общем коде, ты исправил это раз и навсегда клиентов.
- Вы можете выполнить рефакторинг приложения. дизайн для лучшей поддержки клиентов конкретный код и избегайте разветвления.
- По мере роста числа клиентов вы может увеличивать и увеличивать масштаб вашего серверы для встречи производительность / отзывчивость требования.
- Код вашего приложения и базы данных нельзя вмешиваться «Пытливые» клиенты.
Я бы сказал, что почти более важно , где выполняется ваше приложение, а не количество его отдельных экземпляров.
Конечно, поддержка нескольких отдельных экземпляров не идеальна из-за накладных расходов на поддержку / обслуживание, но если эти приложения. все находятся на серверах, которыми вы управляете, жизнь намного проще, чем необходимость удаленного / физического доступа к различным сетям и серверам клиентов.
Джоэл Спольски также говорит именно об этом в подкасте StackOverflow 67 .
Одна вещь. Джоэл узнал от продажа Fogbugz: программное обеспечение, предназначенное для быть установлен на сервере в доме в сайт заказчика, под полным контролем этот клиент почти никогда не стоит хлопот
Условно говоря, 20 миллионов записей - это не огромная база данных SQL Server. Один хорошо подготовленный SQL Server может с комфортом справиться с этим размером. Однако более важным является количество одновременных обращений к базе данных. Однако вы говорите, что на одного клиента будет только несколько пользователей, поэтому вряд ли вас поразит, пока уровень параллелизма не вырастет.
Большим преимуществом отдельных экземпляров будет горизонтальное масштабирование по мере роста потребностей каждого клиента. Например, если вы работаете на одном сервере, и одному клиенту внезапно требуется больше параметров, вы набиты. Но если они все индивидуальны, то переместить этого клиента на новый блестящий сервер будет относительно легко.
Большой недостаток будет заключаться в управлении всеми экземплярами по отдельности. (независимо от того, работают ли они на одном сервере или нет.)
Независимо от того, у вас всегда должен быть только один экземпляр кодовой базы. И все настройки должны контролироваться с помощью плагинов и конфигурации. Фронтенд, естественно, должен быть отделен от контента. Хотя стоимость внесения изменений может быть выше, Я уверен, что выгода с точки зрения функций, которые вы можете предложить своим другим клиентам (это будут просто настройки, которые вас просили сделать), окупится. Это не говоря уже о том, насколько проще будет управлять одной кодовой базой по сравнению с несколькими.
Все вышеперечисленное является хорошие моменты, но вы упускаете два ключевых вопроса. По какой цене предлагается услуга и сколько клиентов (по порядку величины) вам в конечном итоге придется поддерживать (т.е. размер рынка)? Через 3 года у вас будет максимум 10 клиентов, каждый из которых будет платить вам 500 000 долларов в год, или 500 клиентов, каждый из которых будет платить вам 10 000 долларов в год? Для небольшой группы высокооплачиваемых премиальных клиентов преимущества индивидуального развертывания очевидны, в то время как более низкие цены и большая клиентская база требуют общего решения (а ля Оли) - лучший способ. Или выберите облачную платформу, хотя я только читал эту шумиху и возился, а не разворачивал ее в полевых условиях.
Дополнительный вопрос 1: макет таблицы, индексация, количество операций чтения / записи, эффективность и сложность хранимых процедур ( вы используете процедуры или, по крайней мере, подготовленные операторы, не так ли?) все это имеет значение намного больше, чем количество физических записей в базе данных. Помимо этого, вам, скорее всего, потребуется предоставить отдельные экземпляры SQL Server для каждого клиента или для группы клиентов, опять же, в зависимости от некоторых вопросов, которые я поднял выше.
Дополнительный вопрос 2: В этой ситуации необходимо уделить время дизайну шаблонам и архитектуре плагина, и вам нужно сделать это раньше, чем позже. Как только вы начнете настраивать код для платежеспособных клиентов, у вас, скорее всего, не будет времени сделать это правильно. Этот момент нельзя переоценить. Шаблоны и инструменты администрирования, обеспечивающие быстрый и глубокий доступ к изменениям в вашем продукте на основе данных, сэкономят вам много времени в будущем. По мере расширения вашей компании / группы вы можете добавить меньше технического персонала, который может быть «экспертами по продуктам», которые могут выполнять 90% настроек и обслуживания, освобождая ваше ядро для продолжения разработки или перехода к другим проектам. Наконец, не пренебрегайте уровнем данных в процессе планирования. Наличие основного уровня данных (почти) неизменяемых хранимых процедур и таблиц очень важно,
при столкновении с аналогичная проблема, вот что мы сделали:
у нас есть одна кодовая база с несколькими серверами sql. мы поддерживаем несколько серверов iis с копиями одной и той же кодовой базы. мы можем перемещать клиентов с сервера sql на сервер sql, чтобы максимизировать производительность.
если у клиента есть деньги, мы установим их на их собственный сервер и поддержим для них отдельный сервер iis. это подходит для самых крупных клиентов, которым ежемесячно платят гораздо больше (в 10 раз больше). однако мы не даем им отдельной кодовой базы. если им нужен мод, мы делаем его видимым для каждого клиента (см. №3)
пользовательское программирование обычно приводит к настраиваемой опции. даже люди, которые платят нам за собственный сервер, получают ту же версию кода. иногда это так же просто, как пункт в коде, который гласит: «Если покупатель =« нашbigcustomer, тогда включите эту опцию ». Да, это сложная жесткая кодировка, но если у клиента достаточно денег, меня это устраивает.
я не совсем понял из вашего вопроса, хотите ли вы объединить данные разных клиентов в одну большую базу данных .. наше правило таково: мы никогда не делаем этого (никогда). это один из самых мудрых решений, которые мы это делает манипулирование данными намного менее рискованным и упрощает их восстановление.
Основываясь на некоторых из полученных здесь советов, мы в конечном итоге реализовали монолитную мультитенантную версию нашего приложения.
Я рад, что мы это сделали. К тому времени, как это было сделано, у нас было 3 или 4 вилки базы кода (в основном пользовательские скины и вещи, для которых у нас не было поддержки n-уровня, но также и некоторые фактические функции), и это становилось все безумнее.
Мы создали мультитенантную версию и успешно все сложили. В итоге оказалось, что нужно было о многом подумать и многое отслеживать, но наши клиенты даже не подозревали, что их перевели на новую систему.
Я скажу, что фактическая миграция клиентов была медвежьей. Сначала я подумал, что мы сможем сделать это вручную в бэкэнде, но в итоге мне пришлось написать несколько довольно сложных сценариев, чтобы выполнить эту работу.