Один крупный экземпляр приложения или множество приложений среднего размера?

Question

Веб-приложение, которое мы написали, предназначенное для одного клиента, будет разработано и продано десяткам компаний, а мы займемся размещением.

Мне могли бы пригодиться некоторые рекомендации о плюсах и минусах развертывания отдельного экземпляра для каждого клиента по сравнению с использованием одного (или очень небольшого числа) многопользовательских экземпляров.

Сначала, по мере того как мы будем набирать обороты, я буду иметь запускать отдельный экземпляр приложения для каждого нового клиента (они будут выходить в сеть по одному), потому что это единственный немедленный вариант.Я предполагаю, что это будет не очень хорошо масштабироваться с точки зрения технического обслуживания - внедрение изменений станет очень утомительным и, возможно, подверженным ошибкам, как только будет доступно более 4 или 5 экземпляров.Если только мы каким-то образом не автоматизируем это.

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

Итак, каков был ваш опыт работы с этим?

Бонусный вопрос № 1: В чем разница в производительности между 10 SQL-серверами с 2 млн записей на каждом и одним огромным с 20 млн?Допустим, все они находятся в одной таблице, и мы в основном выполняем вставки и выборки для отдельных записей.Иногда выбранные значения находятся в индексированном varchar(12) или поле даты.

Бонусный вопрос №2: Я полагаю, что для того, чтобы избежать разветвления, нам пришлось бы сделать настройки настраиваемыми или создать архитектуру подключаемых модулей.Однако это может увеличить стоимость выполнения настроек, и я не хочу быть одним из тех магазинов, которым требуется неделя, чтобы изменить размер текстового поля, и Я не хочу чрезмерно вкладывать средства в инфраструктуру.Есть какие-нибудь мысли по этому поводу?

Детали масштаба

У каждого клиента будет приличный объем данных - до нескольких миллионов записей.

Одновременно будет работать очень небольшое количество пользователей, всего несколько на одного клиента, плюс несколько внутренних представителей с нашей стороны.

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

Answer 1

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

Это добавляет еще один уровень автоматизации обработки, но это означает, что вы можете сохранить хостинг дешевым (вам не нужно будет идти и покупать Cray в ближайшее время), и (надеюсь) такой менталитет означает, что вы могли бы довольно легко создавать резервные копии при отказоустойчивости.

Но давайте не будем забегать вперед...Мы говорим о веб-приложении, верно?Получите ваши базы данных и aspnet на разных компьютерах.Объедините свои базы данных в кластеры, и вы будете гораздо приятнее проводить время, играя с различными интерфейсными сценариями.Вы также сможете увеличить масштаб в зависимости от того, в какой области слойка закончится первой.

Судя по всему, в итоге у вас будет одна кластеризованная база данных на половине, если не на полной дюжине машин с базами данных и всего пара интерфейсных блоков.

Что касается настроек, то вы отлично справились.Вы либо предоставляете полностью размещенный в базе данных набор редактируемых шаблонов, либо вам необходимо настроить экземпляры who.Я полностью за первое.Это большая работа (без особой отдачи), но она того стоит, поскольку вам нужно будет изменять основной код только тогда, когда (вы это сделаете!) вы выполняете обновления. Поиск по сотням пользовательских экземпляров клиентов, чтобы убедиться, что они безопасно обновляются, убьет разработчика! Шаблон - это ответ.По крайней мере, вы могли бы разрешить пользовательский CSS без особых усилий (но им нужен кто-то, кто знает свое дело).

Редактировать:Я видел пару постов, посвященных методу "все в одном".Разделение экземпляров на несколько машин изолирует вас от нескольких вещей:

• Если вы вводите ошибку, не обнаруженную при тестировании, одновременно выполняется работа только с несколькими клиентами

• Сбой оборудования.Падение одного мегасервера вызовет раздражение у многих людей одновременно.Наличие отказоустойчивого мегасервера обходится очень дорого.Наличие запасного блока для отработки отказа на три или четыре работающих сервера - это многое дешевле и раздражает меньше людей.

• Производительность может быть сбалансирована между блоками для каждого клиента, так что вы можете поместить несколько клиентов для легкого использования в один клиент с тяжелым клиентом или просто заполнить блок несколькими клиентами для среднего использования и т.д.

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

Answer 2

когда мы столкнулись с подобной проблемой, вот что мы сделали:

<Ол>

у нас есть одна база кода с несколькими серверами sql. мы поддерживаем несколько серверов iis с копиями одной и той же базы кода. мы можем свободно перемещать клиентов с сервера sql на сервер sql, чтобы максимизировать производительность.

