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

Question

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

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

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

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

Так, что у вас было с этим опытом?

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

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

Подробности шкалы

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

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

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

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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