если у клиента есть $ для этого, мы установим их на свой сервер и оставим для них отдельный сервер iis. Это касается крупнейших клиентов, которым ежемесячно платят гораздо больше денег (в 10 раз больше). однако мы не предоставляем им отдельную базу кода. если им нужен мод, мы делаем его видимым для каждого клиента (см. # 3)

пользовательское программирование обычно приводит к настраиваемой опции. даже люди, которые платят нам за то, что они имеют собственный сервер, получают одну и ту же версию кода. иногда это так же просто, как предложение в коде, которое гласит «если клиент =» наш клиент, а затем включите эту опцию ». да, это глупое жесткое кодирование, но если у клиента достаточно денег, это нормально для меня.

я не совсем понял из вашего вопроса, хотите ли вы смешать данные разных клиентов в одну большую базу данных ... наше правило - мы никогда не делаем этого (никогда). это один из самых мудрых решений, которые мы когда-либо делали. это делает манипулирование данными намного менее рискованным и упрощает восстановление данных.

Answer 3

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

Большим недостатком будет управление экземплярами в индивидуальном порядке. (независимо от того, работают ли они на одном сервере или нет).

В любом случае у вас должен быть только один экземпляр кодовой базы. А настройкой следует управлять с помощью плагинов и конфигурации. Передняя часть должна быть отделена от содержимого. Хотя стоимость внесения изменений может быть выше, выгода, с точки зрения возможностей, которые вы можете предложить другим своим клиентам (это будут просто настройки, которые вас просили), окупится, я уверен. То есть, не говоря уже о том, насколько легче будет управлять одной базой кода, а не несколькими.

Answer 4

Я бы настоятельно советовал использовать единственный экземпляр, размещенный вашей компанией.Это имеет следующие преимущества:

• У вас есть физический доступ ко всему коду и базам данных для внесения изменений и обновлений.
• Вы контролируете качество оборудование на котором он работает.
• Когда вы исправляете ошибку в обычном коде, вы исправляете ее раз для всех клиентов.
• Вы можете провести рефакторинг приложения дизайн для лучшей поддержки конкретного кода клиента и избежать разветвления.
• По мере роста числа клиентов вы можете масштабировать свои серверы в соответствии с требованиями к производительности /оперативности .
• Код вашего приложения и базы данных не могут быть изменены "любознательными" клиентами.

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

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

Джоэл Сполски также рассказывает именно об этом на Подкаст StackOverflow 67.

Одна вещь, которую Джоэл извлек из продажи Fogbugz:программное обеспечение, разработанное для установки на собственном сервере на сайте заказчика, под полным контролем этого заказчика, практически никогда не стоит лишних хлопот

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

Answer 5

Все вышесказанное - хорошие моменты, но вы упускаете из виду два ключевых вопроса.По какой цене предлагается услуга и сколько клиентов (порядка величины) вам в конечном итоге придется поддерживать (т. е. размер рынка)?Через 3 года у вас будет максимум 10 клиентов, каждый из которых будет платить вам 500 000 долларов в год, или 500 клиентов, каждый из которых будет платить вам по 10 000 долларов в год?Для небольшой группы высокооплачиваемых премиум-клиентов преимущества индивидуального развертывания очевидны, в то время как более низкие цены и большая клиентская база требуют совместного решения (комментарий Оли) - лучший выход.Или перейти на облачную платформу, хотя я только прочитал шумиху и доработал ее, а не внедрил в полевых условиях.

Бонусный вопрос 1:расположение таблиц, индексация, количество операций чтения / записи, эффективность и сложность хранимых процедур (вы используете procs или, по крайней мере, подготовленные инструкции, верно?) все это имеет значение намного большее, чем количество физических записей в базе данных в определенный момент.Помимо этого, вам, вероятно, потребуется либо предоставить отдельные экземпляры SQL Server для каждого клиента, либо для пула клиентов, опять же в зависимости от некоторых вопросов, которые я поднял выше.

Дополнительный Вопрос 2:В этой ситуации важно выделить время на разработку шаблонов и архитектуры плагинов, и вам нужно сделать это скорее раньше, чем позже.Как только вы начнете настраивать код для платящих клиентов, у вас, скорее всего, не будет времени сделать это правильно.Этот момент невозможно переоценить.Шаблоны и инструменты администрирования, которые предоставляют вам быстрый и глубокий доступ к изменениям в вашем продукте, основанным на данных, сэкономят вам много времени в будущем.По мере расширения вашей компании / группы вы можете добавлять меньше технического персонала, который может быть "экспертами по продуктам", которые могут выполнять 90% настроек и технического обслуживания, освобождая ваше ядро для продолжения разработки или перехода к другим проектам.Наконец, не пренебрегайте своим уровнем данных в этом процессе планирования.Наличие базового уровня данных, состоящего из (почти) неизменяемых хранимых процедур и таблиц, очень важно, поскольку пользовательские таблицы и хранимые процедуры четко разграничены с использованием хорошего соглашения об именовании.

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

Answer 6

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

Я рад, что мы сделали. К тому времени, когда это было сделано, у нас было 3 или 4 форка базы кода (в основном, пользовательские скины и вещи, для которых у нас не было поддержки n-уровня, но также были некоторые реальные функции), и это становилось все более безумным.

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

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